Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    VTI IPsec with 3rd party routers that use policy routing

    Scheduled Pinned Locked Moved IPsec
    7 Posts 2 Posters 4.4k Views 2 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • L Offline
      lisandromassera
      last edited by

      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?

      V 1 Reply Last reply Reply Quote 0
      • V Offline
        viragomann @lisandromassera
        last edited by

        @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?

        L 1 Reply Last reply Reply Quote 0
        • L Offline
          lisandromassera @viragomann
          last edited by

          @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.

          V 1 Reply Last reply Reply Quote 0
          • V Offline
            viragomann @lisandromassera
            last edited by

            @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.

            L 2 Replies Last reply Reply Quote 0
            • L Offline
              lisandromassera @viragomann
              last edited by

              @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?

              1 Reply Last reply Reply Quote 0
              • L Offline
                lisandromassera @viragomann
                last edited by

                @viragomann I don`t know how to make your proposal work... For my system to work I need to expose a single IP address, and redirect the traffic to different backend servers depending on the port. I don't know how to configure this using DNAT/BINAT in policy mode.
                In vti mode, using the option to filter on different interfaces, this is simply implemented using Port Forwarding NAT rules

                1 Reply Last reply Reply Quote 0
                • L Offline
                  lisandromassera
                  last edited by

                  I have made some progress. I have modified the file /src/etc/inc/ipsec.inc at lines 2365 and 2365 to remove the additional selectors, and now my proposal correctly matches the one on the other side and it works flawlessly.

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.