[Solved] Keep source IPs of OpenVPN client's subnet

[Scopperloit]

I have configured an OpenVPN network 10.8.0.0/24 running in Azure. The Linux VM's IP is 10.1.0.4 on the 10.1.0.0/24 network in Azure. I have also configured a router as an OpenVPN client with its own subnet 192.168.1.0/24.

In Azure there is a Windows Server VM with the IP 10.1.0.5. On the remote router there is a device with ip 192.168.1.223.

So to summarize I have these networks:

• 10.8.0.0/24 (OpenVPN network)
  10.1.0.0/24 (Azure virtual network)
  192.168.1.0/24 (remote router's LAN)

And these devices:

• 10.1.0.5 (Windows Server VM in Azure)
  10.1.0.4 (Linux VM/OpenVPN server in Azure)
  10.8.0.3 (Router as client on the OpenVPN network)
  192.168.1.223 (Device on the router's LAN)

I have set up routing tables so that the device on IP 192.168.1.223 and the Windows Server VM on IP 10.1.0.5 can communicate with eachother. That is working perfectly.

The problem occurs when I want to send SNMP traps (UDP 162) from the device to the Windows Server VM. The packets are received with the source IP 10.8.0.3 (the router's IP on the OpenVPN network). I want the SNMP packets to arrive with the source IP from the device on 192.168.1.223, which is their actual source.

Is that possible using some set of POSTROUTING rules or configuration in the client.conf file of the remote router?

[TinCanTech]

Please see:
HOWTO: Request Help !

[Scopperloit]

I apologize for my unconventional post. Here are some more details:

Server: OpenVPN 2.3.10 running on Ubuntu 16.04.2 LTS virtual machine hosted in Azure.
Client: Teltonika RT950 (router) with firmware version RUT9XX_R_00.03.314 and kernel version 3.10.36.

However, I was able to solve the problem.
When looking more thoroughly at the router's configuration, I discovered Source NAT trafficing rules allowing me to specify the traffic from LAN to VPN. By applying a rule on all traffic going from LAN IP 192.168.1.223 UDP port 162 to VPN zone (OpenVPN tunnel) setting Source NAT IP to 192.168.1.223, the packets received by the Windows Server now has the desired source IP.