A few weeks ago at my job, we started up a new mini-branch in an existing office that was internet ready. We have many of our micro branches connect via VPN back to our main office. This worked find in all of our offices, except the new one. It turned out that something odd was happening to VPN connections from this location (and from other NATted locations, like coffehouse WiFi). Windows 2000 VPN clients had no difficulty, but XP clients failed to connect. For whatever reason, whenever XP clients tried to connect, GRE packets would get dropped by our SonicWall Pro firewall. The SonicWall doesn’t pass GRE and couldn’t be upgraded to support it (what a gyp). What was most annoying to me about it was that I couldn’t fix the problem by merely applying a patch and making a registry change to XP (as should be expected). God, does M$ piss me off sometimes. Come to think of it, almost all the time.
So I’m fed up. There’s no way I want to pay for another SonicWall-alike product if it’s gonna be obsoleted several years later by some new protocol. What do I do? I’d played with IPCop on my home network several versions back when I had less confidence in its enterprise abilities. Specifically, I knew I needed multiple WAN IP address abilities (aliases). To my delight, I found that IPCop 1.4.8 has an IP alias option! Huzzah! I can use IPCop as our enterprise firewall!
So after a day of configuring the firewall, migrating settings, tweaking config, installing some addons, then removing some (GUIListenPorts is nice, but it needs to be more versatile), then a few hours in the evening testing it, I was running our 100+ employee network on IPCop and the VPN issue was fixed. Although IPCop is fairly easy to set up and use, the setup wasn’t exactly simple in my case. I had some modifications I needed to make. I had to alter the admin web interface ports manually. HTTPS port 445 is blocked by many ISPs and port 443 was already in use for our webmail. GUIListenPorts really needs to allow the user to modify the port numbers by hand. It should suggest 80/443, but linux is all about configurability. Make it configurable as well as easy. I also had multiple subnets on the GREEN network. IPCop doesn’t handle these by default, and can’t be easily (web admin) configured to do so. I ended up having to add a static route entry in rc.local (/sbin/route add -net 10.0.0.0 netmask 255.255.0.0 gw 10.0.0.1). But that was only half of it. IPCop doesn’t allow you to set a wider subnet or multiple subnets on GREEN, so NAT was broken on the remote subnets when talking to aliased RED IPs from remote subnets on GREEN. I had to fix that by changing a line in “/etc/rc.d/rc.firewall” from
/sbin/iptables -t nat -A POSTROUTING -m mark –mark 1 -j SNAT –to-source $GREEN_ADDRESS
/sbin/iptables -t nat -A POSTROUTING -s 10.0.0.0/16 -m mark –mark 1 -j SNAT –to-source $GREEN_ADDRESS
But wait! There’s more! So after all that, things seemed to be working famously. Until another microbranch called. Now their PCs can only stay connected to the VPN for a little over 3 minutes. Something’s not right, and it’s IPCop’s fault. At least that was my initial thought. I looked at the conenction logs on our Win2K RAS server and that said that the client disconnected gracefully. But the client obviously thought it was still connected until a minute or two later. WTF? Something is suddenly blocking packets, and it’s not IPCop. So I drive to the second microbranch and watch this for myself. After a few hours of messing around, and upgrading the Netgear FWG114P, I noticed that the Netgear isn’t forwarding the return GRE packets. I don’t know why, but sopmething about adding the IPCop box on the main office network broke the way the VPN connections were being set up. GD! Proprietary hardware strikes again. I just wished the branch manager would have bought a Linksys WRT54G or WRT54GS instead. But wait! all I have to do is replace this P.O.S. with another IPCop box! IPCop comes to the rescue twice in as many weeks. But this wasn’t a simple setup either. I had a ton of old Dell GX150’s just begging to be turned into IPCop boxen, but the internal NIC wasn’t auto-recognized by IPCop. Nor was the nice, cheap USR NIC (USR 7900, aka, USR997900 [two LEDs]) that I just bought. After a few hours of fiddling, I got it. You have to specify the module name in the /var/ipcop/ethernet/settings file. For the onboard NIC, use this…
For the USR NIC, use this…
You may have to set up the box to use dummy interfaces just to get past that part of the setup and get your initial settings file created.
After I got past that, I just reconfigured the now almost useless Netgear box to just act as an access point. Certainly not worth its initial price.
I should make one more comment about all of these IPCop modifications. Be careful. Keep track of all these mods as you go along (that’s why I’m writing this actually). Although IPcop does have a settings backup function, it does not back up the specific files that I’ve modified (with the exception of ethernet settings). If you ever have to re-install it, or even if you upgrade it, these files may/will get overwritten, and you’ll have to re-do all of your modifications. It’s a pain, I know. It’s the price you pay for an otherwise rockin’ operating system. Maybe they will fix this sometime by maing these sorts of options available natively.
That’s about it. Maybe if I’m adventurous, I’ll try linking the IPCop boxen with local VPN connections (instead of using RAS) and tie our systems together in a cleaner manner. Maybe later, when I have free time. Much later :-)