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

    Openvpn use wrong route

    Scheduled Pinned Locked Moved
    2.1 Snapshot Feedback and Problems - RETIRED
    3
    11
    4.9k
    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.
    • G
      ggzengel
      last edited by

      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?

      1 Reply Last reply Reply Quote 0
      • P
        phil.davis
        last edited by

        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.

        As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
        If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

        1 Reply Last reply Reply Quote 0
        • G
          ggzengel
          last edited by

          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.

          1 Reply Last reply Reply Quote 0
          • P
            phil.davis
            last edited by

            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.

            As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
            If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

            1 Reply Last reply Reply Quote 0
            • G
              ggzengel
              last edited by

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

              1 Reply Last reply Reply Quote 0
              • P
                phil.davis
                last edited by

                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.

                As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                1 Reply Last reply Reply Quote 0
                • C
                  cmb
                  last edited by

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

                  1 Reply Last reply Reply Quote 0
                  • G
                    ggzengel
                    last edited by

                    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?

                    1 Reply Last reply Reply Quote 0
                    • G
                      ggzengel
                      last edited by

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

                      1 Reply Last reply Reply Quote 0
                      • G
                        ggzengel
                        last edited by

                        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?

                        1 Reply Last reply Reply Quote 0
                        • G
                          ggzengel
                          last edited by

                          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.

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