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

Ah that might do it. Cool.

@jimp Good to go against ASR1000 with that patch - tunnel is no longer bouncing. There's a secondary tunnel on the same box not coming up, but I think that's on their side (P1 up, P2 not returning any traffic though pings are going out).

Regardless, I'll drop in next week after our maintenance window to let you know if they've fixed it.

I don't have a good test case against other ipsec site-to-site or mobile tunnels on this test box - the only one with those is on prod :) I will do my best to spin something up on this so that you can be more confident in the patch going into -p1 :)

Thanks Jim!

I just wanted to follow up on this thread quick and mention that I get did routed IPSec (VTI) to work with Google Cloud Platform using dynamic routing. For the P2 IP addresses, one just has to to use the link-local IP's provided for the BGP session (e.g. 169.254.40.1 and 169.254.40.2 in my example) and things will work fine and routes get exchanged between Google Cloud and pfSense. This article provided me with the hint:

https://cloud.google.com/community/tutorials/using-cloud-vpn-with-checkpoint

@dotdash is right. If the other side has a matching network they have to configure a nat. Maybe have a look on this page. Its originally posted in german but maybe google translator works:
https://translate.google.de/translate?hl=de&sl=de&tl=en&u=https%3A%2F%2Fsysadms.de%2F2018%2F09%2Fsite-to-site-ipsec-vpn-bei-gleichen-netzen%2F

Kind regards

Thanks @jimp .

Well, bummer. I don't think this is going to be possible since I don't really have any way to edit the routing parameters for the VPN gateway (Cloud VPN) on the other side.

I suppose to make everything more straightforward, I could just install pfSense on a GCP compute instance and go from there. I saw this guide out on the net, but is there an official installation available as well on how-to available for Google Cloud?

https://blog.kylemanna.com/cloud/pfsense-on-google-cloud/

Thanks again.

Thanks for the reply.
That helps.