OpenVPN client not using the assigned interface

petr · Jun 18, 2016, 6:21 PM

I have multiple WAN connections and I have set up OpenVPN to use my the OPT2WAN2 (my secondary WAN) via the dropdown item in the OpenVPN client settings.

However, no matter what I do all the VPN traffic still goes through the WAN connection. I have other firewall rules in place that direct traffic to either the primary or secondary WAN and those work absolutely fine.

Could you please advise where I need to look to resolve this?

Derelict · Jun 18, 2016, 6:28 PM

Post the rules you think should be policy routing traffic out the VPN.

petr · Jun 18, 2016, 8:42 PM

What do you mean out of the VPN? I do not have any specific rules related to the VPN once it's up.

In terms of determination of what goes over the VPN / normal WAN, I've got a special gateway set up with alias containing list of IPs that go over the VPN.

However, my understanding is that pfSense "dials out" the VPN connection on the interface it is set up to dial out from, which is not the case in my setup. To give a bit more detail, everything was indeed working correctly until about last month, when I added new interfaces to the system (these interfaces are set up separately and have no bearing on the WANs or OpenVPN setup)- since then, I cannot seem to be able to make the VPN connection go over the interface specified in its config.

See attachment on the OpenVPN client setup. The traffic goes over WAN despite the OPT2WAN2 being selected.

![Screenshot 2016-06-18 22.41.29.png](/public/imported_attachments/1/Screenshot 2016-06-18 22.41.29.png)
![Screenshot 2016-06-18 22.41.29.png_thumb](/public/imported_attachments/1/Screenshot 2016-06-18 22.41.29.png_thumb)

Derelict · Jun 18, 2016, 10:01 PM

OK now I see what you're saying. That is interesting. I'll look into it further.

petr · Jun 18, 2016, 10:14 PM

@Derelict:

OK now I see what you're saying. That is interesting. I'll look into it further.

Thank you! Btw. I am on the latest pfSense (but had the same issue on 2.1 before upgrading). Please let me know if there is any further information I can provide!

Derelict · Jun 18, 2016, 10:37 PM

This is on 2.3.1_5.


igb1 - CABLEWAN - DHCP (192.0.2.63) - Gateway 192.0.2.1, Default selected
igb2 - DSLWAN - DHCP (198.51.100.81) - Gateway 198.51.100.1

Gateway Group FAILOVER - Tier 1 CABLEWAN, Tier 2 DSLWAN

OpenVPN Client to Server 203.0.113.99 UDP 1194 DSLWAN Interface selected

igb1 udp 198.51.100.81:45812 -> 203.0.113.99:1194       MULTIPLE:MULTIPLE
   age 00:06:22, expires in 00:00:59, 110:46 pkts, 12930:7991 bytes, rule 209
   id: 01000000576b0a5b creatorid: 1175fd11

Packet capture of packets on DSLWAN show packets out/in the correct interface.
Interesting the state is on igb1.

15:16:29.113002 IP 198.51.100.81.45812 > 203.0.113.99.1194: UDP, length 133
15:16:29.160365 IP 203.0.113.99.1194 > 198.51.100.81.45812: UDP, length 133
15:16:30.117321 IP 198.51.100.81.45812 > 203.0.113.99.1194: UDP, length 133
15:16:30.164606 IP 203.0.113.99.1194 > 198.51.100.81.45812: UDP, length 133
15:16:31.117644 IP 198.51.100.81.45812 > 203.0.113.99.1194: UDP, length 133
15:16:31.164684 IP 203.0.113.99.1194 > 198.51.100.81.45812: UDP, length 133
15:16:32.122491 IP 198.51.100.81.45812 > 203.0.113.99.1194: UDP, length 133
15:16:32.170163 IP 203.0.113.99.1194 > 198.51.100.81.45812: UDP, length 133
15:16:33.127166 IP 198.51.100.81.45812 > 203.0.113.99.1194: UDP, length 133
15:16:33.174159 IP 203.0.113.99.1194 > 198.51.100.81.45812: UDP, length 133

My guess is you could force this state to show the correct interface with a /32 static route to the VPN server to the right gateway. In my case igb1 is probably because it's the default gateway. What really matters is the source address.

Are you just looking at the state or are you actually seeing traffic in/out the incorrect interface?

petr · Jun 18, 2016, 11:22 PM

@Derelict:

This is on 2.3.1_5.
…
My guess is you could force this state to show the correct interface with a /32 static route to the VPN server to the right gateway. In my case igb1 is probably because it's the default gateway. What really matters is the source address.

Are you just looking at the state or are you actually seeing traffic in/out the incorrect interface?

Running same version here. I am actually not looking at the state at all - looking purely at the traffic, which goes through WAN. Before I go into mitigations via static routes, is there any reason why is the preference in the OpenVPN client being ignored? Also, why did it start misbehaving when I've added additional local interfaces? (WANs have not changed during the process, nor did any of the OpenVPN settings).

