Friday, September 22, 2006
The broadcast address is NOT the netmask
I was able to finally solve the issue with XXXXXXXX. 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 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 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.
There's that word again …
“It should only take a minute,” said Smirk.
That was almost an hour ago.
It still isn't done.
Murphy strikes again.
