Can't get OpenVPN client to work
-
I was initlally trying to route two hostnames (sho.com showtimeanytime.com) over the OpenVPN client connection. I have added the OpenVPN interface (let's call it VPN_NJ), could see the gateways up with IP addresses assigned. I also added a LAN rule, routing the traffic destined for those hosts from LAN to the OpenVPN gateway. The rule is above the "LAN default any" rule. I also added a NAT rule in Hybrid mode, matching RFC1918 source traffic one VPN_NJ interface.
However, with tcpdump running on the VPN_NJ interface, I could not see any traffic reaching the interface, e.g. when attempting to telnet the remote host from a local LAN client. The configuration was as follows:
Not being able to get this to work, I slowly reverted back to seting up a typical scenario where all my LAN traffic is routed via VPN.
In my OpenVPN client configuration, I initially had "Don't add/remove routes", as suggested by all the tutorials I encountered. Yet I noticed in the local OpenVPN client that logs report following settings pushed by the server:
PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 10.90.0.1,dhcp-option DNS 10.90.0.10,route 10.90.0.1,topology net30,ping 5,ping-restart 10,ifconfig 10.90.0.10 10.90.0.9,peer-id 0,cipher AES-256-GCM'
So the client on my end clearly sets up a route to 10.90.0.1:
/sbin/route add -net 10.90.0.1 10.90.0.9 255.255.255.255
I re-enabled route creation on the interface and what now happens is:
- I can see traffic on on VPN_NJ interface, but it is one direction only, e.g:
11:49:07.564943 IP 10.90.0.6.62126 > 64.6.65.6.53: 18780+ A? app-measurement.com. (37)
I suppose this is NAT-related.
- the routing rule applies to all traffic, although I don't see why, since all the adde routes should apply to VPN_NJ interface only?
I run out of ideas on how to debug this further. How to test that the VPN connection itself is healthy? Or is it NAT/routing configuration that causes the packets not returning? And why is the 10.90.0.1 route needed in the first place?
-
@kultigsptrizigfrisch said in Can't get OpenVPN client to work:
So the client on my end clearly sets up a route to 10.90.0.1:
/sbin/route add -net 10.90.0.1 10.90.0.9 255.255.255.255If you want to avoid this check "Don't pull routes" in the client settings.
@kultigsptrizigfrisch said in Can't get OpenVPN client to work:
I re-enabled route creation on the interface and what now happens is:
I can see traffic on on VPN_NJ interface, but it is one direction only, e.g:
11:49:07.564943 IP 10.90.0.6.62126 > 64.6.65.6.53: 18780+ A? app-measurement.com. (37)
I suppose this is NAT-related.
The NAT is working on your site as the tcpdump is showing.
Possibly the remote site is miss-configured. What is it, a VPN provider?
Consider that the policy routing rule directs any traffic coming in on LAN to the VPN server. Hence you are not able to access any local IP.
This means, DNS on LAN devices will not work if they are configured to use an internal DNS server like pfSense.
You to add an additional firewall rule to the top of the LAN rule set to allow access to DNS or other internal IPs. -
@viragomann said in Can't get OpenVPN client to work:
So the client on my end clearly sets up a route to 10.90.0.1:
/sbin/route add -net 10.90.0.1 10.90.0.9 255.255.255.255If you want to avoid this check "Don't pull routes" in the client settings.
Sorry, should have made it more clear: I see those routes in my laptop's OpenVPN client. I had "Don't pull routes" in pfSense before, but with that I saw no traffic on the interface at all. I only see the traffic on the interface after disabling that option, i.e. pulling in the routes.
The NAT is working on your site as the tcpdump is showing.
Possibly the remote site is miss-configured. What is it, a VPN provider?
Yes, it is a VPN provider.Consider that the policy routing rule directs any traffic coming in on LAN to the VPN server. Hence you are not able to access any local IP.
I am not able to access Internet IP. LAN works fine. That is, again, with pulling in of the OpenVPN routes enabled. The traffic on the OpenVPN interface is one-direction only, which is why I concluded that something was still wrong with NAT or routing.
This means, DNS on LAN devices will not work if they are configured to use an internal DNS server like pfSense.
Let's forget about DNS resolution for now, not even 1.1.1.1 works. Literally nothing.
You to add an additional firewall rule to the top of the LAN rule set to allow access to DNS or other internal IPs.
-
@kultigsptrizigfrisch said in Can't get OpenVPN client to work:
Sorry, should have made it more clear: I see those routes in my laptop's OpenVPN client.
So not clear what you're talking about here. A VPN provider, your laptop connected to the provider directly, or pfSense?
-
@viragomann said in Can't get OpenVPN client to work:
@kultigsptrizigfrisch said in Can't get OpenVPN client to work:
Sorry, should have made it more clear: I see those routes in my laptop's OpenVPN client.
So not clear what you're talking about here. A VPN provider, your laptop connected to the provider directly, or pfSense?
I used an OpenVPN client on my laptop purely for debugging, to make sure that the VPN provider and the service is functional at all. Then I looked into its logs to see what was going on and saw that the upstream server pushes the 10.90.0.1 route.
-
I tested one more thing: I re-enabled pulling of the routes and tested the VPN connectivity from pfSense shell with
curl https://www.myip.com
It works just fine, I can see the IP address is as expected. So the VPN connection itself works without issues, it must be the routing and/or NATting that are somehow misconfigured that I can't get the selective routing working for LAN clients.
-
@kultigsptrizigfrisch
You have only one NAT rule that applies to any IPv4 traffic. If this one is working from pfSense itself, it should also work for networks behind.
Also you filter rule is applied the any IPv4 traffic. The only thing to consider here is if you have a Quick floating rule, which could match the LAN traffic.So you intend to direct the whole (for now) IPv4 traffic to a VPN provider and you are testing this on your laptop which is connected to LAN as I got it. It doesn't work even if you have NO VPN up on the laptop?
Maybe something wrong on the laptop. So please post its routing table. -
@viragomann said in Can't get OpenVPN client to work:
@kultigsptrizigfrisch
You have only one NAT rule that applies to any IPv4 traffic. If this one is working from pfSense itself, it should also work for networks behind.I actually previously updated that rule to only apply to OpenVPN interface, so it's not that. It works from pfSense only when I have openvpn configured to set up the routes – but then I get no LAN to Internet traffic at all, although I see it on the OpenVPN interface, which is why I assume there's something broken with NAT or routing.
Also you filter rule is applied the any IPv4 traffic. The only thing to consider here is if you have a Quick floating rule, which could match the LAN traffic.
Just a single QoS rule there, nothing of interest:
So you intend to direct the whole (for now) IPv4 traffic to a VPN provider
Yes
and you are testing this on your laptop which is connected to LAN as I got it.
Yes, but also on other devices – to same results, so nothing specific to my laptop.
Let me try to clear one thing up once again: With the pulling of the routes disabled, and the firewall rules configured as instructed and on the screenshots above, which basically dictate to rule all the LAN traffic via the OpenVPN gateway, LAN traffic to the Internet does work – except that traffic is not routed via the OpenVPN and still goes through the main WAN connection. This is the weirdest part, since it appears to be ignoring that rule altogether, or that the gateway that pfSense sets up implicitly is somehow misconfigured. With route pulling enabled, I get the traffic from pfSense itself to route over OpenVPN, but otherwise get no traffic to the Internet on LAN clients.
-
Does anyone have any other idea on how to debug this? Essentially my Firewall LAN pass rule, configured to use OpenVPN gateway is ignored, such that the traffic is still routed through the WAN gateway. What to check here?
EDIT: Updated to 2.6.0 today, didn't change anything.
-
Replying myself, again:
I realized there is a Gateway Status page in Diagnostics, and in there I see the OpenVPN gateway marked as:
Offline, Packetloss: 100%So at this point I am assuming there's something wrong with the Gateway creation.
-
@kultigsptrizigfrisch
Yeah, if the VPN gateway is offline, the packets are sent out by the default gateway.
You can change this behavior by checking System > Advanced > Miscellaneous > Skip rules when gateway is down.Gateway offline basically means that pfSense cannot ping the monitoring IP. The default monitoring IP is the virtual VPN IP of the remote endpoint.
That does not necessarily mean that the VPN is not working, just the remote endpoint does not respond to ping.You can set another monitoring IP, which is reachable over the VPN and is responding, or you can disable monitoring if you don't need it in System > Routing > Gateways.
-
@viragomann Thanks. Came here to report the final solution and I see you had answered with the same. The issue was that the default gateway was not responding to ICMP. Changing the monitoring IP to something else had immediately brought the Gateway up, and the routing now works as expected.
This took way longer than it should :o