Date: Fri, 15 Jun 2007 16:21:27 -0700 From: "Kurt Buff" <kurt.buff@gmail.com> To: "Chuck Swiger" <cswiger@mac.com> Cc: FreeBSD <freebsd-questions@freebsd.org> Subject: Re: OK - I'm fairly clueless on this... Message-ID: <a9f4a3860706151621v2b1b3bf7ya6f43f80b64e99c0@mail.gmail.com> In-Reply-To: <EC74488D-94E8-4439-8CC4-17498DE1FD3C@mac.com> References: <a9f4a3860706151215ydf80c00j80c6342eabd01418@mail.gmail.com> <20070615215116.A63508@wojtek.tensor.gdynia.pl> <4672F1F0.4090707@joeholden.co.uk> <a9f4a3860706151314y6f1e195ah1726db59cb3f72e0@mail.gmail.com> <EC74488D-94E8-4439-8CC4-17498DE1FD3C@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6/15/07, Chuck Swiger <cswiger@mac.com> wrote: > On Jun 15, 2007, at 1:14 PM, Kurt Buff wrote: > >> >> traceroute to www.freebsd.org (69.147.83.33), 64 hops max, 40 byte > >> >> packets > >> >> 1 www.freebsd.org (69.147.83.33) 1.050 ms 0.970 ms 2.110 ms > >> > > >> > very short times suggest that the router (possibly NAT machine as > >> > 192.168 suggest) is doing strange things... > >> Do you have a bogus rdr/fwd in your config anywhere? > >> -- > >> Joe Holden > >> T: (UK) 02071009593 (AU) 282442321 > >> E: joe@joeholden.co.uk > > > > Uh, don't know what those are, and I built this machine myself, from > > scratch, so I doubt it. > > > > All it's got on it is postfix (for mailing daily reports) and squid. > > It's pointed to our new T1, out a Watchguard firewall - we're going to > > use the old T1 for mail and traffic to our branch offices. > > It would not be astonishing if your Watchguard firewall was blocking > or modifying the traceroute traffic and ICMP time exceeded packets > which result, unless someone has explicitly configured it to pass > traceroutes. > > However, the problem you've shown can also happen when something > things it should proxy-arp for all IPs, in other words, it will claim > that anything outside of the subnet it is actually on is really a > local IP and should go to that particular MAC address. > > Doing an "arp -a" and looking for dups should indicate whether this > sort of thing is happening... > > -- > -Chuck Problem solved, but this was indeed quite interesting. I've got several FreeBSD boxes scattered at various points through our network. After checking them, the ones that I had trouble with are those that are in the same subnet as our two firewalls. Doing a traceroute from the others worked just fine. However, 'arp -a' on the affected FreeBSD boxes (those in the subnet with the Watchguards) didn't reveal anything interesting. So, the Watchguards were doing *something*. OTOH, running tracert (the Windows version of traceroute) from a box on that same subnet worked just fine - that is, I get a full list of hops, etc. This is where the light started to shine.. I tried 'traceroute -P udp' and 'traceroute -P tcp', with no difference - that is, the machines in the same subnet got a single line back. However, if I specified 'tracert -I' (capital i - which means use ICMP) I get the output I expect from a traceroute command. As mentioned above, however, arp -a reveals no duplicates. Windows uses ICMP for its traceroutes, FreeBSD doesn't, by default, though it can. So, I took a look at my traceroute filter on the firewall, and found, finally, that it wasn't allowed from the subnet where my problem children were. I adjusted the filter on the firewall, and all is now happy. Thanks for your help, Chuck - it made the difference I needed to figure this out. Kurt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a9f4a3860706151621v2b1b3bf7ya6f43f80b64e99c0>