Sean's blog

Sharing DiGi EDGE

It has only been 5 weeks or so since I cancelled TM’s Streamyx ADSL broadband service and started using DiGi’s cellular network, and I’m impressed. OK, ok, so TM could occasionally keep Streamyx working for 3 weeks at a time too. I promise I’ll report in 3 to 6 months’ time!

A quick performance update: DiGi gave us a very conservative ‘average’ download speed of 8KB/s. I’m currently upgrading the packages on our Slackware server from ftp.slackware-brasil.com.br (because Brazil is so close to Malaysia, obviously) and getting 25KB/s average for 4MB+ files. That must be fairly close to a maximum specification for download over EDGE, so I’m delighted. We had the 1Mbit/s Streamyx deal, which was 7 times faster for downloads from Brazil (and occasionally Taiwan), but was often almost or completely unusable for many other websites.

I finally got round to sorting out two things today: a local DNS proxy and shared access to DiGi Internet.

DNS Proxy

Our DiGi EDGE adapter is connected to a USB port on a server on our desk running Slackware. The server runs when any of us is working anyway, but is now also doing what the embedded system does inside a typical ADSL router – it is routing traffic from the LAN to which our PCs are connected, to the Internet via the DiGi EDGE adapter and PPP. In order to reduce the load on the DiGi connection from our PCs, I installed squid on the server and setup our browsers to access the web via the proxy cache.

Watching the squid logs, and using iptraf to check traffic over the ppp0 interface, I noticed that DNS queries were taking a long time – often several seconds for the round-trip. Slackware has a startup script called ‘/etc/rc.d/rc.dnsmasq’, so I had a quick read of the man page and changed its permissions so dnsmasq would be started whenever the server is running. dnsmasq is apparently a lightweight DNS forwarder, and it really does appear to do exactly what it says on the label – I’m impressed with it.

Perhaps I should have read the documentation more carefully, but on our server, the file /etc/resolv.conf now contains a line that says:
nameserver localhost
and the DiGi nameservers are in a file /etc/resolv.conf.digi, identified by the resolv-file option in dnsmasq’s configuration file. The PCs on our LAN all have the IP address of our (DiGi-connected) server in their resolv.conf as nameserver.

The effect of dnsmasq is most noticeable when browsing pages that have embedded resources from many different domains. From watching the dnsmasq debug output, it appears many Internet applications either don’t cache nameserver results or refresh them surprisingly often. When your ISP’s nameservers are as slow to respond as DiGi’s appear to be, that can result in a considerable slowdown in application performance.

Shared access to DiGi

The squid caching proxy is working just fine, but to get email, SSH and all those other applications working that require non-HTTP access, I configured the Slackware server to do IP forwarding with NAT (Network Address Translation). The IP forwarding part is easy – yet again, there’s a handy startup script:
/etc/rc.d/rc.ip_forward
which does very little! IP forwarding doesn’t work on its own – from my brief research, it causes network traffic from our LAN PCs to be copied to the Internet, but with their LAN IP address intact. You can see these packets going out, using iptraf, for example when pinging a website. The server can ping the website, and iptraf shows the ping is ‘from’ the ppp0 address to the website address. The ping from one of the LAN PCs is also sent out via ppp0, but iptraf shows the packet as coming from the PC’s LAN address.

The server must use ‘masquerading’ to solve this problem: it will appear to DiGi’s network that network requests are coming from the server with the EDGE adapter attached, rather than one of the LAN PCs. It took me an embarrassingly long time to find the appropriate settings to get masquerading working on our server, hence the blog article to preserve them for posterity. While checking my facts for this article, I notice that everything I needed to know is already recorded in:
/etc/rc.d/rc.modules-`uname -r`

Just in case you need this for reference, the rc.modules file suggests adding the following to rc.local:

# EXTERNAL -> external network interface
# INTERNAL -> internal network interface
EXTERNAL=eth0
INTERNAL=eth1
echo "Setting up NAT (Network Address Translation)..."
# by default, nothing is forwarded.
iptables -P FORWARD DROP
# Allow all connections OUT and only related ones IN
iptables -A FORWARD -i $EXTERNAL -o $INTERNAL -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $INTERNAL -o $EXTERNAL -j ACCEPT
# enable MASQUERADING
iptables -t nat -A POSTROUTING -o $EXTERNAL -j MASQUERADE

There are some useful notes in the rc.modules file about the effects of masquerading on different protocols, and a list of kernel modules iptables (the software that provides the masquerading facility) needs. Once the server is masquerading correctly, the LAN PCs should have their default gateway changed to the server’s LAN address. That’s it! A shared DiGi EDGE connection.

One final improvement to our setup was getting rid of the necessity to configure all our PCs to work with the squid proxy. Squid is running on the same server that is routing our LAN traffic to and from the Internet. It is possible to make squid a transparent proxy and intercept any requests from the LAN with the following changes:

In squid.conf, to configure squid to be a transparent proxy:

http_port $INTERNAL_IP:3128 transparent

And added to the iptables settings in /etc/rc.d/rc.local:

iptables -t nat -A PREROUTING -s INTERNAL_IP -p tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination INTERNAL_IP:3128

Once that is done, there’s no need for proxy settings on the local PCs. Any outgoing traffic to websites (as long as it’s to the default port 80) will be intercepted by the squid proxy. When we have visitors who use our home network, they too will be transparently using our squid proxy.