me too[image: 1581008235645-capture.png]

Thanks Manuel ! This was just what I was looking for. At least, when tried from the firewall, it worked (127.0.0.1 and LAN gw answered after the change). I will visit the customer and double check it from the workstation but pretty sure that this was the solution. Appreciate Your help. / best regards, pete

@kiokoman thx your right

UP

by default only the first 100 routes are displayed in diagnostic routes. Solved.

@ilGino said in IPsec tunnel pfSense - Fortigate disconnects and reconnects: invalid HASH_V1 payload length, decryption failed It is some mismatch on the ID or Phase1 configuration "My Identifier" and "Peer Identifier" fields in the Phase 1 Proposal for example also i would check IKE_SA lifetime if they are the same you need to compare it with the fortigate

PHEW ! Well that was emotional... ok so all working now. Basically I had to stop the IPSEC service (and I mean STOP not restart)… wait a few seconds and then start it again and now it all connects just fine....

Thanks all for your kind replies appreciated

Bump and some additional info: With that line removed, we initially thought we had gotten rid of the problem, but it looks like we only added delay. After about 2 weeks, the IPSec tunnels entered the same weird state where they are up and traffic going out can be seen, but dpinger (or a manual ping) seems to never reach the remote end. Hard to tell if the exact timing is reproducible, but it will happen again eventually after a few days/weeks. (we've seen it happen twice since i initially posted here). Rebooting seems to be the only way to fix this. Restarting ipsec service didn't do anything, neither did disconnecting the tunnels via webinterface and reconnecting. Our resort for now was to move the AWS Site-to-Site tunnels off to an EdgeRouter, as we only started to encounter the issues once they were added. Worker fine before with only pfsense<->pfsense tunnels. I'll continue to monitor the situation, and am waiting for the 2.4.5 release to become available. Hopefully the various bugfixes will in the end resolve the problem. I'll also soon have the opportunity to make another, almost identical setup using two MB-4220T pfsense appliances (https://store.netgate.com/MBT-4220-system.aspx) instead of SG-3100s.

Finally, I solved making a VPN IPsec site-to-site between the networks using a pair of firewalls.

to route all the traffic though IPsec tunnel please follow the below configuration. you need firewall Aliases. [image: 1580195419985-cc7dc5c1-f3f5-4e83-b444-5aa06b44d60a-image.png] [image: 1580195503480-30ea59c5-81e8-4f77-9ee5-213982ae04bc-image.png] you need virtual IP for DNS routing could be any [image: 1580195562895-bb864545-61b8-4176-a3a5-6875ebf07d2b-image.png] [image: 1580195605547-a02e11a5-0657-4322-b622-a5f6a56ee72f-image.png] Set the above virtual ip as DNS for vpn clients. [image: 1580195718656-b5851bc7-ecc7-4417-a518-8488912b53ff-image.png] hope this should work for you. Thanks Daman

Hi, Yes it is possible to setup Routed IPsec over VTI in Pfsense 2.4.4-p1+ alongside FRR BGP. Generally speaking the steps are correct in https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/ipsec-routed.html. Here's some example config to get others going though. In Azure: Azure Example VNET Prefix(s): 192.168.0/16, 172.28.80.0/27 Azure GatewaySubnet Prefix: 172.28.80.0/27 Azure Local Network Gateway: On Premise Remote IP: 1.1.1.1 Address Space: 172.28.80.1/32 Configure BGP: x ASN: On-Premise ASN (Eg. 65512) BGP Peer Address: 172.28.80.33 Azure Virtual Network Gateway: SKU: VpnGwx Configure BGP: x ASN: A different ASN for Azure side (ASN 65515 is the default) BGP Peer IP Address: 172.28.80.5 (Default itll allocate one for you in the GatewaySubnet) Virtual Network Gateway Connection: Youll need to define a matching IKEV2 policy. I went with: dh_group = "ECP256" ike_encryption = "DES3" ike_integrity = "SHA256" ipsec_encryption = "DES3" ipsec_integrity = "SHA256" pfs_group = "ECP256" It shouldn't matter too much so long as they match at both ends. Set a suitable pre-shared key. Finally ensure the connections has BGP enabled. In Pfsense: On the P1: Define a matching policy that you set on Azure Pre-shared key Public ip you allocated and then assigned to the Virtual Network Gateway (Must be a dyanmic PIP btw) On the P2: Local Network Address: 172.28.80.33/32 Remote Network Address: 172.28.80.5/27 FRR BGP: I wont write this out as theres nothing special here. Set your local and remote ASNs correctly. understand what your advertising and what you should be receiving etc... The gotchas Only recent revisions of Pfsense 2.4.4 correctly append 0.0.0.0/0 to right and left side of the tunnels in strongswan. This is important here as we aren't defining policy selectors and need this wildcard so we can use BGP dyanmically. This was likely the issue Richard was encountering I'd guess. Note how my VPN range for local network address is outside of the GatewaySubnet range. This is intentional. Basically Azure wants to own the range you set for GatewaySubnet so you cant use it on premise despite what the Pfsense guide says. Additionally Azure won't peer with a BGP Peering IP that's part of this range. It must be outside of its routeable ranges. So you could also set the BGP peering IP to another entirely unrelated ip on the box eg. 10.0.0.1 (other than the WAN ip you connect Azure too on the P1). As the Azure doc says the minimum address space, and in fact only address space, you need on the LNG is the ip of the BGP peer on Pfsense. Otherwise youll end up with a connection up but nothing being sent down it from Azure. Normal Ipsec rules apply. If your P1 doesnt connect, you've probably not matched either the IKEv policy or the PSK at both ends. Diagnose that before you go any further. If the P2 doesn't connect, check your addresses and the policy on the P2 etc.. Fun fact you can ping the Azure VGWs by default. So if you cant ping it across the tunnel fix that before you fiddle with BGP. FRR and Strongswan have a pretty terrible bug https://redmine.pfsense.org/issues/9668 that means every time your connection goes down (say due to Azure maintenance) or you update ipsec config on even unrelated connections it messes up the BGP -> Kernel route table and you end up with a broken routing table. Be warned and be nice to Netgate and FRR so they fix it ;) Good luck and have fun!

You would need one of two things: Setup a Dynamic DNS hostname using the same failover group as the IPsec local interface. Use a single tunnel with the other side using that Dynamic DNS address for the peer. Do the same on the remote end. This works, but can be slow to respond. Because of how DNS TTLs and timing it could be several minutes before the tunnel recovers. -OR- Use VTI mode, keep two tunnels up at all times, and use a dynamic routing protocol to decide which tunnel will have traffic routed across. This fails over much faster, but is a bit more involved to setup. Both of those have been discussed in numerous threads here on the forum, search around a bit and you're certain to find enough information to guide you either way.