Hi. I recently inherited a 3 year old FreeBSD box running a firewall/
load balancer. I attempted to replace it with an IP tables based firewall
running on openSuSE 10.3. I encountered the following issue. Any help
would be greatly appreciated.
The machine has 2 physical NIC cards with the following IPs:
Physical NIC 1:
---------------
.11 (eth0)
.12 (eth0:1)
.13 (eth0:2)
Physical NIC 2:
---------------
192.168.1.1
Listening on .11 is DNS and on .12 is HTTP. .13 was the IP used by
developers to access machines inside the firewall. I didn't test this IP
extensively.
After we replaced the old firewall with this new one, everything ran fine
for 10 hours. No issues. After 10 hours, however, everything seemed to
stop responding. As we dug in to investigate it turned out that .11 was
now responding to HTTP traffic and .12 was responding for DNS - essentially
.11 and .12 had switched. We rebooted, tried a bunch of stuff and the
system never went back to responding to requests properly. We eventually
fell back to the old machine.
[We ruled out issues with iptables rules because the firewall ran fine for
10 hours with no issues and we cut out a lot of rules while testing during
the period when the machine was not responding properly.]
Physical NIC 1 is connected to a Cisco 2950 that services the public network.
Physical NIC 2 is connected to another Cisco 2950 that services our private
192.168.1.0/24 network.
I've built a test network and replicated almost everything. I cannot get
this issue to reproduce. The one part I could not replicate was the use of
2 Cisco 2950's. I think I have a 2900/XL on the private network and some
NetGear for what would be the public network.
I've been reading everything about ARP Flux, ARP caches, IP aliasing and
related kernel config parameters, etc. but I can't seem to figure out where to
go next or get a definitive answer.
Any help would be greatly appreciated!
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
