Home / server / Questions / 710137
Accepted
rlib
Asked: 2015-08-02 01:24:26 +0800 CST

UDP packet comes to VPN interface and is not delivered to the process

  • 772

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?

iptables

2 Answers

  1. Best Answer

    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.
    • 2

  2. 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
    • 0