iptables redirect traffic from VPN interface to next interface

Question

Can you help me with this problem please? I need redirect all traffic from tun0 interface (OpenVPN tunnel) to eth1 interface. eth1 is internal network behind this system which works as special firewall... If I use this rule (now only for testing purposes - destination port 80):

iptables -t nat -A PREROUTING -i tun0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.199.115.146

traffic from VPN pass correctly. I see it in iptables statistic (iptables -L -v), but reverse traffic does not pass. iptables shows this error:

99689.703349 x_tables: ip_tables: tcp match: only valid for protocol 6  

I need redirect all traffic from machine behind firewall only via tun0 interface. I use this rule too:

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE   

I have enabled ip_forward. If I use rule only with -p tcp without -m tcp I see in iptables statistic activity in the rule iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

interfaces

VPN Server (A):

eth0      Link encap:Ethernet  HWaddr 00:...
          inet addr:MY_PUBLIC_IP  Bcast:MY_PUBLIC_IP.255  Mask:255.255.255.0
          inet6 addr: .../64 Scope:Global
          inet6 addr: .../64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:41909528 errors:0 dropped:0 overruns:0 frame:0
          TX packets:373639 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2150448064 (2.1 GB)  TX bytes:185713075 (185.7 MB)
          Interrupt:10

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.1.1.1  P-t-P:10.1.1.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:82014 errors:0 dropped:0 overruns:0 frame:0
          TX packets:164251 errors:0 dropped:24 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:5945388 (5.9 MB)  TX bytes:147587733 (147.5 MB)

on firewall machine:

eth0      Link encap:Ethernet  HWaddr 08:...
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:189399 errors:0 dropped:0 overruns:0 frame:0
          TX packets:103528 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:180399131 (180.3 MB)  TX bytes:14844868 (14.8 MB)


tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.1.1.2  P-t-P:10.1.1.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:153314 errors:0 dropped:0 overruns:0 frame:0
          TX packets:80986 errors:0 dropped:8 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:145341797 (145.3 MB)  TX bytes:5818996 (5.8 MB)

eth1      Link encap:Ethernet  HWaddr 08:...
          inet addr:10.199.115.1  Bcast:10.199.115.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6890 errors:0 dropped:0 overruns:0 frame:0
          TX packets:23022 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:710721 (710.7 KB)  TX bytes:43966879 (43.9 MB)

machine B:

eth0      Link encap:Ethernet  HWaddr 08:...
          inet addr:10.199.115.146  Bcast:10.199.155.255  Mask:255.255.255.0
          inet6 addr: .../64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:24185 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8044 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:29645960 (28.2 MiB)  TX bytes:842414 (822.6 KiB)

Schema:

VPN server (A) /eth0 - public IP, tun0 VPN/ <-> Firewall (F) /tun0 VPN, eth1 - internal network/ <-> Server (B) (eth0 - internal network)

Communication which is initialized from machine behind the firewall works ok. Thank you very much for your help.

Routing tables:

VPN server A: - is VPS server

10.1.1.2 dev tun0  proto kernel  scope link  src 10.1.1.1
MY_PUBLIC_IP.0/24 dev eth0  proto kernel  scope link  src MY_PUBLIC_IP
10.199.115.0/24 via 10.1.1.2 dev tun0
default via MY_PUBLIC_IP.1 dev eth0  metric 100

///one physical server

Firewall F: is virtual machine VirtualBox Ubuntu - eth0 is VirtualBox NAT, but I need use tun0 and eth1 is local network for B

0.0.0.0/1 via 10.1.1.1 dev tun0
default via 10.0.2.2 dev eth0  metric 100
10.0.2.0/24 dev eth0  proto kernel  scope link  src 10.0.2.15
10.1.1.1 dev tun0  proto kernel  scope link  src 10.1.1.2
10.199.115.0/24 dev eth1  proto kernel  scope link  src 10.199.115.1
MY_PUBLIC_IP via 10.0.2.2 dev eth0
128.0.0.0/1 via 10.1.1.1 dev tun0

B machine on eth1 side (no eth0) is virtual machine Debian 7

default via 10.199.115.1 dev eth0 proto static
10.199.115.0/24 dev eth0 proto kernel scope link src 10.199.115.146

Route for packets should be as much as possible transparent even invisible...

iptables rules:

on VPN Server (A):

only table NAT:

