2.1.1 to 2.1.3 Upgrade caused problems with SSH and IPSec



  • Hi there, I dont know if these problems are related but I am assuming so, so I will post them together.

    My pfSense was version 2.1.1 and everything was working fine. I had SSH access from WAN when I needed it and I had IPSec setup which I used with an iOS device.

    I decided to do the upgrade (I didn't do the 2.1.2 when it came out) which ran through with no noticeable problems. Reboot for good luck! Everything appears to work as expected, my NAT forwards work, firewall rules working - IE forwards from WAN to internal servers are all good.

    However SSH was no longer accessible from the WAN. In order to make it work I had to create a rule (which I didnt need before) like so:

    Firewall:NAT:Port Forward
    WAN TCP * * WAN address 22 192.168.0.1 22

    Firewall:Rules:
    WAN
    IPv4TCP * * 192.168.0.1 22 * none

    So I had to NAT port 22 from the WAN to LAN? Okay so I understand what I am doing but I don't understand why I need to do it now! is SSH not available on the WAN anymore? Anyway so I now have a working SSH from the WAN.

    Next problem is IPSec, and I am still stuck with this one:

    Firstly I see absolutely nothing in logging on the Firewall about blocking or otherwise for the relevant ports for IPSec (500 4500 etc). And nothing odd in the IPSec log:

    Jun 13 10:57:44 racoon: INFO: unsupported PF_KEY message REGISTER
    Jun 13 10:57:30 racoon: INFO: unsupported PF_KEY message REGISTER
    Jun 13 10:57:30 racoon: [Self]: INFO: 58.xxx.xxx.xxx[500] used as isakmp port (fd=15)
    Jun 13 10:57:30 racoon: [Self]: INFO: 58.xxx.xxx.xxx[500] used for NAT-T
    Jun 13 10:57:30 racoon: [Self]: INFO: 58.xxx.xxx.xxx[4500] used as isakmp port (fd=14)
    Jun 13 10:57:30 racoon: [Self]: INFO: 58.xxx.xxx.xxx[4500] used for NAT-T
    Jun 13 10:57:30 racoon: INFO: Resize address pool from 0 to 5
    Jun 13 10:57:30 racoon: INFO: Reading configuration from "/var/etc/ipsec/racoon.conf"
    Jun 13 10:57:30 racoon: INFO: @(#)This product linked OpenSSL 1.0.1g 7 Apr 2014 (http://www.openssl.org/)
    Jun 13 10:57:30 racoon: INFO: @(#)ipsec-tools 0.8.1 (http://ipsec-tools.sourceforge.net)

    So I figured that I had to create the SSH forward, maybe I have to do that now also with IPSec (again didnt have these rules in 2.1.1).

    Firewall:Rules
    WAN
    IPv4UDP * * WAN address 500(ISAKMP) * none
    IPv4ESP * * WAN address * * none
    IPv4AH * * WAN address * * none
    IPv4UDP * * WAN address 4500(IPSec NAT-T) * none

    What I haven't created is a WAN to LAN NAT for the above, I absolutely don't expect to need to do that!
    However I simply cannot get it to work.

    I can connect from external to the pfsense box, either ssh (now) or through any of my other NAT forwards to internal servers.

    What other information can I offer to help identify the problem here, as I say the firewall log reports nothing being blocked, I even modified the rules above to log and I saw nothing?!

    dns is correctly resolving my external ip.

    Any suggestions, before I have to roll back to 2.1.1, and then if I do upgrade again, catch 22??

    EDIT:

    I did a packet capture and I see one way traffic coming in:

    14:19:01.597086 IP 1.142.xxx.xxx.500 > 58.xxx.xxx.xxx.500: UDP, length 778
    14:19:04.893226 IP 1.142.xxx.xxx.500 > 58.xxx.xxx.xxx.500: UDP, length 778
    14:19:08.850137 IP 1.142.xxx.xxx.500 > 58.xxx.xxx.xxx.500: UDP, length 778
    14:19:10.460159 IP 1.142.xxx.xxx.500 > 58.xxx.xxx.xxx.500: UDP, length 778
    14:19:13.630497 IP 1.142.xxx.xxx.500 > 58.xxx.xxx.xxx.500: UDP, length 778
    14:19:17.577157 IP 1.142.xxx.xxx.500 > 58.xxx.xxx.xxx.500: UDP, length 778



  • @tang73:

    ….

    However SSH was no longer accessible from the WAN. In order to make it work I had to create a rule (which I didnt need before) like so:

    Firewall:NAT:Port Forward
    WAN TCP * * WAN address 22 192.168.0.1 22

    Firewall:Rules:
    WAN
    IPv4TCP * * 192.168.0.1 22 * none

    So I had to NAT port 22 from the WAN to LAN? Okay so I understand what I am doing but I don't understand why I need to do it now! is SSH not available on the WAN anymore? Anyway so I now have a working SSH from the WAN.

    :o
    SSH never ever work  from the WAN 'out of the box'.
    If it was the case, it would be a huge BUG and security issue.

    If you need to SSH in form the outside, take the openvpn road.


  • Netgate Administrator

    SSH still listens on WAN though so a simple firewall rule on WAN that allows traffic in on port 22 should be all that's required, no need to do any NATing. I don't know what's up there, I don't see anything in the 2.1.2 or 2.1.3 change list that might effect it.

    There was though a fix that went into IPSec in 2.1.3 so that may have effected you somehow. Don't know quite how though.  :-\

    Steve


Log in to reply