OK - I'm fairly clueless on this...

[Kurt Buff]

On 6/15/07, Chuck Swiger <cswiger at 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 at 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