VTI IPsec with 3rd party routers that use policy routing
-
I’ve run into this issue several times when setting up an IPsec VPN with third parties who typically use policy-based VPNs on their firewalls (Cisco, Palo Alto, etc.).
On my side, I rely on SNAT/DNAT, so I need to use a routed/VTI tunnel. The problem is that these third-party firewalls expect an exactly matching Phase 2 selector. However, when using VTI, pfSense automatically adds 0.0.0.0/0, ::/0 to my proposal, which breaks the match.
Questions:
Is there a known workaround for this?
Would it be possible to add an option in the IPsec tunnel settings — e.g., a checkbox like "Don’t add 0.0.0.0/0 to the proposal" — so that existing behavior is preserved, but those of us who need exact matches can configure it accordingly?
-
@lisandromassera said in VTI IPsec with 3rd party routers that use policy routing:
On my side, I rely on SNAT/DNAT, so I need to use a routed/VTI tunnel.
Could you explain this statement, please?
-
@viragomann I generally provide multiple TCP services to the remote side, all exposed on different ports of a single IP. I usually let the remote side choose the IP, so it doesn't conflict with what they already use.
Behind my router, those services actually live on different servers, so I rely on DNAT/port-forwarding rules on the IPsec interface to send each port to the correct backend host.
I believe this requirement (routing traffic from the same IP but different ports to different internal servers) rules out a policy-based VPN, since policy-based NAT would force all traffic to a single IP. I tried combining policy NAT with additional port-forwarding, but two layers of NAT doesn’t seem to work.
On top of that, I also need to consume services on the remote side. For that, I configure outgoing NAT so all traffic from my clients is SNATed to the same single IP.
Moreover, I need to do this with several different customers (each with their IPSEC VPN) on the same router.
Because of these needs — inbound DNAT per service and outbound SNAT for clients, for different IPSEC VPNs — I’ve ended up using a route-based VPN with the option “Filter IPsec VTI and Transport on assigned interfaces, block all tunnel mode traffic.” This allows me to set different rules on each interface's tab and fits my needs.
-
@lisandromassera said in VTI IPsec with 3rd party routers that use policy routing:
I believe this requirement (routing traffic from the same IP but different ports to different internal servers) rules out a policy-based VPN
No, you can as well achieve the same with policy-based IPSec.
@lisandromassera said in VTI IPsec with 3rd party routers that use policy routing:
On my side, I rely on SNAT/DNAT, so I need to use a routed/VTI tunnel. The problem is that these third-party firewalls expect an exactly matching Phase 2 selector. However, when using VTI, pfSense automatically adds 0.0.0.0/0, ::/0 to my proposal, which breaks the match.
Questions:
Is there a known workaround for this?
I'm not aware of any.
If the remote router has no VTI support it will require a proper phase 2 proposal, otherwise the connection will not be established.So try to realize it with a policy-based IPSec and configure the NAT in the phase 2.
For the single address state it at the BINAT settings.
This IP is the only one, which the remote config needs to know then.At "local network" specify your real LAN network. This enables the connection inside your pfSense. But the remote router doesn't need to be aware of this.
You can use this NAT address in port forwarding rules on the IPSec interface to redirect incoming traffic to wherever you want. But the destination has to match the "local network" in the p2.
All outgoing traffic from "local network" to the remote site is natted to the single NAT IP in the p2. -
@viragomann Thanks for your help. Unfortunately, I am already using the "Filter IPsec VTI and Transport on assigned interfaces, block all tunnel mode traffic" option, which allows me to have one filter rule tab per VPN interface, but also prevents me from using policy-based VPNs.
Do you think my proposal of not adding the 0.0.0.0/0 default routes would be workable?