1

I have a server X (45.55.245.182) which is connected to server Y by VPN. VPN interface on X is tap0 with ip 10.200.0.2; VPN interface on Y is tap0 with ip 10.200.0.1. I run netcat on server Y to listen to UDP 35000:

nc -lu 10.200.0.1 35000

On server X the packets of port 35000 are DNAT'ed with the following rule of iptables:

iptables -t nat -A PREROUTING -p udp --dport 35000 -j DNAT --to-destination 10.200.0.1

Running tcpdump on server Y on its tap0 interface shows the packets come as expected:

11:54:44.000610 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.200.0.1 tell 10.200.0.2, length 28
11:54:44.000638 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.200.0.1 is-at fa:0f:00:1a:57:59 (oui Unknown), length 28
11:54:44.154702 IP (tos 0x8, ttl 47, id 52840, offset 0, flags [DF], proto UDP (17), length 34)
    hotnet-213-57-17-185.hotnet.net.il.24740 > 10.200.0.1.35000: [udp sum ok] UDP, length 6

See the diagram showing setup: enter image description here

However, I cannot see that listening netcat on the server Y get the data (nothing echoes on the screen of Y when I press enter on the client).

What can be a problem?

2 Answers 2

2

The most likely explanation for your problem is the rp_filter, which is enabled by default. Server Y receives the packet on tap0, but according to its routing table, the packet was supposed to arrive on a different interface (likely eth0).

If this is indeed your problem, then the solution is to disable rp_filter for tap0. First try this to see if the problem goes away:

echo 0 > /proc/sys/net/ipv4/conf/tap0/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

Once you get Server Y to accept the packet. You may face a problem with the client rejecting the reply due to coming from the wrong IP address. There are different solutions to that problem.

If you choose to use SNAT on server X it will solve both problems. But there are two caveats.

  • Server Y will not know the IP address of the client.
  • Replies to the client will have to take the long way through server X to get back to the client, which may be less efficient than routing them directly back to the client.
3
  • Thanks for your reply! The problem has been solved by SNAT'ing source address to 10.200.0.2.
    – rlib
    Aug 1, 2015 at 10:24
  • @rlib That's another way to get around the rp_filter. That is of course only a usable approach if Server Y does not need to know the IP address of the client.
    – kasperd
    Aug 1, 2015 at 10:32
  • And yes, disabling rp_filter on tap0 also solves the problem! Great thanks!
    – rlib
    Aug 1, 2015 at 11:30
0

Setting source address to 10.200.0.2 from which actually the packet arrived solved the problem:

iptables -t nat -A POSTROUTING -p udp --dport 35000 -j SNAT --to 10.200.0.2

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .