Life gives us constant reminders to go back to basics and in the computer world it’s no different. My laptop has two network interfaces built in, an intel gigabit interface that FreeBSD calls em0, and an intel 802.11b wifi interface that FreeBSD calls ipw0. Usually I need either the gigabit interface or the wifi interface. I’ve never needed both. When I move about the house I sometimes have to switch in between them. The architecture of my network makes that a little more complicated and when I switch without rebooting I have to remember to get back to basics or I could waste some serious coffee time.
It’s the network dummy
My network is a logical cidr/23 divided into two physical cidr/24’s by an OpenBSD bridge which does packet filtering. That gives me the classic firewall spaces: a DMZ network connected directly to the internet and a protected network which is behind both the filter on the internet gateway and the DMZ filter. Using a bridge allows me to make the DMZ filter transparent. As far as a node on the protected network is concerned there it’s on the same switch as the hosts that it talks to in the DMZ. If a host in the DMZ tries to connect to something in the protected network it only passes if the filter allows it. When the connection is blocked the filter responds as though the port is closed on the protected client.For most clients this design is pretty simple. They see a single LAN with a router that gets them to the internet. It’s nice from the outside also. I can build an IPSec tunnel to a partner without seriously compromising the security of my protected LAN. But the lesson here is that hidding complexity does have a cost.
The problem always starts the same way. I unplug the ethernet cable from my laptop. FreeBSD stops dhclient from running on the em0 interface but leaves the interface running. This is just in case I’m running downstairs to plug in at a different jack. Instead I load the kernel module for the ipw interface and then configure it with my WEP keys and fire off a new dhclient. The Dhclient finds the server, modifies the DNS configuration, and silently fails in the attempt to modify the routing table. Dhclient stalls in the protocal waiting for a packet and I think that it’s some sort of transient. Now’s the time to go back to basics.
Debugging simple ip connection problems.
I’ve moved to place where there isn’t a wired jack, switched from wired to wifi and my internet connection no longer works. Firefox gives me the “I can’t find your server screen.” Try these before a reboot.
- Start from the inside:Â Is the configuration correct on the wifi card? Check with ifconfig:
$ ifconfig ipw0
ipw0: flags=8843 mtu 1500
inet6 fe80::204:23ff:fe7a:c9d2%ipw0 prefixlen 64 scopeid 0x6
inet xxx.yyy.zzz.67 netmask 0xfffffe00 broadcast xxx.yyy.zzz.255
ether 00:04:23:7a:c9:d2
media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps)
status: associated
ssid Vindaloo-WVLAN channel 10 bssid 00:04:5a:0f:34:fe
authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit wepkey 2:104-bit
wepkey 3:104-bit wepkey 4:104-bit txpowmax 100 bintval 100
Ok, that looks good. - Cut out the resolver:Â The best thing one can do when trying to isolate tcp/ip connection problems is to cut out the resolver early in the process and come back to it when you know the lower levels are correct. We treat name resolution like its a part of the media (layer 2) but it’s not. The name resolver is an application (layer 7) and it’s subject to failure in all of the lower levels.
Memorize the addresses of a few hosts both on the internet and on the LANs that you connect to. When testing ping by address if pinging by name doesn’t work. Also be aware of the resolver’s timing. If something takes exactly 1 minute 15 seconds to fail your resolver configuration is probably corrupt.
In my case ping of all addresses failed. - Really check the configuration:Â Understand that the configuration check in the first step was lightweight. If ifconfig says everything is all right the next place to look is probably the route table. In my case running the route program would have shown that the kernel was trying to get packets to the network through the em0 interface which is marked down but still has a route for my network. This happens on my network because the wifi network and the wired network are the same.
Downsides
The DMZ gateway here becomes a single point of failure and that creates a rather big downside. The problem isn’t that if the DMZ fails that the clients can’t get to the internet. In that case discovering what the problem is will be easy. So having reliable hardware at that point will be critical. In the worse case that box is only a patch cord with filtering anyhow. The insideous problem is that your network has two protection plateaus: a somewhat protected DMZ; and a somewhat more protected plateau for clients and insecure services like smb/cifs. If you are thinking about security and you have this as your infrastructure there will be a great and proper temptation to locate some very useful services on the protected network. That generates more holes in your filter and means that even more is lost if the filter fails.
My Waterloo: LDAP
When I first met LDAP, the database that really isn’t a database, I turned my nose up at it. In my applications software engineering world the relational database was the Shangri-La of storage. From where I sat LDAP looked like an overcomplicated, X.500 based steaming pile of cruft. But as buzzwords go LDAP wasn’t going away. So in early October of 2001 on a somewhat nervous plane ride from Newark, NJ to San Diego, CA, I decided to use the incommunicato 6 hours flight to get to know openldap. After a couple of days I got the point where I could put data into the LDAP box, search for it and take it out but not much more. The problem of the day was authentication. Everyone did authentication differently which meant that every user had one a set of credentials for each application. And the help desk spent most of it’s time reaquanting people with those credentials. Furthermore every application had to have functions committed to updating those credentials. It was obvious then that this situation was not optimal. If you people to be in-secure the best way to go about it is to make security difficult for the users. My personal problem had to do with managing users on a Samba server. To change a password I had to log into a shell, su to root, and then use passwd program with the user present. I was also managing several web applications. One of these managed authentication and hashed it’s passwords into a relational database. In the long run this was just way too much work. The second problem is that nearly no one does authentication right. Back when I was a pup playing with AIX in Chicago I was a huge advocate of rsh instead of telnet. And the one reason that I liked rsh was because it didn’t pass your password in the clear on the ethernet hub environment of the time. And we did get cracked and the cracker got everyone’s password in the building except mine. Now we have switches, but we also have wifi, and we have ssh which puts the entire argument to bed. But eleven years later in 2006 when people write a new application and design their own authentication the best that they can come up with still passes a password on the wire. Thankfully most applications are smart enough to at least use SSL for that part of the transaction.