This short post is about the dilemma a coworker of mine just had this morning regarding network packets, and a not fully functional IPCop Linux installation.
The server runs IPCop, which allows a PC to run as a firewall appliance. The IPCop server has 2 NICs, eth0 and eth1. Eth0 is connected to a Class A private LAN while eth1 uses a Class C address to connect to the public Internet. The problem however is that the Internet is accessible (Google, Yahoo! etc.) but not private LAN machines and addresses. The private LAN’s gateway return ping replies, but not the DNS server.
Detective Work (i.e. Troubleshooting)
What I did was to check all possible causes for this problem: restart the network, checked logs for error messages and others, though some of these had already been done, but I just want to be doubly sure myself. I next checked the firewall using the iptables command. There were tens of lines of firewall rules, along with numerous chains. Since I was in a hurry at that time, I decided to skip the detailed checking of the firewall rules for the moment, even hough I have experience dealing directly with iptables, and not with the higher level application firewalls that just modify it. Next I tried to ping again the DNS server. Adding a -v in the ping command to make it more verbose, I noticed that packets were being successfully sent to the DNS server, but no packets were coming back. I thought to myself that the iptables firewall is one good suspect for this, but I’ll try a few more checks before I go to the nitty gritty of iptables firewall rules. I did ifconfig ethX up and then down but to no avail. Replace the X with the NIC number you wish to up/down.
I next checkd the routing table using the very useful route command. The static IP route looked fine, but I noticed that it was rathe incomplete, given that it has 2 NICs. What I mean by incomplete is that the route from the public, Class C network has routes for going in and out of the destination network and host, but the private LAN doesn’t have a route for traffic going into the IPCop server. It only has a route for traffic coming from the Class A private LAN NIC. Bingo was its name-o. 🙂 Apparently the reason why ping packets weren’t making their way back to the IPCop server was that they weren’t being routed correctly back to the IPCop server itself. This was further supported by using the traceroute command. I traceroute-ed the private LAN DNS server and as expected, the routing of the packet was all messed up. The traceroute packets for the private LAN DNS server were exiting through eth1, and out to the public Internet already. No wonder it doesn’t have a private LAN connection! 🙂
So the fix was to add a correct route to the routing table using the route command. The new route should, well, route the packets correctly from the private LAN back to the IPCop server, and to make sure that the class A private LAN traffic enters/exits via the eth0 NIC. To do this the command
route add -net NETWORK netmask NETMASK gw GATEWAY
was used. Just replace NETWORK, NETMASK, and GATEWAY with the appropriate values for your network. In our case, NETWORK was the destination host ( the local machine, given by 0.0.0.0) and GATEWAY was the gateway of the Class A network of the private LAN.
Sure enough, after adding that static route, the Class A private LAN became accessible. 🙂