Thank you by your insight @jimp. I just change the keyword on my script (to monitor VPN tunnels on zabbix) to know if the tunnel is up for "rekeying" insted of "ESTABLISHED". If you wanna take a look: https://github.com/alanwds/zabbix_ipsec_pfsense Thank you so much.

There isn't an IPsec traceroute exactly, but you can use hping to get a similar effect. For example, to see how far ESP (tunneled traffic) makes it, run this command: $ hping -0 1.2.3.4 -H 50 -d 10 -t 1 Replace 1.2.3.4 with the far side, and increase the -t value until you do not get a response. That's where it gets dropped. I see -T in the hping settings now and it might be helpful as well. If the tunnel won't connect at all, however, that would be a simple UDP test for port 500 and 4500. For that you can probably use a traditional traceroute command with -P UDP -p 500 and again for -p 4500.

2.3.2... I just don't get this.. Why would you not be on at least 2.3.5p2? 2.3.2 is no longer supported.. And to be honest the 2.3.x line is EOL here soon.. Like tmrw ;) https://www.netgate.com/blog/pfsense-release-2-3-x-eol-reminder.html

Thank you for the good information. I'm sure I'll succeed.

Not easily. You can make a VPN to a hostname, and if the remote peer can update the hostname when a failover happens, that can trigger a failover. There isn't a way to use both peers at once at the moment though, not with tunneled IPsec. With routed IPsec (VTI) you could nail up a tunnel to both peer addresses and use a routing protocol like OSPF or BGP to decide when to fail over.

@jimp said in 2.4.4 Multiple tunnels to same endpoint: When you make a P1 to a remote peer, it adds a static route to that peer out the chosen interface. Ah ha, that explains the behaviour! Forgive my naivety, but why is the static route required? Is there another mechanism we could use to make sure the connection exits via the right interface? I am imagining something similar to PBR but for host traffic...

Thank you very much for your suggestion. I've reconfigured the tunnel to use VTI and since some days it stays quite stable. The routing seems to work fine for all subnets.

That is probably what the far side used to contact you. pfSense will reply back to whatever port the far side used, since it was probably run through NAT or had some other similar translation done along the way. There may not be anything you can do about that on your side, the far side probably needs to fix whatever is changing that port.

Radius, I think the AD server can provide radius, you'll also need to set up framed ip addresses. I use the inbuilt radius server, my user configs look something like this:- "andy" Cleartext-Password := "xxxxxxxxxx", Simultaneous-Use := "1", Expiration := "Apr 11 2027" Framed-IP-Address = 172.16.8.2, Framed-IP-Netmask = 255.255.255.0, Framed-Route = "0.0.0.0/0 172.16.8.1 1" "Fred" Cleartext-Password := "xxxxxxxxxx", Simultaneous-Use := "1", Expiration := "Apr 11 2027" Framed-IP-Address = 172.16.8.3, Framed-IP-Netmask = 255.255.255.0, Framed-Route = "0.0.0.0/0 172.16.8.1 1"

Unfortunately, NAT won't work with routed IPsec so you might be a bit of a bind there. It's an issue in FreeBSD with how if_ipsec and pf interact. For the larger issue there, you don't setup P2 entries with routed IPsec like that. You just setup static routes, and send the traffic through the tunnel. The far side should still accept the connection as long as the networks passing through match what it expects. Normally you'd want to do routed on both ends, however, not just one.

Thanks for the info. I just checked on both systems and this option was already disabled. Should I maybe enable it? Interestingly though: pfSense A is having trouble with pfSense B's site to site tunnel pfSense B is however able to establish 4 other siste to site tunnels successfully and communicate. THis 5th tunnel to pfSense A just refuses to work.

@chrismacmahon said in TCP not routing through IPsec tunnel - MSS issue?: Can you try disabling the setting of Asynchronous Cryptography? This is located in VPN - IPSEC - Advanced setting bottom of the page. @chrismacmahon - this setting was already disabled in my config - I don't have the box Asynchronous Cryptography checked.

correcting the above information, lifetimes above 3600 seconds still produce the same error after one hour. i'm thinking an upstream network equipment might time out. i'm currently checking with a smaller phase1 timer, hoping for better results

Oct 18 07:11:30 charon 06[CFG] <con-mobile|25> received proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_MD5_96/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_MD5_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_MD5_96/NO_EXT_SEQ Oct 18 07:11:30 charon 06[CFG] <con-mobile|25> configured proposals: ESP:AES_CBC_256/HMAC_MD5_96/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA2_384_192/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA2_512_256/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_256/AES_XCBC_96/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_192/HMAC_MD5_96/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_192/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_192/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_192/HMAC_SHA2_384_192/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_192/HMAC_SHA2_512_256/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_192/AES_XCBC_96/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_MD5_96/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA2_384_192/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA2_512_256/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_128/AES_XCBC_96/MODP_2048/NO_EX Oct 18 07:11:30 charon 06[IKE] <con-mobile|25> no matching proposal found, sending NO_PROPOSAL_CHOSEN That looks more like P2 mismatch there, again, there was no match between what the client wants and what your firewall is configured to send. Looks like the client doesn't want PFS.

@NogBadTheBad Thank you for your message. I agree with your idea implementing Radius server, it makes sense in some way. The IP that they connect to the VPN is a virtual IP assigned to an interface. I better understand now. But on another pfsense box (version 2.3.4) we don't have this issue and we can connect to the vpn from a lan interface.

More logs 2018/10/15 10:19:11 BGP: %ADJCHANGE: neighbor 10.0.29.2(Unknown) in vrf Default Up 2018/10/15 10:22:13 BGP: sendmsg_nexthop: zclient_send_message() failed