Derelict · Jun 19, 2016, 4:17 AM

I don't see that it is being ignored. My OpenVPN connection is going out the chosen interface.

What is the source address of the state created out to the VPN provider?

Much more information can be had if you look at what's actually happening instead of a traffic graph.

petr · Jun 19, 2016, 12:11 PM

Ok, looked at the states - it looks like it's originating from the OPT2WAN

In an nutshell, my interfaces are setup in a following way:

inet1 .1.1 <- pfsense WAN .1.51 (default gateway 192.168.1.1)
inet2 .5.1 <- pfsense OPT2WAN2 .5.50 (secondary gateway 192.168.5.1)

On the screenshot, we can see that the state is indeed originating from the 5.50, as it would indicate the OPT2WAN2.

lo0 	udp 	192.168.5.50:41155 -> 31.7.58.234:443 	MULTIPLE:MULTIPLE

However, why does the traffic then flow through WAN?

Thus you are right - it is taken into account in the OpenVPN client, however, the packets just seem to go off the wrong interface for some reason.

Also, why is the OpenVPN connection the only state that has the "lo0" as the interface? All of my other states have a real interface assigned (LAN, WAN, etc.).

![Screenshot 2016-06-19 13.43.07.png](/public/imported_attachments/1/Screenshot 2016-06-19 13.43.07.png)
![Screenshot 2016-06-19 13.43.07.png_thumb](/public/imported_attachments/1/Screenshot 2016-06-19 13.43.07.png_thumb)

petr · Jun 19, 2016, 1:58 PM

Further update:

I have now managed to include the static routes and those seem to have "fixed" the problem and the VPN traffic is going through the assigned interface. However, I had to include all of the current results of the DNS records for vpn.blackvpn.ch, which is far from ideal and I imagine it breaking easily in the future.

Any tips how can I keep using the domain name?

Derelict · Jun 19, 2016, 7:20 PM

If that 5.50 address is the correct interface and traffic is STILL going out another interface it is not being properly routed to the VPN in the first place, like I was originally saying. This really sounds like a policy routing problem brought about by adding Multi-WAN which introduced more policy routing into your rule set.

You need to POST YOUR LAN RULES like I originally asked for. You very likely have something set incorrectly.

And please report the status of the Don't pull routes checkbox and anything in Custom Options in your OpenVPN client config.

Remove whatever static route you set up.

If traffic is still flowing through the wrong WAN go to www.wimi.com. You will see you are not going through the VPN at all.

Having the state on lo0 (a loopback interface) is just fine.

petr · Jun 20, 2016, 9:49 AM

Please find attached!

I do not see anything relevant to the actual VPN connection there though.

The rule that sends selected machines' traffic over the VPN is the "routeViaBlackVPN" alias, which contains IPs of few machines on my network. The torrentDownloads is gateway group consisting of the VPN connection as a primary one and other gateway as secondary.

To clarify, the VPN has always worked (I have tested outgoing IP from configured machines), my only issue that the VPN traffic was not going over the assigned interface. This is now resolved via setting the static routes, however, I would like to find a more flexible solution.

In my opinion, the issue is that the OpenVPN traffic goes over "lo0" interface, which in turn is routed via the default gateway.

Please see below for "Custom Options" of the BlackVPN Client:

comp-lzo
auth SHA512
auth-user-pass /root/blackvpnpassword
route-nopull

The Don't pull routes checkbox is unchecked above.

As I've said, I do not have any issues with using the VPN - traffic goes through it as expected. What I do have issues with is that without the static routes, the data of the OpenVPN link itself does not go through the specified interface. I would also like to add that it all used to work just fine, until I added additional local LAN interfaces to the system (no changes to gateways or rules).

![Screenshot 2016-06-20 11.42.42.png](/public/imported_attachments/1/Screenshot 2016-06-20 11.42.42.png)
![Screenshot 2016-06-20 11.42.42.png_thumb](/public/imported_attachments/1/Screenshot 2016-06-20 11.42.42.png_thumb)

gremblin · Oct 4, 2021, 10:26 PM

@petr I am having the same issue. I also have an OpenVPN client that is using the failover WAN interface. My failover WAN is a 4G modem that I pay for the data I use on, so I want to limit the devices that can use this interface. All the rules seem to work fine except that the VPN connects and devices that use that VPN can still access the internet and tank my data plan. Did you ever find a solution to this?

dbykov · Apr 22, 2024, 3:10 PM

The problem still exists in 2.7.

If during the OpenVPN client connection the interface, specified in client's config, is down, the connection happens through another gateway (which could be a metered backup connection for example).

This is a major issue in my opinion.

UPD: "Do not create rules when gateway is down" option is checked BTW.