Mythokia

I configured and installed Ubuntu Server 8.04 with the typical LAMP setup with the intend of mirroring this blog locally so I could test out a few changes without affecting the live copy and placed the server virtualized, behind the Vyatta router.

Back on my desktop, I was greeted with a previously unseen error as I navigated to the site.

I verified that Apache was running with a ps aux | grep apache, and indeed it was. I checked that I was able to access the page from machine on the same subnet. At this point, I suspected it was an issue with the Vyatta router, although its rather puzzling since all traffic initiated from the 192.168.5.0 network, internet bound or otherwise seemed to be working fine.

Carrying out tcpdump on the Ubuntu server, it seems that the first SYN packet from 192.168.1.50 was received, and judging from the subsequent similar (they all have same sequence numbers) SYN-ACK packets that were sent out from the server, it was clear that server never heard from 192.168.1.50 any further. One of the following could’ve happened:

1. The SYN-ACK bound for 192.168.1.50 never arrived at its destination.
2. The SYN-ACK packets arrived at 192.168.1.50, but the ACK respond required to complete the handshake never made it back to the server.

Carrying out a tcpdump dump similarly on eth0 of Vyatta, I was able to verify that the packets were following both ways, which took the fault of the router of the question. All was well with it.

I don’t know why I didn’t look at this earlier, but when you install a sparkling new piece of equipment and it something doesn’t work, you would automatically lay blame to that equipment instead of examining the complete picture closely, exactly like the old rhetoric “it used to work until I <insert something that you recently just did here>”. I ran Wireshark, which is a GUI version of a packet capturing tool much like tcpdump on my desktop itself. What showed next was the reason behind all my problems.

Wireshark showed that my IPCop router was sending me an ICMP redirect for every packet I sent out destined for 192.168.5.3. It was then that it occurred to me that since the Vyatta router had an interface in the same network as my computer, IPCop was telling me that that shorter route to the 192.168.5.0 network was to send it directly to the gateway at 192.168.1.150 instead of sending it to the default gateway specified on the desktop of 192.168.1.1 aka IPCop and then have it rerouted.

It turns out that on Windows if the Windows Firewall is turned on, ICMP redirects are dropped by default. As a routing mechanism, ICMP redirects have no security built in and hence, are vulnerable to IP spoofing attacks. So although an ICMP redirect was sent to my computer, it was silently dropped and the message never got through.

To get around this problem, the firewall could simply be enabled to accept ICMP redirects. Despite the security issues with it, it is rather safe on a small LAN where every computer comes under my control and ICMP requests are not forwarded by the exterior facing router into the network. Alternatively, an entry could be added in the Windows routing table.

route -p add 192.168.5.0 mask 255.255.255.0 192.168.1.150

It turns out to be a simple and small issue, but it took the better part of an afternoon to solve. Its all about the learning experience I guess, that’s what the network was setup for in the first place.