Netgate SG-1000 microFirewall

Author Topic: pfSense to OpnSense ipsec tunnel ssh problem  (Read 141 times)

0 Members and 1 Guest are viewing this topic.

Offline Paddy

  • Newbie
  • *
  • Posts: 23
  • Karma: +0/-0
    • View Profile
pfSense to OpnSense ipsec tunnel ssh problem
« on: January 18, 2018, 08:58:40 am »
I have created a tunnel between my pfSense box and a clients OpnSense box.

The remote end is a 24 bit subnet and my end is a 23bit subnet.

The tunnel is up and passing all traffic but I have a problem with SSH. My 23bit sub net is slit in two. x.x.1.x is my lan and x.x.2.x is used by openvpn to give to remote workers.

remote workers on x.x.2.x can ssh through the ipsec tunnel with no problem but lan workers can't. The connection only goes so far then stops. the client logs;

OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "remote IP" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to remote ip [remote ip] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/tcadmin/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tcadmin/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tcadmin/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tcadmin/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tcadmin/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tcadmin/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tcadmin/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tcadmin/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8 pat OpenSSH_6.6.1* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to remote ip:22 as 'username'
debug1: SSH2_MSG_KEXINIT sent

and it stop there. The ssh server logs;

sshd[4490]: Connection closed by x.x.1.x [preauth]

The rules on the remote IPSEC interface is allow all from all

The rule on the local openvpn interface is allow all from all

The there are no local LAN rules that would block port 22

Any ideas?

I read it could be caused by a  MTU of 1500 but I don't know. I assume the remote Opnsense is OK as ssh works from half the subnet.

Locally I have other ipsec tunnels to other sites and ssh works fine.

Thanks for any advice.

Offline Paddy

  • Newbie
  • *
  • Posts: 23
  • Karma: +0/-0
    • View Profile
Re: pfSense to OpnSense ipsec tunnel ssh problem
« Reply #1 on: January 18, 2018, 05:54:42 pm »
I've done more testing and it is a MTU problem.

On a client on my lan (x.x.1.12) I tried to ssh to a host at the remote end - it failed to connect.

I then set the MTU on the client (x.x.1.12) to 1400 and tried again - the connection worked.

Without changing the mtu on every host on my lan is there a setting on pfsense I could use?

many thanks for looking.

Offline NogBadTheBad

  • Sr. Member
  • ****
  • Posts: 502
  • Karma: +45/-0
    • View Profile
Re: pfSense to OpnSense ipsec tunnel ssh problem
« Reply #2 on: January 19, 2018, 03:05:16 am »
Does changing the MTU on the WAN or LAN interface not work ?

Offline Paddy

  • Newbie
  • *
  • Posts: 23
  • Karma: +0/-0
    • View Profile
Re: pfSense to OpnSense ipsec tunnel ssh problem
« Reply #3 on: January 19, 2018, 03:32:24 am »
I tried setting the mtu to 1400 on the LAN interface but this had no effect on the ssh connection.

I also set the MSS within the IPSEC settings to 1360 but again it didn't help. I never tried the WAN interface.

I have now set the MTU to 1400 on the target servers and this has worked however I would still prefer to find a solution that effects only the tunnel traffic.