#59: Problems with lime-management.co.uk and Galileo
I got an interesting phone call last week at work. An colleague at one of our offices couldn’t get into a certain website (http://www.lime-management.co.uk) to make bookings. They could see the front page, but whenever they tried to log in, the site would just “stop” and then eventually time out with a “Page cannot be displayed” message.
I tried the site in my office, as well as at home and on a couple of other IP addresses, and there was no problem with it at all. Using different browsers created no problem at all, and even different operating systems (I tried from both Linux and Windows) weren’t a problem. The only issue that the boss and I could come up with that it was some kind of bizarre group policy setting, because the colleague’s office all runs on a Windows domain, whereas my office does not. However, this theory was disproved when I tried a PC at the remote office that wasn’t a member of the domain and the problem persisted.
I decided to try a different internet gateway in the hope that there was some issue with the primary router at my colleague’s office. Obviously this would still be a major issue, but at least it might offer some explanation as to why this problem was manifesting itself. We have multiple internet connections to each office, not just for redundancy but due to historical reasons, so this was a good time to test one out. Unfortunately the problem was still there.
After scratching my head for a minute or two, I tried out a couple of traceroutes. The first was directly to the website itself (194.154.164.72) and completed without a problem. I’d noticed that the login to the site handed off to booking.lime-management.co.uk (57.66.83.59) and so tried that as well.
This is where the problem became apparent. The traceroute halted on the second hop with a message: “192.168.0.252 reports: destination net unreachable”. This surprised me, as that IP belongs to the router which deals with that office’s connection to the Galileo GDS system. It was here that I realised that a slight oversight had been made with the configuration of the primary router. Galileo servers use IPs in the range 57.8.x.x, and we’d added a static route to the primary router to offload any traffic for 57.x.x.x to 192.168.0.252, without bearing in mind that the entire class A 57.x.x.x range did not belong to Galileo.
I changed the offending route and subnet mask to 57.8.x.x and 255.255.x.x respectively, and the website promptly started working with no problems.
(this entry has mainly been put here in case anyone else ever has a similar problem and searches for it)