-P PREROUTING ACCEPT
-P POSTROUTING ACCEPT
-P OUTPUT ACCEPT
-A PREROUTING -i eth0 -p tcp -m tcp --dport 0:1192 -j DNAT --to-destination 10.1.1.2
-A PREROUTING -i eth0 -p tcp -m tcp --dport 1195:65535 -j DNAT --to-destination 10.1.1.2
-A PREROUTING -i eth0 -p udp -m udp --dport 0:1192 -j DNAT --to-destination 10.1.1.2
-A PREROUTING -i eth0 -p udp -m udp --dport 1195:65535 -j DNAT --to-destination 10.1.1.2
-A POSTROUTING -s 10.0.0.0/8 -o eth0 -j MASQUERADE

FILTER table

is empty 

MANGLE table

is empty

on firewall (F):

currently after last modification

NAT table:

none

FILTER table

contains many specific rules for mitigation etc...  

MANGLE table

is empty

on machine B

without iptables rules

Answer 1

Server A lacks a route suggesting to connect to network 10.199.115.0/24 through VPN, thus uses its default route (i.e., try to reach B through your public IP).

Try to see if running

ip route add 10.199.115.0/24 via 10.1.1.2

on server A will allow connecting from A to B (without any NAT rule on firewall F)

If this works, you can set up openvpn to automatically create the route for you when you start the connection from A

An explanation of what happens in your configuration.

Here it is how the routing/NAT happens in the three cases

Case 1: B pings PUBLIC_IP

• The packet leaves B using the default route, because it is the only one that matches PUBLIC_IP. It is sent to be routed at the IP address 10.199.115.1, with final destination PUBLIC_IP, and source address 10.199.115.146.
• The packet is routed by F. Many routes apply: the most specific one is PUBLIC_IP/32 which sends the packet to be routed at the machine 10.0.2.2 on eth0, which I guess it is machine A (the connection underlying openvpn).
• Machine A receive the packet, and reply back to the source address 10.199.115.146. Without the rule I showed you, this would be interpreted as an internet address, and thus the reply would be sent over the internet.
• using the route I proposed, the packet goes back through tun0 to machine F. Machine F routes this back to eth1 where machine B receives the reply packet. However, its source is marked as 10.1.1.1, thus it is not recognized as the reply to the original packet. Ping failed.

Case 2: B pings 10.1.1.1

• Same as before, the packet leaves B to be routed by F
• This time the destination matches the rule 10.1.1.1/32, so the packet is sent through tun0
• As the packet is going out through tun0, the MASQUERADE rule kicks in, changing the source for the packet as 10.1.1.2. (this isn't needed if using the route rule I proposed, see below).
• Machine A receive the packet, and replies back to 10.1.1.2 (machine F). Without MASQUERADE this would be sent back to 10.199.115.146. With my proposed routing table entry this wouldn't change much, because the package would be sent to 10.1.1.2 for routing nevertheless, however if you don't have either the destination 10.199.115.146 would be routed through internet.
• The reply packet is received by machine F. If masquerade was performed, the packet is recognized as reply and its destination address is changed back to 10.199.115.146. The packet is routed through eth1 to its final destination.
• Machine B recognize this as the reply packet. Ping successful.

Case 3: A pings 10.199.115.146

• Without my proposed rule, the original packet is sent to the internet, and lost. Otherwise it is sent to 10.1.1.2 for routing, with source address = 10.1.1.1.
• Machine F receives the packet and routes it through eth1.
• The packet is received by B and a reply is sent to 10.1.1.1.
• The reply is routed through tun0. The MASQUERADE rule changes the source address to 10.1.1.2.
• Machine A receives a reply from 10.1.1.2, which is not the original destination, and discards it as unrelated. Ping failed

As you can see, there is 2 ways to connect machines from internal network to VPN:

• Public Routing: Both networks know each other's IP address, and they have specific route table entries to find them (as the one I showed you).
• SNAT/MASQUERADE: Only one network know how to reach the other, and the firewall changes the source IP address of outgoing packets from that network to the firewall's own IP (which is known by the other network).

Don't use both. If you use SNAT/MASQUERADE the routing tables on external hosts are not applicable because the packet coming from the private network are never using the original address as source.

You can choose whether machine A should be reachable from B using PUBLIC_IP or 10.1.1.1. Maybe it is possible to configure the firewall such that both will work, but it is probably not worth the effort.