I have a udp forwarding to a VM with the rule

iptables -t nat -A PREROUTING -i eth0 -p udp -m udp --dport 42000:42020 -j DNAT --to-destination
iptables -t nat -A POSTROUTING -s -j MASQUERADE
iptables -A FORWARD -d -p udp --dport 42000:42020 -j ACCEPT
iptables -A FORWARD -s -j ACCEPT

In the VM is are openvpn servers listening on these ports.

Now I have a strange problem with the forwarding on the host: Some packets are routed between the interfaces and some are not, without a clear pattern why.

  • One VPN connection is working just fine. tcpdump shows packets on eth0 and vmnet on the host and inside the VM.
  • Three VPN connections are getting peer packets on eth0 which are not routed to vmnet and vm packets on vmnet which are not routed to eth0.
  • UDP packets with the same sourceport and packet length as one of the failing connections sent via netcat are logged on eth0, vmnet and inside the VM just fine.

What can I try to find why the packets are not routed to the other interface?


The problem has two parts:

First libvirt inserted a firewall rule with

- j MASQUERADE --to-port 1024-65535

which changed source ports, which do not match other rules and cause errors in openvpn.

The complicated part is, why disabling this did not work. And there the conntrack table kept the information about the source port alive. I guess the packets from the peer, which were still coming in trying to reconnect, updated the entry in the table.

When I ran conntrack -D (be careful, this will drop all tracked connections), the packets started to have the correct source port. Note that conntrack cannot ensure the source port, but if available tries to use the original one, if no --to-ports parameter is used.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.