OpenVPN client routing issues at home
Simply put, OpenVPN clients using OpenVPN Connect on iPad are having issues RDPing to their workstations in the office and are unable to ping anything other then the internet. While in the office and connecting to an 'External/Public' wifi they have no issues.
Hardware, as stated, are iPads (NOTE: not all iPads are having issues. Mine being one of them. Others using MacBook Pro's are also ok. Same config settings).
Config settings are the same between devices.
All traffic routed through VPN
VPN is NOT default gateway for network that it is connecting to. PfSense that is the default gateway has static route redirecting VPN traffic from it to the VPN for VPN specific subnet. DNS server does have static route listed for VPN clients.
Config (modified due to privilege information as a X)
remote XX.XX.XX.XX 'Port #' udp
setenv CLIENT_CERT 0
-----BEGIN OpenVPN Static key V1-----
-----END OpenVPN Static key V1-----</tls-auth>
Thank you ahead of time for your assistance.
divsys last edited by
Sorry but I'm a little confused as to the problem scenario.
Simply put, OpenVPN clients using OpenVPN Connect on iPad are having issues RDPing to their workstations in the office and are unable to ping anything other then the internet.
Ok, some of your iPad's won't RDP.
While in the office and connecting to an 'External/Public' wifi they have no issues.
Do you mean they have no issues other than RDP or there is a way that they can get RDP while in the office, or they can get RDP from outside via some other means?
Thanks for Replying!
Sorry for the confusion.
While in the office, testing was done connecting to our 'Guest wifi' that connects straight out to the internet. There is no internal network resolution. Just internet. Also, we have access to the 'public' free wifi offered by a local ISP.
Once they are connected to either our companies guest wifi or the cities public, they launch the VPN and connect with no issues. Once connected, they are able to RDP, ping, and browse our internal resources as if they were connected to our secure wifi in the office. No issues.
Once they go home, connect to their wifi, launch their VPN and connect, they are unable to Ping or RDP to their workstation but they have internet.
Thanks again for your assistance!
Maybe the clients have the same local subnet at home as in your office. This often is the case if you use a subnet which is router default like 192.168.1.0/24. In that case this subnet isn't routed over vpn.
Thanks for replying!
Just verified that they indeed their home network and office network are the same. Now, how do I get them past their local network?
Change your office subnet. Or tell the affected users to do so.
It's hard, I know, but there is no other well working solution. Avoid to use routers default subnets.
I would suggest you change your office network. While you can get home users to change theirs, what do you do when your on some guest wifi say at starbucks or whatever, hotel etc.. and they happen to use the same default 192.168.1.0/24 network.
Stay away from the common ones like 192.168.0 and 192.168.1 - maybe something like 192.168.13.0/14
I would suggest using some oddball 172.16-31 or 10.x network - but have seen many places use default mask on those and just F it up for everyone so they will be using the WHOLE range 10/8 and 172.16/12 so its better to just stick with the 192.168 and use something odd for the 3rd octet
First off, I TOTALLY agree with you on staying away from the de facto 192.168 ranges. With that said, easier said then down.
The frustration I'm having with these answers is that Windows OS's and our MacBooks are working fine. Case in point, one of my iPad users had a MacBook Pro a few months ago and was having issues. Made a change to the config file and it was working fine. That same user has an iPad now and nothing change at his house and it won't work.
Is there NO way to wife the routing table on the iPads so the uTun0 interface is used instead?
This wasn't an issue with the old PPTP they used to have. What makes OpenVPN so different that it can't ignore the local network like the settings selected dictate; "Force all client generated traffic through the tunnel."
Please, I'm REALLY not trying to be difficult or dense. Just trying to explore ALL options because what you are suggesting won't get approved and another VPN option will have to be explored.
There is NO freaking option that allows you to have same freaking network on both sides of the tunnel..
OK. Thank you for making that very clear.
Thank you for your time.
Here is simple example of why its a bad idea..
My desktop I want to remote desktop to at work is 192.168.1.47, I just happen to have the same IP at home 192.168.1.47 – how do tell the machine to ignore the fact and send that traffic down the tunnel.. Lets say you can on the client side force traffic for 192.168.1.82 down the tunnel even though your on 192.168.1.0/24
How do you tell the remote machine hey ignore the fact your on 192.168.1.47 and I am coming from 192.168.1.47 send me the data.. Or that your .82 and I am .47 but instead of sending the data out your local network, send it back to your gateway..
Your simple solution is to just change to a not so common IP range.. Or you going to have to work out some nat plan in your office so that vpn users use some other IP for machines - say 192.168.14.X for their machines even though they are really wanting to go to 192.168.1.X -- then you have to NAT it on your network that when you see traffic to 192.168.14.x send it to 192.168.1.x
It really is a simple process to change your office network to something else..
Your intention isn't totally impossible, but as said, it's a very bad idea.
You can push routes to your office hosts to the clients with very low metric. But if you do that, you cannot ensure that you don't push a route to an IP that the client absolutely need in his own network like his default gateway.
Not at all you push the hole subnet!
To set metric: in server config Advanced box enter e.g.
push "route-metric 10"
A dirty workaround can also be a solution with NAT: You can a 1:1 NAT for vpn interface using a notional external subnet to your LAN and add that notional subnet to the "IPv4 Local Network/s" in openvpn server config. The clients then have to use the NAT addresses to access the LAN hosts.
But, I've never suggested that all! ;)
Thank you for the follow up comments!
I honestly thought that was it.
Again, I totally agree with you. The head scratcher is that my understanding was that when
One thing I haven't mentioned and may make a difference is that the IPv4 Tunnel Network IS a different IP range. WAY different.
It was my understanding that when the VPN connects, the IPv4 Tunnel Network and the IP assigned to that client makes it easy to redirect requests to that network and to make sure that no requests are going to the local network you redirect IPv4 Tunnel Network
What am I missing?
You are correct with your tunnel network, I was thinking site to site with IPs on same side. In a road warrior setup where client gets a IP in the tunnel while the remote server will know how to get back to that client tunnel IP it has. You still have the issue that the client sees his local network as 192.168.1.0/24 and no reason to send that traffic down the tunnel.
Even when you set default send everything down the tunnel, that is for networks that he is not directly attached too. You could try pushing specific routes to that specific client for the specific IP he is trying to get to.. Or having the user create it on their machine. Good luck doing that with an ipad.
But here is the thing - what is the freaking big deal of changing your work ip range to something non common?? It really should be only a few minutes of work at most.. What is your office setup that you don't think you can change its network?
Sigh (not at you). I wish it was as simple as just changing dhcp and that's it.
Besides the firewalls, infrastructure devices, backup jobs, if you can think it, go ahead and apply it. It's somewhat a legacy environment to such degree that some static addressing applies (Evidently 5+ years back, they didn't trust internal DNS all to much).
There are SOO many layers to this environment and not all of it is local. We have an other hardened location that has secured layers connected to each of the subnets we have here. I proposed changing it for other reasons and the exploratory showed it would take WEEKS to thoroughly go through everything and change it.
So yeah… Right now that is the immovable object.
To add to it, now when I connect my iPad to the VPN, the client ip isn't appearing on the OpenVPN Connect client screen. And I have to say I wasn't having issues before and now can't do anything and I'm connected via cell service... this is getting old.
Well even if took months you should get started. Use of static IPs and lack of dns is not a good idea.
Please tell me you didn't hard code IPs into home grown applications..
So what else do these users go to other than their desktops? Why don't you just change that network segment.. Are you saying that your desktops are on the same segment as all your other networking gear and servers, printers, wifi, etc.. ? And also your desktop are static as well??
I'll bring up the topic again because it really should be done and not just for this reason.
Thanks again for your time on this. Much appreciated.