Openvpn use wrong route



  • 2.1-BETA1 (amd64)
    built on Sat Feb 2 01:46:53 EST 2013

    I have multi wan with wan1 and wan2.
    wan2 is default gateway.

    For openvpn I chose wan1 as interface and get:
    wan1:19319 -> wan2:27733 -> dest:1195

    If I try it with a wan group and wan1 as tier1 I get the same error.

    Is there a docu about the new routing in 2.1?
    especially:
    Allow default gateway switching - to which gateway; on which interface; in which order?
    Disable all auto-added VPN rules - Are there rules for routing, too?



  • I would also like to verify that selecting a gateway group as the interface for an OpenVPN client will actually make the OpenVPN establish itself out the highest-tier member of the gateway group that is currently up. I don't have a system with me to play with right now.
    I suspect that in the simple case of selecting WAN1 as the interface, when WAN2 is the default gateway, the OpenVPN client initiates packets from WAN1:ephemeral-port-number. The destination is dest:1195. These packets are dealt with according to the ordinary routing table. In the routing table, WAN1 just goes to WAN1 net. From the point of view of the routing table, WAN1 is not a general  way out to the internet. To get to dest:1195 out in internet-land, the routing table has to take the default route, which fires it out WAN2.
    The same logic would apply to selecting a gateway group as the OpenVPN Client interface. Normally WAN1 would be the highest-tier available in the group, and the packets would originate from there - the rest of the argument follows as above.
    If you add a policy-based firewall rule that says "WAN1, UDP, source WAN1 address, any port, destination any (or dest address), port 1195, gateway WAN1" then that might catch the packets generated by the OpenVPN client and policy-route them out WAN1. With a bit of thought the rule could be tightened up so that it only matches packets related to the OpenVPN client, and doesn't interfere with anything else (I don't know what) that might originate on WAN1.
    If that works, then it would be good for the OpenVPN controlling code to be enhanced to setup the appropriate policy routing to match the interface selected.



  • I still have the same problem.

    2.1-BETA1 (amd64)
    built on Thu Mar 28 00:48:46 EDT 2013
    FreeBSD 8.3-RELEASE-p6

    WAN1:17268 -> WAN2:16875 -> dest:1194

    If I choose WAN1 as OpenVPN Interface the traffic leave at interface WAN2.

    If I choose GatewayGroup1 (WAN1=Tier1) as interface the traffic leave at interface WAN2.



  • Did some testing on an Alix (2.1-BETA1 (i386) built on Wed Mar 27 07:29:56 EDT 2013) with LAN, WAN (default gateway), OPT1 and an OpenVPN client that connects out to a company server.
    WANpriority gateway group has WAN = tier1, OPT1 = tier2
    OPT1priority gateway group has WAN = tier2, OPT1 = tier1

    Select interface WAN - connect comes from WAN public IP - good
    Select interface OPT1 - connect comes from OPT1 public IP - good
    Select interface WANpriority - connect comes from WAN public IP - good
    Select interface OPT1priority - connect comes from OPT1 public IP - good

    Changed default gateway to OPT1, used http://checkip.dyndns.com/ to verify that my general browsing is now heading out OPT1.
    Ran the 4 OpenVPN client interface selections again - all still work as expected.
    I do NOT have default gateway switching on, and both WAN and OPT1 were up during the tests.

    Note: If you modify a gateway group (adjusting which gateways are which tier…), save and apply, the OpenVPN client/s using that gateway group do not get re-evaluated and restarted, so they do not start using the new gateway group config. Using the restart button in Status->Services is also not effective - that just restarts the process, it does not rewrite the client conf file. To be effective you have to edit and save the client OpenVPN settings (without actually changing anything). So when testing it is easier to setup multiple gateway groups with various combinations of tiers, then keep editing the OpenVPN client config to change the GW group selected in the interface.



  • What kind of <server host="" or="" address="">do you use? DNS or IP?
    I'm useing DNS.</server>



  • I have a DynDNS account, and DynDNS entries in a dozen pfSense systems that keep the registered names up-to-date with the dynamic IPs. All my OpenVPN clients connect to their servers by name.



  • @ggzengel:

    For openvpn I chose wan1 as interface and get:
    wan1:19319 -> wan2:27733 -> dest:1195

    If I try it with a wan group and wan1 as tier1 I get the same error.

    Only way this happens is if you have a policy routing floating rules forcing the traffic out the wrong way. That can override the auto-handled policy routing that will send it out the correct way absent floating rules. Obviously it's binding correctly since WAN1 is getting NATed to WAN2, which will only happen in that scenario.



  • I have 5 pfsense with 2.1.
    On 3 I have host routes for IPSec and OpenVPN destinations.
    On 2 I have no routes either for IPSec or OpenVPN.

    Edit:
    I forgot I added the route manually for the OpenVPN destinations.
    After deleteing the route the openvpn traffic goes always the default route.

    I don't have floating rules.
    If I change interface (wan1 to wan2) and default route (wan2 to wan1) I get:
    wan2 -> wan1 -> dest

    1. Why didn't I get the routes for IPSec on some pfsense.
    2. Why doesn't it work with openvpn?



  • For IPSec I made a new thread.
    I think there is a big bug with multi wan in my config.



  • After long research and installing 5 virtual pfsense I found the issue.
    If a NAT entry matches, the packet goes the default route.

    I allways set source=* in NAT rules.
    I think this is not the expected behavior of NAT.

    What happens if you get an IP from the carrier (mostly UMTS) which matches the internal subnet?



  • Could somebody verify this behavior?
    Or is this a problem of my understanding?

    Right or wrong? NAT shouldn't change the outgoing interface only changing the IP header.


Locked