Tag Archives: linux

Turning an old laptop into a router with pfSense

I’ve generally been very happy with my Netgear DG834G ADSL router. It does ADSL. It does routing. It serves as a wireless access point. However, I felt myself wanting a little more.

The web interface is a little rudimentary, so initially I looked into the OpenWRT project. It turns out that the DG834G, as well as many other routers, runs Linux and there is custom firmware out there to do much cooler things. Perfect!

Well, not quite. The support for the DG834G appears rudimentary at this time. Mainly due to some evil checksum routines on the DG834G which will not allow custom firmwares to run. These can be bypassed, but it is at this point I started reading more and more pages with the phrase, “This could brick your router!” and more forum threads along the lines of, “My router stopped responding!”.

The next step was to look into firewalls which can be run on old PC hardware. I had an old Pentium III-800 laptop kicking around not doing much (I remember ordering a PIII-800 as a server ‘back in the day’ for its sheer power). It had Ethernet on board. So, stick two more PCMCIA cards in (one for Ethernet, one for Wireless) and I’ve got a router and access point in one. It is also whisper quiet and generates very little heat.

There are quite a few firewall packages designed to run on old hardware like this. Initially considered was SmoothWall. However, not for long: No PCMCIA support.

IPCop was next as it features PCMCIA support. Perfect. Unfortunately, it would not install. It made the laptop hard disk perform a ‘click of death’ during formatting. Although worrying, I could not reproduce this with any of the other firewall packages I looked at, or even a full install of Ubuntu.

The latter two are based on Linux. I then decided to look at pfSense, which runs on FreeBSD.

pfSense supports PCMCIA. It also scored many bonus points as you can try it out without installing. It will boot off the CD and you can configure it and go (storing the configuration on removable media). I was impressed and installed it properly.

The web interface is excellent and has all the fancy graphs that I was after from before. It was easy to get it to treat the wireless PCMCIA card as an access point, and to bridge it over to my LAN. pfSense then performed firewall duties between my network and the WAN.

Now, this was a slightly awkward bit. The Netgear router itself was acting like a bridge. So I ended up with a 192.168.1.* ‘insecure’ network, and my main internal 192.168.0.* secure LAN. pfSense sorted that out but it felt a bit clunky. Plus you then hit a ‘double NAT’ problem which means NAT will just not work properly on the LAN (as you have one NAT router sitting right behind another).

Thankfully, the DG834G can be put into pure modem mode. It won’t act as a router at all. It will present itself to pfSense with the ADSL IP address and ‘play dumb’. This is great as now I just have my 192.168.0.* subnet as before, yet behind pfSense. Phew.

Again, pfSense made this easy. Just configure the WAN as PPPoE (You fill in your username and password in pfSense instead of on your ADSL router, as remember the ADSL device is just being a dumb modem). Note that some ISPs, including mine, state they are PPPoA (which pfSense does not support). Thankfully, PPPoE worked with my ISP anyway.

My 360 still complained about being in a ‘strict NAT’ zone. That was fixed by some further NAT configuration and now all is perfect!

There are various cool packages available for pfSense. For example, a transparent proxy mode for squid to cache web content.

Transparent web proxying: Ubuntu, DG834G, Squid

I’ve been tinkering with my home network and in particular with setting up Squid for caching duties. This was easy enough but also required manual configuration on any other systems to actually use it.

Wouldn’t it be easier for this to happen automatically?

The answer lies in transparent proxying which turned out to be possible with my setup.

I went with Squid3 and that just needed to be told to expect to work in this fashion:

# Squid normally listens to port 3128
http_port 3128 transparent

The next step as to get outbound web traffic redirected to the Squid box, which would then perform its duties.

This would normally require a dedicated firewall, and although most ADSL routers nowadays have rudimentary routing capabilities, I thought I was going to have to end up installing Smoothwall or similar.

Thankfully, the DG834G is running a form of embedded Linux. Although the web interface doesn’t allow complex firewall rules changes, it is possible to telnet in directly to play with iptables.

Once in, just a case of setting up the following rules:

iptables -t nat -A PREROUTING -i eth0 -s ! squid-box -p tcp –dport 80 -j DNAT –to squid-box:3128
iptables -t nat -A POSTROUTING -o eth0 -s local-network -d squid-box -j SNAT –to iptables-box
iptables -A FORWARD -s local-network -d squid-box -i eth0 -o eth0 -p tcp –dport 3128 -j ACCEPT

(With squid-box and local-network replaced with the relevant numbers!)

The above courtesy of: http://www.faqs.org/docs/Linux-mini/TransparentProxy.html#s6.

Once done, it just works! One bad thing is that it is not possible to save such custom rules from the telnet interface, so upon a reboot they will need to be manually put back. There are ways round this as you can roll your own custom firmware but that is something for another time.

Port forwarding with Linux, but no iptables, with socat

I’ve recently been experimenting with using Ubuntu as my main desktop at home. I’ve always been a fan of Linux since my university days and it is great to see how far it has come.

I’m particularly happy that there is now Cisco VPN support. Complete with working with the SecurID keyfobs.

Getting connected to my work VPN was trivial once I was pointed in the right direction of which packages to use. Unfortunately, a snag was that I needed to Remote Desktop to my Windows workstation, but the work firewall was not up to date. It was blocking me.

I could, however, ssh to our Linux development server, so surely there was a way to use it as a proxy between my home PC and my work PC?

This is normally ideal ground for SSH tunneling but I was not in the position to get OpenSSH installed on the work PC when I couldn’t get access to it!

The solution: socat.

Easily compiled, establishing an appropriate tunnel was just a matter of invoking:

socat TCP4-LISTEN:5000 TCP4:my-work-pc.somewhere.net:3389

Pointing my Remote Desktop client to that server, on port 5000, meant that the traffic ultimately ended up at the correct place. Perfect.

Caveats here: This sort of tunnel is not encrypted. In this instance, no problem, as the Internet portion is still going over the secured VPN, and the work network itself is considered trusted. RDP traffic is encrypted.