OpenVPN Support Forum

Hi folks
I've been chasing documentation, forum articles and everything else I can read for a couple of days now to try and get this working, and I'm still getting nowhere, so its time to ask for help.

The scenario is fairly simple. We have a network running its own OpenVPN server, in to which our small team connect. I've deliberately set that up to force connected clients' DNS to go through the VPN server, to ensure that our server names (thing.company.local) resolve. However, all their traffic apart from addresses within our network then routes to their normal gateways rather than the VPN - there's simply no point in forcing all their non-network traffic such as their browsing and windows updates through our VPN server. SO far, so good, and that's all working.

However, for a few very specific addresses outside our network, I need to force connected clients to route through the VPN server rather than directly. At the client end I should be able to just run a route command, and I know I can ultimately add that to the downloaded users' config file in the VPN login - for now, I'm just running route commands manually while I test this. However, my route command:

route add <dest address> mask 255.255.255.255 <OpenVPN server IP address>

is simply getting me "Destination host unreachable" at the first stage when I check with a traceroute to that destination address.

Is this an OpenVPN server config problem, or something wrong with my route command? Any assistance gratefully appreciated. Thanks.

Is this OpenVPN Access Server? If not, I'll move this ticket to the proper board.

In any case, if you are doing manual directives, on open source, to a public IP, then you need to set up NAT.

Yes, this is OpenVPN Access server using the AWS AMI.

Then simply go to the admin UI, go to VPN Settings, and in the routing section under Allow access to private subnets, select YES, using NAT, and then enter the IP addresses that need to be accessible in CIDR format, like 123.45.67.89/32. That's it.

If you want to do it per user that's fine too. Then define it per user in the user permissions settings, but again, as NAT access.

Thanks, novaflash - that's definitely now causing connections to those IP addresses to be routed to the OpenVPN server without the need for route commands on the individual PCs, so that's half the problem solved. However, connections are still not being routed *through* the actual server. Traceroute from a PC running the OpenVPN client to one of the external addresses gets through OK, routing nicely through the Openvpn server, but no actual SSH or other TCP connections are allowed through, which is very weird.

I've confirmed that from the actual OpenVPN linux server itself can traceroute and connect to the IP address in question with no problems, but for some reason the actual VPN connection isn't allowing the routing through.

Source/dest checking at AWS is disabled on both network gateway and the actual OpenVPN server, as that came up regularly as an issue in other forums I was reading, but that hasn't helped.

I'd welcome any ideas - thank you.

From the Access Server side, it's very simple. Allow access to private subnets > yes, using NAT > specify the IP. Done.

If it doesn't work for you then I suggest you run tcpdump on the Access Server itself:
apt install tcpdump
tcpdump -eni any icmp

And then do a ping from the VPN client to the target system. You will see the traffic coming in at the Access Server, and leaving the Access Server. The source address should be altered to the IP of the Access Server.

You must use NAT, and you cannot using ROUTING. You can never route a private IP on the public Internet. You can never keep the VPN client IP address intact on the Internet. That is why NAT is used.

Also make sure you didn't put anything in the "private routed subnets" field in the Advanced VPN page that would force routing on packets travelling through the Access Server, instead of NAT.

Hi novaflash

Thanks - got there in the end. With your advice on the VPN setup plus some understanding of exactly how things routed on a VPC at AWS, everything is working. Thanks again for your help.

Alright, great to hear.