Should conntrack-sync also sync NAT?

Bugs
, , ,
1

Hi

I’m testing a setup with conntrack-sync and vrrp. For connections which are not NATed it works, but the connections which are NATed they fail.

The routers is in VMware ESXi 5.5

This is tested on 1.0.5 and 1.1.1

It’s probably something I have missed so if anybody could point me to how to get stateful NAT I will be really happy :slight_smile:

Regards
Arne

2

Without rfc3768 mode, the arp caches of other systems need to change to pickup the new ip->mac mapping. RFC3768 mode solves that, but there is a bug for which I have a patch.

http://www.five-ten-sg.com/mapper/blog/vrrp

Can you check your arp cache? If the arp cache on 172.16.4.254 did not get updated, it might cause these symptoms.

You could verify that. On both master and backup routers, run two simultaneous dumps:

sudo tcpdump -i eth0 dst host $target
sudo tcpdump -i eth1 dst host $target

while from some system in 172.16.5.0/24, run “ping $target”. You should see the icmp packets incoming on eth1 and outgoing on eth0 on the master. Do a vrrp transition, and which vyos box sees the incoming pings, and does either box show outgoing pings?

3

To me it looks like the ARP is updated correctly. When I capture traffic on the interfaces when doing a transition the traffic switches over to the new master. Traffic which are not NATed works fine. The NATed traffic shows up on eth0 but does not go out on eth1.

4

Can you try http://www.five-ten-sg.com/util/VyOS-livecd-1501130922-69741b0-amd64.iso in rfc3768-compatibility mode? It seems to work for me. I setup two VMs from that iso, brought up an inbound natted connection into a server, and an outbound natted connection from a client, shutdown the master vrrp, and both natted connections survived.

I only use rfc3768-compatibility mode.

5

My testcases works with your iso. And it looks to be fine!