I have two server facilities (192.168.20.0/24 and 192.168.21.0/24) and I was able to connect the two of them using routing. Almost everything works perfectly; I can ping every host from every other host. My problem is that pings from the client subnet (192.168.20.0/24) are emerging into the server subnet as though they are from the server gateway (192.168.21.10). This unexpected NATing is causing problems with one of my applications. [u]Client Facility (192.168.20.0/24):[/u] [list] [*]192.168.20.1: Router with some static routes. Static route for the Server Facility subnet (192.168.21.0/24) pointing to 192.168.20.10 Static route for the VPN subnet (10.0.10.0/24) pointing to 192.168.20.10 [*]192.168.20.2 - 192.168.20.9: Various hosts [*]192.168.20.10: Ubuntu with OpenVPN 2.3.2 in client mode. Lots of firewall (iptables) rules, but I am pretty sure the rules allow forwarding from LAN/eth0 to VPN/tun0 and vice versa)[/list] [u]Server Facility (192.168.21.0/24):[/u] [list] [*]192.168.21.1: Router with some static routes. Static route for Client Facility subnet (192.168.20.0/24) pointing to 192.168.21.10 Static route for VPN subnet (10.0.10.0/24) pointing to 192.168.21.10 [*]192.168.20.2 - 192.168.20.9: Various hosts [*]192.168.20.10: Ubuntu with OpenVPN 2.3.2 in server mode. Firewall (iptables) is basically empty and all policies are allow[/list] When I initiate a ping from, say, 192.168.20.9 to 192.168.21.9, and then listen for ICMP packets using Wireshark on 192.168.21.9, the ping packets are apparently coming from the Server Facility's OpenVPN server IP address (192.168.21.10), but I was expecting the pings to come from 192.168.20.9. The pings get responses, it's just their origination IP that concerns me. I think it means NAT is enabled somewhere on the Server Facility's OpenVPN server, but I don't why or how to stop it. When I initiate a ping in the opposite direction (from the server subnet into the client subnet), the ping has the desired originating IP address. [oconf=Server Configuration]port 1195 proto udp dev tun ca ca.crt cert server.crt key server.key dh dh2048.pem server 10.0.10.0 255.255.255.0 keepalive 10 120 comp-lzo verb 3 client-to-client push "route 192.168.21.0 255.255.255.0" push "route 192.168.20.0 255.255.255.0" route 192.168.20.0 255.255.255.0 client-config-dir ccd[/oconf] [oconf=Client-specific Configuration File on the Server]iroute 192.168.20.0 255.255.255.0[/oconf] [oconf=Client Configuration]client dev tun proto udp remote server.mydomain.com 1195 lport 8374 ca ca.crt cert client.crt key client.key ns-cert-type server comp-lzo[/oconf]

Pings from client are NATed and I don't understand why

rtgamber

I have two server facilities (192.168.20.0/24 and 192.168.21.0/24) and I was able to connect the two of them using routing. Almost everything works perfectly; I can ping every host from every other host. My problem is that pings from the client subnet (192.168.20.0/24) are emerging into the server subnet as though they are from the server gateway (192.168.21.10). This unexpected NATing is causing problems with one of my applications.

Client Facility (192.168.20.0/24):

192.168.20.1: Router with some static routes.
Static route for the Server Facility subnet (192.168.21.0/24) pointing to 192.168.20.10
Static route for the VPN subnet (10.0.10.0/24) pointing to 192.168.20.10
192.168.20.2 - 192.168.20.9: Various hosts
192.168.20.10: Ubuntu with OpenVPN 2.3.2 in client mode. Lots of firewall (iptables) rules, but I am pretty sure the rules allow forwarding from LAN/eth0 to VPN/tun0 and vice versa)

Server Facility (192.168.21.0/24):

192.168.21.1: Router with some static routes.
Static route for Client Facility subnet (192.168.20.0/24) pointing to 192.168.21.10
Static route for VPN subnet (10.0.10.0/24) pointing to 192.168.21.10
192.168.20.2 - 192.168.20.9: Various hosts
192.168.20.10: Ubuntu with OpenVPN 2.3.2 in server mode. Firewall (iptables) is basically empty and all policies are allow

When I initiate a ping from, say, 192.168.20.9 to 192.168.21.9, and then listen for ICMP packets using Wireshark on 192.168.21.9, the ping packets are apparently coming from the Server Facility's OpenVPN server IP address (192.168.21.10), but I was expecting the pings to come from 192.168.20.9. The pings get responses, it's just their origination IP that concerns me. I think it means NAT is enabled somewhere on the Server Facility's OpenVPN server, but I don't why or how to stop it. When I initiate a ping in the opposite direction (from the server subnet into the client subnet), the ping has the desired originating IP address.
port 1195
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.0.10.0 255.255.255.0
keepalive 10 120
comp-lzo
verb 3
client-to-client
push "route 192.168.21.0 255.255.255.0"
push "route 192.168.20.0 255.255.255.0"
route 192.168.20.0 255.255.255.0
client-config-dir ccd iroute 192.168.20.0 255.255.255.0 client
dev tun
proto udp
remote server.mydomain.com 1195
lport 8374
ca ca.crt
cert client.crt
key client.key
ns-cert-type server
comp-lzo

rtgamber

Figured out the problem(s):
1) I didn't know what I was doing with iptables. There was a "nat" table which had a postrouting rule to masquerade/NAT traffic. When I removed the rule everything worked. I had incorrectly assumed that when I ran 'sudo iptables -L', it would show me *all* the rules, which is how I came to the conclusion that there wasn't a postrouting rule. When I ran 'sudo iptables -L -t nat', it became apparent there was a postrouting rule.
2) I had installed the iptables-persistent package which periodically rewrote my firewall rules to a configuration I used long ago. So, after I had set rules manually using iptables, they would magically be screwed up again a few hours later.

Removed the postrouting rule, uninstalled iptables-persistent and it works great.

TinCanTech

Well done and thanks for letting us know your solution 8-)