On 6/15/07, Chuck Swiger <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>
> 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
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
