IPsec stops working, Diagnostics Tables entry

allaw

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

cmb

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?

allaw

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>

allaw

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

cmb

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.

allaw

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