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

    Incorrect outbound policy based routing

    Scheduled Pinned Locked Moved Routing and Multi WAN
    5 Posts 3 Posters 2.3k Views
    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.
    • M
      mcamino
      last edited by

      Hello. We are having an issue with our site-to-site OpenVPN connection.  Below is a diagram of the connectivity currently

      /24 ARIN IP Allocation–-> HQ PfSense Wan 64.79.X.146 ----> Internet(openvpn tunnel) ---> Spoke PfSense Wan 74.109.X.6 --> Local Lan 10.0.x.1---> Server 10.0.X.248

      What we are trying to do is perform a 1:1 Nat from our /24 across the VPN to a server in our remote office. We have this about 90% setup and working sucessfully but we have a single remaining issue. We are experiancing a Asymetrical route. So there is the traffic flow we are seeing.
      Outbound Successful Testing
      server 10.0.X.248 –> Spoke Pfsense ---> openvpn tunnel ---> hq pfsense --> /24 1:1 Nat address ---> Working internet via 1:1 address

      Inbound Failed Testing
      (Http or ANY service)

      1:1 internet address–-> HQ PfSense Wan 64.79.X.146 ----> OpenVPN Tunnel ---> Spoke PfSense Wan 74.109.X.6 --> Local Lan 10.0.x.1---> Server 10.0.X.248

      We did packet captures on all the interfaces and the 1:1 nat packet is recived by the server sucessfull. the server responds but instead of the response going out over the OPENVPN connection back to our HQ pfsense to be natted to the 1:1 address. Instead it is going out the local pfsense wan address 74.109.x.6. Obviously the connection doesnt work with that setup.

      We have Sucessfully setup the OpenVpn connection between the sites. We can perform outbound 1:1 nat sucessfully, but when we try to access public resources inbound we end up with an asymetrical route to the wrong NAT address.

      This is the ruleset we are using for Policy based routing.

      ID Proto Source Port Destination Port Gateway Queue Schedule Description

      • 10.0.X.248 * ! 8.8.8.8 * VPS_NAT none

      Can anyone provide some guidance or assistance on getting this routing troubleshot?

      1 Reply Last reply Reply Quote 0
      • M
        mcamino
        last edited by

        bump**

        1 Reply Last reply Reply Quote 0
        • M
          mcamino
          last edited by

          bump

          1 Reply Last reply Reply Quote 0
          • W
            Willy
            last edited by

            These kind of questions rarely get a (satisfying) answer. I found numerous (much older) issues like yours with no answer.

            I'm experiencing a similar issue and the async routing was classified as a feature.

            1 Reply Last reply Reply Quote 0
            • jimpJ
              jimp Rebel Alliance Developer Netgate
              last edited by

              The problem here is that the return traffic has no way to know it's supposed to go back over the VPN in this case. So it tries to leave out of the internet connection, and either gets blocked for lack of a state, or gets blocked at the client because the IPs don't match up.

              The "client" for the inbound traffic is not known as one that needs to be routed across the VPN.

              Normally, multi-wan sorts this out by using reply-to on the firewall rules on the interface, however we don't add that for VPNs. It may be possible to do that in some cases where the OpenVPN interfaces have been assigned. We have talked about adding a manual reply-to field populated with gateways to choose from, but that hasn't materialized yet.

              Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

              Need help fast? Netgate Global Support!

              Do not Chat/PM for help!

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