Hi,

I'm having troubles setting up an scenario because iptables suddenly stops doing nat as configured. I have discarded configuration error because it works for a while.

Let's say I have these TUN interfaces

xserver
inet addr:10.210.0.2 P-t-P:10.210.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1300 Metric:1



xclient
inet addr:10.200.0.2 P-t-P:10.200.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1300 Metric:1


these IPTABLES rules
-A PREROUTING -d 10.110.0.2/32 -i xserver -j DNAT --to-destination 10.210.0.2
-A PREROUTING -d 10.100.0.2/32 -i xclient -j DNAT --to-destination 10.200.0.2
-A POSTROUTING -s 10.200.0.2/32 -o xclient -j SNAT --to-source 10.100.0.2
-A POSTROUTING -s 10.210.0.2/32 -o xserver -j SNAT --to-source 10.110.0.2

I need these nat rules because both interfaces are in the same host, so if I didn't use fake IP addresses, the traffic to xserver wouldn't go through xclient and xserver, but delivered to xserver right away.

I have a process listening to each tun interface, because I do things with those packets.

These routes are defined in the host:

10.110.0.2 dev xclient scope link ## so, if sent to fake IP 10.110.0.2, the packet will go through xclient
10.100.0.2 dev xserver scope link ## so, if sent to fake IP 10.100.0.2, the packet will go through xserver

So, when sending sth. from xclient to xserver, I must target the fake IP of the xserver (10.110.0.2). When the IP packet is received by the process listening to xclient, the src IP will be the fake xclient IP (10.100.0.2). The server will receive a real dest. IP 10.210.0.2 (real xserver IP) and src IP 10.100.0.2 (fake client IP).


So, if I do
ping 10.110.0.2 , the ICMP will correctly reach 10.210.0.2, and be answered to 10.100.0.2, which in turn will reach xclient with dst IP = 10.200.0.2 and src = 10.110.0.2

If there's something wrong above, it has been an error writing the post: ping works, and even download of some files. The problem arises when I start several FTP downloads at the same time: it works for a while, but suddenly the process listening to the xclient interface starts receiving IP packets with src IP = 10.200.0.2, which should NEVER happen.

The question... am I missing something? is this a known bug related to using iptables nat with a tun interface? Is there a way to solve this, other than having my application rewrite IP headers (which would be really awful and scary).

Thank you in advance for any answer.

Dear What I understand is you have 2 machines with different IP networks on same switch???
Why don't you use any low cost router for this routing in between two IP networks???
please.

Correct me if I'm wrong but you are working with two virtual machines inside the host and you want to get traffic to get from the real world into the virtual machines, right?

If that's the case, provide us with this:



Now, going into simple stuff: are you managing the network? If that were the case, I'd try to use the VM host as a router to connect to the two boxes.. that shouldn't be too painful (and would avoid all nat stuff).

That means, set up two "public" (at least for the networks you need to work with) network segments that are reachable through the VM host.

Hi again,

first of all, sorry for the silence these days, I was sleeping a few hours per day and I forgot many pending issues I had those days. The day after asking I noticed there was a pattern to this behaviour and suddenly realized it all made sense, so I never thought again about this. And I am really sorry because you couldn't solve this right away with the provided information.

I'll give a few explanations here, if only because you spent time answering these and you deserve to know what happened.

First of all, the complete scenario:

* As I was saying, I had 2 TUN interfaces, with an IP address and a fake virtual address (not configured, but used to make IP packets enter a tun interface to reach the other after being processed by me). Both tun interfaces in the same (real) host.
* I observed that the issue always happened with TCP traffic, but not with ICMP. I mentioned ICMP, which might have been misleading; but what I wanted to say was that traffic routed to the fake virtual IP of xserver was going to be routed through xclient.
* The packets, when sent to xclient, were "processed" before another procees wrote them to xserver. There was a delay in such processing (in fact, they were not processed locally), but sent to another host, and then back to the first one. This means there was a small delay before the server received packets, and before ACKs were delievered to their destinations.


As a result, TCP was doing some retransmissions. The final clue was after watching a few pcap files of these events: it always happened after a connection was closed, with retransmissions (I believe the same happened with resets, can't remember right now, but makes sense).

Conclusion: iptables only does NAT with connections in a valid state. That is: the three handshake connection process, the end, and valid TCP traffic between those two points. After the connection is closed, it won't do NAT with retransmissions arriving late, or resets sent because a IP packet arrives for a connection that no longer exists.


On a side note, answering this:

Correct me if I'm wrong but you are working with two virtual machines inside the host and you want to get traffic to get from the real world into the virtual machines, right?

There wasn't 2 virtual machines, but an "application" to process that traffic, capturing from and writing to the TUN interfaces. The client and server behind both were just FTP clients and a server, and my problem was that I could not (well, I could but it was not the right way to do things) accept traffic from the real IPs, which should be unknown to me.

So, what I did was just adding rules to drop TCP packets which didn't belong to any valid connection:

-A OUTPUT -d 10.110.0.2/32 -o xclient -m state --state INVALID -j DROP
-A OUTPUT -d 10.100.0.2/32 -o xserver -m state --state INVALID -j DROP



Thank you for your time and again, sorry for the delay in my answer.