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

    OpenVPN Client Connection sending Traffic to wrong destination

    Scheduled Pinned Locked Moved 2.3-RC Snapshot Feedback and Issues - ARCHIVED
    8 Posts 2 Posters 1.9k 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.
    • D
      dweimer
      last edited by

      I have 3 OpenVPN client connections configured on my pfSense running 2.3.b.20160224.1730, 2 of them are working just fine, but the third stopped sending traffic outbound. I was very confused, as I could see the traffic hitting the firewalls LAN interface but no matter what I did I couldn't see it leaving, nor could I see it blocking anywhere. I was about to ask what else to look at when I finally though to check a packet capture on the other OpenVPN clients tunnel interfaces.

      Bingo, the third connections outbound traffic is going out the 1st connection instead.

      The 1st connection is using 10.12.101.0/24 as its remote subnet.

      The 3rd connections traffic that I am testing with is going to 10.20.0.0/16 subnet. Which is only 1 of several subnets on the 3rd connections.

      The second connection in the list is using 10.12.100.0/24 as its remote subnet and is working correctly.

      This appears to have started on the update I ran on the 24th, and is still continuing on the latest firmware.

      1 Reply Last reply Reply Quote 0
      • D
        dweimer
        last edited by

        I suspect that this has something to do with the tunnel IP Address selection, If I disable the other two OpenVPN clients and restart this one then renable the others it all works. But if I restart this one with either of the others enabled it doesn't.

        The servers are configured with 172.16.0.0/30 For the one I am having issues with 10.12.254.16/29 & 10.12.254.32/29.

        I have found an error in the OpenVPN tunnel logs when the service restarts.

        WARNING: 'ifconfig' is used inconsistently, local='ifconfig 0.0.0.2 0.0.0.1', remote='ifconfig 172.16.0.2 172.16.0.1'
        WARNING: 'ifconfig' is used inconsistently, local='ifconfig 0.0.0.2 0.0.0.1', remote='ifconfig 10.12.254.18 10.12.254.17'

        So it seems that the changes to the OpenVPN tunnel configuration are rejecting the ip settings, anyone else using multiple connections with the new Beta setup and know how these should be configured.

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

          edit: nevermind, I see the issue on the tunnel network. Fix coming.

          1 Reply Last reply Reply Quote 0
          • D
            dweimer
            last edited by

            Server, is still running 2.2.6, IPv4 Tunnel Network is set to 172.16.0.0/30.

            Client Side, currently running 2.3 Beta, IPv4 Tunnel Network is set to 172.16.0.0/30. Topology is set to Subnet.

            Server side status shows its interface IP is 172.16.0.1, client side shows status 0.0.0.2.

            I have the other two turned off at the moment. Server for this connection is at work, the one running beta is at my house. The other two connections are to branch offices, also still running 2.2.6, the 2.2.6 side is the server for both of those as well. Those branch offices also tie back to the main corporate office as clients, and the 2.2.6 client is loading the correct 2nd IP specified in the IPv4 Tunnel network setting.

            1 Reply Last reply Reply Quote 0
            • D
              dweimer
              last edited by

              I went ahead and re-enabled one of the others, when you view the routing information both show same destination address and netif, the following two screen captures are showing destination subnets that are on separate OpenVPN client connections and should show 172.16.0.1 as the gateway for the 192.168.1.0/24 subnet and 10.12.254.17for the 10.12.100.0/24 subnet.

              ![2016-02-25 21_33_07-pfSense.dweimer.net - Diagnostics_ Routes - https___pfsense.dweimer.net_diag_rou.png](/public/imported_attachments/1/2016-02-25 21_33_07-pfSense.dweimer.net - Diagnostics_ Routes - https___pfsense.dweimer.net_diag_rou.png)
              ![2016-02-25 21_33_07-pfSense.dweimer.net - Diagnostics_ Routes - https___pfsense.dweimer.net_diag_rou.png_thumb](/public/imported_attachments/1/2016-02-25 21_33_07-pfSense.dweimer.net - Diagnostics_ Routes - https___pfsense.dweimer.net_diag_rou.png_thumb)
              ![2016-02-25 21_33_28-pfSense.dweimer.net - Diagnostics_ Routes - https___pfsense.dweimer.net_diag_rou.png](/public/imported_attachments/1/2016-02-25 21_33_28-pfSense.dweimer.net - Diagnostics_ Routes - https___pfsense.dweimer.net_diag_rou.png)
              ![2016-02-25 21_33_28-pfSense.dweimer.net - Diagnostics_ Routes - https___pfsense.dweimer.net_diag_rou.png_thumb](/public/imported_attachments/1/2016-02-25 21_33_28-pfSense.dweimer.net - Diagnostics_ Routes - https___pfsense.dweimer.net_diag_rou.png_thumb)

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

                should be fixed.
                https://redmine.pfsense.org/issues/5930

                1 Reply Last reply Reply Quote 0
                • D
                  dweimer
                  last edited by

                  I have confirmed that it is indeed resolved after updating to 2.3.b.20160226.1008, the client is now using the correct IPs and multiple connections are correctly passing traffic.

                  There does appear to a wording issue on the client configuration screen though in the description for the IPv4 Tunnel Network, it states the first network address will be assigned to the client virtual interface.

                  "This is the IPv4 virtual network used for private communications between this client and the server expressed using CIDR (eg. 10.0.8.0/24). The first network address will be assigned to the client virtual interface."

                  Shouldn't this say that the second address will be assigned to the client virtual interface?

                  ![2016-02-26 10_30_54-pfSense.dweimer.net - Status_ OpenVPN - pfsense.dweimer.net.png](/public/imported_attachments/1/2016-02-26 10_30_54-pfSense.dweimer.net - Status_ OpenVPN - pfsense.dweimer.net.png)
                  ![2016-02-26 10_30_54-pfSense.dweimer.net - Status_ OpenVPN - pfsense.dweimer.net.png_thumb](/public/imported_attachments/1/2016-02-26 10_30_54-pfSense.dweimer.net - Status_ OpenVPN - pfsense.dweimer.net.png_thumb)
                  ![2016-02-26 10_37_34-pfSense.dweimer.net - VPN_ OpenVPN_ Clients_ Edit - pfsense.dweimer.net.png](/public/imported_attachments/1/2016-02-26 10_37_34-pfSense.dweimer.net - VPN_ OpenVPN_ Clients_ Edit - pfsense.dweimer.net.png)
                  ![2016-02-26 10_37_34-pfSense.dweimer.net - VPN_ OpenVPN_ Clients_ Edit - pfsense.dweimer.net.png_thumb](/public/imported_attachments/1/2016-02-26 10_37_34-pfSense.dweimer.net - VPN_ OpenVPN_ Clients_ Edit - pfsense.dweimer.net.png_thumb)

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

                    Yeah I fixed the text there, thanks.

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