Serious packet loss issues when 1:1 is enabled.
-
I've confirmed this using both CARP and Proxy-ARP. Beta2.
I create a virtual IP address for the server. I create rules to allow traffic to pass to the server (using the LAN IP address of the system, not the virtual IP), and very strange things start to happen.
Name lookups, ssh, voice traffic, all break down badly. If I allow ICMP, I'm losing a good 2/3 of the packets. If I ping from the machine out to the firewall's gateway (ie, the next hop upstream) the packets I get back take over a millisecond to return, and I don't get all of them back. The problem immediately ceases as soon as I disable the 1:1 NAT entry. Very bizarre. Unfortunately I'm stuck in a situation where I can't route the public IP's and will be that way for ~6 more weeks. :( My upstream provider is totally clueless about routing. Scary stuff.
So 1:1 NAT I must. Is this a known behavior? It seems to me that allowing ICMP traffic to return correctly might be an outbound NAT issue, but if I set up 1:1, it should automatically appear to be coming from the external IP of the 1:1 entry, correct?
What's more, I was getting an error scrolling in my logs like this:
kernel: arp_rtrequest: bad gateway x.x.x.x !AF_LINK
I searched for that, and of course it complains about arp table weirdness, which would make sense with the problem I'm having. It could be that layer 2 is getting hosed up getting back to the interface, but I've tested all of my cables, leaving the switch which is, sadly, an unmanaged switch.
Thoughts?
-
I've further narrowed the cause of the problem. I've turned off 1:1, and instead I've enabled advanced outbound NAT. I added a new rule and placed it in front of the default rule, stating that traffic coming from this machine on the inside should be seen as the virtual IP address I've added. As soon as I do this, i get packet loss. Turn it off, packets flow fine again.
This is really odd.
-
I run both 1:1 and advanced outbound on the same firewall… I am not seeing this.
-
I'm not seeing it on my other boxes either. Really makes me wonder. I'll reply here if I figure out what's causing it, but for now I cannot assign a public IP to that machine until I can clue in my provider of how to set up routing.
-
Resolved. I did something dumb, and yet it's probably a common mistake when setting this sort of thing up even though there's a warning sitting there.
The virtual IP I assigned was in a /26. When I set up the carp IP, I set it up as a /32 (even though it says to use the REAL subnet mask).
Oi. Drove me nuts. Packet loss, begone!
-
Unfortunately we cannot cure the world of not reading :/
-
We need to make our textx more interesting to ready, maybe some boops would help ;D