IPsec stops working, Diagnostics Tables entry



  • Have had IPsec working for many months with Pfsense version 2.1.5, PMTUD did not work but the link was ok.
    Remote network is a public class C and the local network is a 10.xx.xx.0/24
    Upgraded to 2.2.3 and i keep getting entries in Diagnostics > Tables > vpn_networks
    The Table entry is my remote network Class C 203.xxx.xxx.0/24
    When this happens the IPsec does not seem to pass traffic from local windows systems to the remote network.
    If i delete the entry in Tables > vpn_networks then the local windows can access remote data via the IPsec tunnel again for a short period of time, a couple of minutes!
    Another strange thing is that it only blocks large packets of data, ssh will work as long as i do not try to dump a full screen.

    Anyone know what causes entries in Tables > vpn_networks
    Do not have any advanced filter options enabled in any rules.

    Appreciate any suggestions
    markl



  • The entries in vpn_networks are supposed to be there and have no relation to whether or not IPsec works. They're used to negate policy routing rules for multi-WAN use cases. If things were missing there it could break in some circumstances where you're relying on the auto-negate rules, but otherwise they do nothing.

    Do you have multi-WAN on this system? What does the output of command:

    grep vpn_networks /tmp/rules.debug
    
    

    show?



  • Hi
    Thanks for the reply.
    I assumed the table was for blocking similar to the Virus Table.
    The unit only has a single WAN interface and a single LAN interface.
    IPsec uses PSK

    Output from command
    grep vpn_networks /tmp/rules.debug
    table <vpn_networks>{ 203.xx.xxx.0/24 }
    scrub from any to <vpn_networks>max-mss 1400
    scrub from <vpn_networks>to any max-mss 1400

    It is strange that i can only get large blocks of data through the tunnel when i delete this entry, as soon as the entry returns i can only get a couple of lines at a time using ssh (putty) Windows 7, if i try to run a top on a remote system the link hangs.

    Will try to spend more time on this when i get home tonight.

    Regards
    markl</vpn_networks></vpn_networks></vpn_networks>



  • Hi
    I can confirm that Samba and SSH fail to pass full packets on the IPsec tunnel if a 203.xxx.xxx.0/24 entry exist in Table vpn_networks.
    Have proven this on two windows 7 systems on the Home network.
    Samba connection also failed on a Centos 7.1 system from Home to Office via the IPsec tunnel.
    Traceroute shows that the IPsec path is always taken from Home to the Office network under both conditions.

    Home  10.34.4.0/24 IPsec <–--------> Office network 203.xxx.xxx.0/24
    10.34.4.0/24 <----> pfsense <---->internet<----> Firewall <-----> Office 203.xxx.xxx.0/24

    The tunnel is reliable but fails to pass any large blocks of data.
    SSH will work if you do not try to dump any more that a couple of lines to the screen.
    Access to Office samba network fails until i remove the entry in Tables vpn_networks.
    If the Table entry is deleted and a samba connection from Home to Office is established the connection seems to remain reliable as long as it remains open.

    Regards
    markl



  • The scrub for MSS clamping is the only relevant difference there. That's very widely used, and you're the only one that's seen any issues.

    The symptoms you describe sound like the opposite - what would happen if you didn't have MSS clamping, not what happens with it enabled.

    You running 32 or 64 bit?

    Under System>Advanced, Networking, do you have TSO and LRO disabled? That's the default, and should be left that way. I have seen weird VPN issues where people have enabled one or both of those.



  • Hi
    Upgraded to Update-2.2.4-DEVELOPMENT-i386-20150704-0731
    IPsec works with this version, no configuration changes where required.
    Did not get time to test the MSS clamping, needed the network so the choice was go back to 2.1.5 or try 2.2.4 Development

    System is 32 bit
    TSO and LRO where not disabled

    The good news is that the problem in 2.2.3 seems to have been resolved in 2.2.4 Development

    Thanks
    markl


Log in to reply