Bryan Irvine wrote: > On 3/10/06, Steven S <[EMAIL PROTECTED]> wrote: >> Bryan Irvine wrote: >> ... >> ... >>> It happened after we installed the carp firewalls, and seems to be >>> related to ICMP-Redirect coming from the real IP, as opposed to the >>> carp one the request went to. >>> >> ... >> >> Interesting, in my experiments carp interfaces didn't send ICMP >> redirects at all... > > The CARP interface is not. I'm not sure if it's supposed to or not. > I'm guessing because that is the only thing that has changed. With > the exception of the carp and pfsync rules, this is the exact same > ruleset from the old firewall. > > here's what I see on the firewall when I try a traceroute to a remote > network that goes through a different gateway. > > 17:51:50.581658 10.0.0.2 > 10.0.253.236.kent-dhcp.kcjn.com: icmp: > time exceeded in-transit 17:51:50.585106 10.0.0.2 > > 10.0.253.236.kent-dhcp.kcjn.com: icmp: time exceeded in-transit > 17:51:50.585402 10.0.0.2 > 10.0.253.236.kent-dhcp.kcjn.com: icmp: > time exceeded in-transit > > The results of the traceroute: > 1 10.0.0.2 (10.0.0.2) 0.971 ms 0.268 ms 4.880 ms > 2 10.0.0.201 (10.0.0.201) 0.508 ms 0.503 ms 0.359 ms > 3 172.19.1.10 (172.19.1.10) 111.714 ms 111.264 ms 111.691 ms > 4 172.19.4.10 (172.19.4.10) 111.331 ms 113.438 ms 111.278 ms > > > Am I missing something or barking up the wrong tree? > > --Bryan
I experienced similar issues. The carp interface does not send an ICMP redirect (I have not had the time to find out why) but instead routes the packet, creating state if you're running PF. My users experienced "slowness" so I ended up adding static routes on the servers (only about 5 of them) for the short-term. There appears to be two things broken, ICMP redirects and routing back through a carp interface. -Steve S.
