Policy routing on established connection



  • I have a setup with two WAN's and two other gateways. The extra gateways are both gateways to the same remote LAN bit via different connections (openVPN (seperate server) vs MPLS) I have static routes which directs all the traffic to the remote LAN over the MPLS and I have a couple of policy routes (on our local LAN interface) which redirect the traffic for some hosts over the openVPN. These are basic rules: if source = IP x.x.x.x and dst = IP x.x.x.x then use openVPN GW. Of course these rules are the first rules in the table.

    On outgoing connections (local to remote) this works fine. All the traffic flows over the openVPN. On incoming connections (remote to local) however, the connection arrives via openVPN but is routed back over the MPLS.

    Schematic view:

    pfSense 10.40.0.1 –------------ Server 10.40.1.100
    pfSense 192.168.1.1
    pfSense 192.168.2.1
                    |
                    |--- MPLS 192.168.1.5 ------- VPN ----- |
                    |---- openVPN 192.168.2.5------- VPN -- |10.41.0.0/16
                                                                       |-server 10.41.1.100

    Why does the policy route not affect the returning traffic? Is there another rule I should add, maybe on another interface?



  • Is there any info missing that prevents anyone from providing a solution? Or is the behavior as designed?



  • Did you solve this?

    I have the same problem. Oitgoing policy route works just fine, but when it is an incoming connection the reply is not following the policy route but the default route.

    Please advise.



  • reply-to is not used on OpenVPN connections unless the tun interface they're using is assigned as an OPT, then it should be. The incoming traffic will follow the routing table without that reply-to.



  • The openvpn connection is not created on the pfSense server but on a separate server located in the DMZ subnet of the pfSense server. As far as the pfSense server is concerned it's "just" another gateway.

    Sorry for not being clear about this in the opening post.



  • Oh, then you'll need to define that other device as a gateway and specify it on the interface that faces that system. You'll have to be careful about how that impacts the automatically generated outbound NAT rules (unless you're using manual outbound NAT) as it will then treat that interface the same as an Internet connection.



  • OK, so when I set the gateway for that interface to the gateway I have configured for the OpenVPN server then the policy rules will work on return-connections as well?

    The MPLS line is also not configured as an internet connection (no gateway set in the interface). Would it be better to do so?



  • Does it work Willy?



  • No, the problem persists.

    In my opinion, if a connection comes in via gateway-X it should go back via that gateway, it shouldn't go back via gateway-Y. But that is exactly what pfSense does. Instead of going back via the same gateway it seems to go back via the routes defined in the routing table.

    I'd like this to be considered as a bug.

    I'm happy to provide you with logs, configurations settings or anything else when needed to track this down.

    Edit: currently running 2.0-RC3 (amd64) built on Fri Aug 12 14:47:46 EDT 2011.


  • Rebel Alliance Developer Netgate

    Depending on how you have that setup, it may not be possible for pfSense to know that the connection came from that gateway, so what you are asking for may be impossible. It isn't a bug really, but a "feature" of how you designed your network.

    Asymmetric routing can cause all kinds of fun things like this to happen.



  • Hi,
    I've encountered the same issue. I'm trying to get all site-to-site site vpn traffic (the return traffic as well) to route via an interface group (two simultaneous tunnels) and not the routing table.
    I assigned each tunnel an interface and set a rule on the lan to use the gateway group for all traffic destined to the opposing site.
    The problem is that if one tunnel goes down, and its the one in the routing table, the return traffic gets lost.
    Any pointers on how I can get it working?

    Thanks,
    E


Log in to reply