Routed IPsec (VTI) to Azure - Does it work?

richard.gray

Hi,

Has anyone been successful in establishing a routed IPsec connection (VTI) between pfSense and the Microsoft Azure VPN gateway? Tunnel mode works fine for me, but I can't get routed mode working for the life of me. I guess my main question is how to configure the local and remote addresses/networks in the pfSense side phase 2 connection.

The closest I've got so far is by setting the local network to a small private range, and the remote address to the private address for the Azure VPN gateway (i.e. the GatewaySubnet address). With this configuration in place, I can establish a BGP session between pfSense and Azure, so there's some basic connectivity there. If I try to connect from pfSense to a host on the Azure side though, I see packets leaving the ipsec2000 interface, but nothing coming back.

It's not obviously a routing problem because I see my BGP advertised routes in the effective routes table in the Azure portal for my VM. And I don't think it's a firewall or security group problem because the same rules work fine when I'm using tunnel mode.

Has anyone managed to get this to work?

Cheers,
Richard

wdup

Hi Richard,

Did you ever get this working?

Rgds,
W

neilfromit

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!