OpenVPN Client Connection sending Traffic to wrong destination



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



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



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



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



  • 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)





  • 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)



  • Yeah I fixed the text there, thanks.