IP address presented to private networks

[deleted]

I'm using Oracle Cloud Infrastructure virtual machines. The VCN CIDR is 10.110.0.0/16, the subnet is 10.110.0.0/24. The VM on which OVPN server is running has a public IP address (ephemeral - one of Oracle's) and a private address on 10.110.0.0/24.

When I create an ovpn server using the OCI Marketplace image, if I run the ovpn client on my PC I get an address on 172.27.224.0/20 as expected. When I then connect from my PC to any VM on the subnet, to the VM I appear to be connecting from OVPN machine's private 10.110.0.0/24 internal address.

When I create my own VM and install the OVPN server by hand, if I run the ovpn client on my PC I get an address on 172.27.224.0/20 as before. But when I then connect from my PC to any VM on the subnet, to the VM I appear to be connecting from my 172.27.224.0/20 address.

Where is this difference configured? I have checked the configuration network and VPN settings for both OVPN servers in the admin GUI, and I think they are identical. For routing, both are set to "Yes, using NAT". I tried "Yes, using routing" as well, got the same effect.

The only difference I can see is that the Marketplace version is 2.8.3, the one I installed myself is 2.10.1

I really want the behaviour I get with the Marketplace image, where on-prem users appear to be on the OCI subnet: that will make routing rules and security groups much easier to configure.

Thankyou for any insight.
John Watson.

[deleted]

Perhaps the problem is that NAT isn't properly enabled in my server? I've been googling around and have found suggestions that masquerade and forward need to be enabled, but as far as I can see they are not enabled in the OVPN Marketplace image either. Is there a proper install doc for openvpnas, that includes any necessary OS config? I've not found anything here, https://openvpn.net/vpn-server-resources/

openvpn_inc

Hello jwatson,

> The VCN CIDR is 10.110.0.0/16, the subnet is 10.110.0.0/24

That's going to be a problem. That's not how you should set this up. You should ensure the VPN subnet is unique and does not overlap with existing subnets. Please fix that by ensuring that the VPN subnet is something completely different like 10.200.0.0/24 or such

> if I run the ovpn client on my PC I get an address on 172.27.224.0/20 as expected.

Hmm so your VPN subnet is actually 172.27.2240.0/20? Okay then. That seems to contradict what you said earlier.

> Where is this difference configured? I have checked the configuration network and VPN settings for both OVPN servers in the admin GUI, and I think they are identical. For routing, both are set to "Yes, using NAT". I tried "Yes, using routing" as well, got the same effect.

So to explain the difference - if you use the 'use NAT' method in Access Server, requests coming from the particular user, group, or global setting, will be provided using NAT. Meaning that the traffic will appear to be coming from the Access Server's own IP on the local network. That makes it easy to integrate VPN because you don't have to deal with special routing rules. If however you use the 'use routing' method, then the traffic will retain the source IP of the VPN client that sends traffic.

So as an example, if you go to the Admin UI, and go to VPN Settings, and set the 'access to private subnets' to 'yes, using NAT', and enter your oracle private network there, then when VPN clients send traffic to the oracle private network, it will appear to the oracle private network as if the traffic comes from the Access Server itself. The existence of the VPN client is kind of hidden from the oracle network. This makes integration easy because the oracle network already knows how to talk to the Access Server, so no additional routes are needed. The Access Server will automatically translate replies to requests from VPN clients back to the VPN clients.

And if you were to set it to 'yes, using routing' instead, then the VPN client traffic will appear on the oracle private network as coming from the VPN client's IP address 172.27.244.x. And this means the oracle private network must be made aware of how to reach the VPN client network. The Access Server serves as the gateway to that VPN network. That requires additional routing steps to be taken care of the oracle private network. If you don't do that then the replies just end up getting lost.

> The only difference I can see is that the Marketplace version is 2.8.3, the one I installed myself is 2.10.1

That's not the problem, we've supported NAT and routing pretty much from version 1.0 so it's just a configuration problem.

Access rules can be set on the global level in VPN Settings, but can also be set on the group level in group permissions, and can alo be set on user level in user permissions. If for example you set it in user permissions as 'use NAT' then NAT will be used. So you have to check all of those places. Another thing is that under Advanced VPN there is a 'routed networks' setting that allows to override NAT and force routing for specific subnets. Sometimes people mistakenly adds subnet there - if you have it set there, try emptying that out.

Good luck,
Johan

[deleted]

In case it will help others, this is the problem: The standard OEL8 installation uses nftables, not iptables. For openvpnas to function correctly, you have to disable nftables:

systemctl stop firewalld
systemctl disable firewalld
yum erase firewalld
service openvpnas restart

and then of course configure iptables the way you need it. To quote the support analyst who identified the problem for me:

"This looks like a possible firewall issue on the OpenVPN Access Server host/VM.
Perhaps there is nftables installed on that instance?

It actually conflicts with using iptables which is what OpenVPN Access Server relies on."

openvpn_inc

Hello jwatson,

Thanks for letting us know. We already have a recommendation to remove the firewall on RHEL systems, as Access Server implements its own firewall. They conflict. This is mentioned on this page;

https://openvpn.net/vpn-server-resources/openvpn-access-server-system-requirements/

What threw me off is that you mentioned you're using Oracle cloud platform, for which we have our own OpenVPN Access Server offering which is based on Ubuntu 22, which doesn't have this problem. I had not realized you installed your own with Oracle Linux (which is an alternative to Red Hat Enterprise Linux) and does have this issue.

Now that we know, it's all clear, thank you.

Have a nice day,
Johan