0

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

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?

Scopperloit
  • 101
  • 1

1 Answers1

0

I was able to solve this by looking through the router configuration. The router I am using is Teltonika RT950, which is Linux-based and has built-in trafficing rules allowing for Source NAT configuration along with great OpenVPN support.

By adding a rule for assigning SNAT IP 192.168.1.223 to UDP packets on port 162 going from LAN to VPN (the OpenVPN client configuration appears as a separate zone in the router), the packets received by the Windows Server now has source IP set to 192.168.1.223.

Scopperloit
  • 101
  • 1