client-nat OpenVPN 2.3

michael.schefczyk

Dear All,

Could someone please post an example of a working configuration using the new client-nat function available in OpenVPN 2.3-alpha1?

In addition to finding out how it works, I would also like to know if it is sufficient to install OpenVPN 2.3-alpha1 only on the (Windows) client side while maintaining the OpenVPN 2.2.2 (CentOS) server to reach the goal described below. If possible, I would like to keep a stable release on the server.

My situation is:
- The server uses routing to connect to a LAN with the (unfortunate, as I now know) IP range 192.168.1.x
- One single user is located at a University (!) using 192.168.x.x. That user obviously experiences an IP address conflict and cannot connect.

My goal is the following:
- It would be great if the user with the address conflict could see the devices in 192.168.1.x (he actually needs only one single IP within that range) for example translated into 10.8.3.x (or any other range not yet used, my idea was to avoid 10.8.0.x, 10.8.1.x and 10.8.2.x which are used inside the OpenVPN server for the routing)
- The translation should only apply to the client in question. For the other clients using other applications, the translation would be a burden. Hence, changes on the client side only would be very welcome.

I assume that client-nat should basically provide a way to reach my goal. However, the command that one my take after reading the manual:

client-nat dnat 10.8.3.0/255.255.255.0 192.168.1.0/255.255.255.0

does not seem to work. In my case, the alpha-client works fine without the command while the connection window remains blank when appending the command to the end of the client configuration file.

Without the shashes as below (alternatively also without the last 255.255.255.0):

client-nat dnat 10.8.3.0 255.255.255.0 192.168.1.0 255.255.255.0

one can connect normally. However, then it is neither possible to ping, e.g., 192.168.1.60 (normally no problem for clients without the address conflict) nor the same device via 10.8.3.60 (which was the goal).

Any help would be very welcome!

Regards,

Michael

Mimiko

"client-nat" is not really intended to mask other clients IPs. The problem you've encountered, is that even the client to which you add client-nat option translates the IP to 10.8.3.x, the server just does not what to do with this IP. I didn't have any practice with this new option, but I think, you will have to route on the server 10.8.3.0 to this new client, and 192.168.1.0 to first client.

michael.schefczyk

Dear All,

Thank you very much for the response - I am still looking for advice which can be implemented directly.

To avoid any misunderstanding: I do not intend to mask clients IPs. My core goal is to avoid an IP adress problem for one OpenVPN client in need to reach a single device in the OpenVPN server side. The device on the server side LAN is - which is not intended - in the same IP address range as the client.

For the lack of documentation, the following questions arise:
- OpenVPN 2.3 alpha required for client aloe or client and server?
- Does the client-nat command run on either the server side or the client side? It would be great if it could be set for only one individual client.
- How do I get snat / dnat right without confusion?
- Which further routing steps need to be taken to reach the goal?

Regards,

Michael

Mimiko

OpenVPN 2.3 alpha required for client alone or client and server?

In any combination.

Does the client-nat command run on either the server side or the client side?

Yes, you can use it only on one client.

How do I get snat / dnat right without confusion?

The same way like you would use iptable's snad / dnat routing.

Which further routing steps need to be taken to reach the goal?

I've already gave you some hint. Wait for developers to answer in more details.

michael.schefczyk

Dear All,

I am thankful for Mimiko's responses, but I still did not manage to use client-nat successfully. According to the manual, client-nat should be "useful in cases where routes or ifconfig settings pushed to the client would create an IP numbering conflict". This is just the issue I am aiming to resolve.

I am trying to use the client-nat command on the client side (with the 2.3 alpha installed only on the client side, not on the server side). My understanding of the manual is that the IP on the server side is transformed ("defines the local view of a resource from the client perspective") so that it does not conflict with the network on the client side anymore.

Adding the command (and variants of the parameters, including snat instead of dnat) to the client config, however, does not seem to have any impact on the routes added by the windows client. It also does not enable pinging/reaching the device located on the server side under a transformed IP.

Could anyone please provide help via a simple example or an explanation?

Regards,

Michael Schefczyk

Mimiko

however, does not seem to have any impact on the routes added by the windows client

I suggest you use iptables NETMASK for this scope and not relying to "client-nat" as it still in test mode and there is no much experience with this. I think, "client-nat" will not work on windows systems, as the same windows systems does not have iptables' option NETMASK.