* * * * *
The broadcast address is NOT the netmask
I was able to finally solve the issue with XXXXXXXX [1]. It was an odd
problem though—they could get to some sites, not to others. Even wierder, I
could get to their router from outside, but not their firewall, even though
both were in the same network block. I could ping the firewall from the
router, but the implementation of ssh on Cisco routers is … well … pathetic
so that's not really an option.
I was able to ping the firewall from an ISP (Internet Service Provider) in
Boston.
Yup.
Boston (by the way, thanks Eve for not getting rid of the account—it comes in
handy from time to time).
And since I could ping it, I tried to ssh into it.
Success.
A few minutes later, and I'm looking at the routing table of the firewall.
> Kernel IP (Internet Protocol) routing table
> Destination Gateway Genmask Flags MSS Window irtt Iface
> XXXXXXXXXXXXX 0.0.0.0 255.255.255.252 U 40 0 0 eth0
> 66.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 eth1
> 0.0.0.0 XXXXXXXXXXXXX 0.0.0.0 UG 40 0 0 eth0
>
How odd. Every IP address between 66.0.0.0 and 66.255.255.255 is being routed
back to XXXXXXXX's firewall. How did that happen?
I come to find out that they had a power outtage a few days ago, and that's
when their problems started. I check the startup scripts and lo', I had
specified a broadcast address in lieu of a netmask. The command to configure
the interface rejected the value for the netmask and picked a default mask
based upon the IP address (the address falls into the old class “A” network,
which has a default mask of 255.0.0.0).
Ah.
Well then.
That would certain explain why they were able to get to some sites but not
others. And it would explain why I was unable to get into their firewall from
The Office or Casa New Jersey (as both locations fall into the 66.0.0.0/8
network block).
Ahem.
It was an easy fix.
[1]
gopher://gopher.conman.org/0Phlog:2006/09/21.1
Email author at
[email protected]
