This work is licensed under a Creative Commons License.
Tangled in the Threads
Jon Udell, December 1, 1999Joining the DSL Party
My long-awaited ADSL circuit arrives, but there are problems with network address translationWhen you live in an out-of-the way place, as I do, you're making a tradeoff. You can't beat the quality of life in small-town New Hampshire, and in principle the Net enables you to do business with people everywhere. In practice, though, my 56Kbps modem has been a major obstacle. I watched jealously as my friends in metro areas signed up for cable and DSL, and was finally vindicated when my DSL service went live last week.
When I learned that my DSL "modem" (really, bridge or router) was going to be the Cisco 675, I asked the folks in the networking newsgroup what they thought of it:
My new DSL setup is going to use the Cisco 675. Apparently it does NAT (network address translation) and some filtering, but it seems like it's often used in combination with a SonicWALL or WebRamp.
Does anybody else who's using this box have opinions about how to best use it?
"It rocks!" said one person:
I have a Cisco 675 external DSL router and its all you'll ever need. I used to use a Sonic firewall but I've found the 675 offers all I need.
Another contributor agreed with that assessment:
If your 675 is doing NAT then that should be all you need. If you've heard of other 675 users using firewalls it was because they are using the 675 in bridging rather than routing mode as you are.
With bridging mode each computer connected to the 675 gets an IP address from the ISP and so is visible on the Internet. With routing mode (and NAT) only the router (675) is visible. (Port mapping, of course, will complicate things.)
But is NAT, alone, really sufficient? A true firewall does stateful packet inspection. A lot of cracking exploits rely on the fact that unexpected outbound traffic is never filtered, hence the need to correlate what goes outbound with what came inbound.
Randy Switt agreed:
Saying that NAT is as good as a firewall is somewhat disingenuous. Yes, NAT makes hacking more difficult because it is harder to see the machines on the internal network, but it doesn't keep a truly determined hacker out. It may stop 90% of the script kiddies though.
A canned solution like this is much easier to setup and administer, but it loses the flexibility of using something you have total control over, like Linux. For example, I don't know if you could get a website like www.dialpad.com to work through the 675, since it uses custom ports, but my Linux router only took two added lines to enable the port forwarding needed.
What www.dialpad.com offers, by the way, is IP-based long-distance calling, and to use it from a private IP network you have to map some ports (UDP 51200, 51201, TCP 51210).
Dominic Amman asked Randy to post those lines, so he could get his IP-masquerading setup to use the dialpad, and Randy obliged:
Linux IP Masquerading (Thanks to Allen Rotton) If you're using a firewall, make sure you enabled UDP: 51200, 51201, and TCP 51210. In your /etc/rc.d/rc.local, add the following lines and reboot: /usr/sbin/ipmasqadm autofw -A -v -r udp 51200 51201 -c tcp 7175 /usr/sbin/ipmasqadm autofw -A -v -r tcp 51210 51210 -c tcp 7175 Also, please take a look at http://www.ispchannel.com/~rottona/linux_dialpad.htmlPros and cons of appliance firewalls
I've always been a big fan of network appliances. The first one I fell in love with was the Cayman Gatorbox, which was nominally an Ethernet/Appletalk router but could also make UNIX NFS servers look like AppleShare servers. When it arrived at BYTE we just plugged it in, enjoyed the services that it provided, and that was that.
When it comes to firewalls, convenience isn't the only virtue of an appliance-like solution. When I read O'Reilly's classic Building Internet Firewalls, by D. Brent Chapman and Elizabeth Zwicky, I was depressed for about a week. Why? The diligence required to transform a general-purpose computer into a truly effective firewall -- a process described in painstaking detail in this excellent book -- was simply overwhelming. Sure, you can set up firewalling and IP masquerading on your Linux box, but unless you go the extra mile that box is going to have a lot on it that a firewall shouldn't -- a C compiler, Perl, and all manner of other things useful to an intruder.
I'm strongly inclined to prefer a tamper-proof appliance firewall -- provided that it's inexpensive and works well. If you take Chapman and Zwicky's recommendations seriously, the do-it-yourself approach ends up being a lot of work, and there are lots of ways to screw up. And in principle, there's no reason why appliances can't offer the needed degrees of freedom. For example, the same DialPad web page that described the Linux IP-masquerade configuration later added a Cisco 675 solution:
CISCO 675 with NAT (Thanks to Greg Buschmann) configure the router as follows set nat entry add (local IP) 51200 (REAL IP address) 51200 UDP set nat entry add (local IP) 51201 (REAL IP address) 51201 UDP set nat entry add (local IP) 51210 (REAL IP address) 51210 TCPAt the moment, though, I wish that my only problem was to figure out how to do IP telephony through my Cisco 675. In fact, I have a much more basic problem -- one that makes Randy's points about flexibility and control ring true. Good old FTP only sort of works through my 675's NAT software.
The FTP glitch
As is typical of a private IP network, I'm using the 192.168.1 subnet (see RFC1918, Address Allocation For Private Internets). A major benefit of private addressing is conservation of IP address space. Many private networks can, and do, reuse the blocks of address space that RFC1918 recommends for private networks. But the scheme also offers some nice security benefits, since the unregistered (and duplicated) internal addresses will only work -- from the Internet's perspective -- by way of a NAT system that translates between public and private addresses. Such a system is, by definition, a chokepoint, and thus a logical place to also locate firewall functionality: port filtering, traffic monitoring.
It's easy to take NAT for granted and, when it works properly, you can. A single public address magically resolves to one or more private addresses, and away you go. DNS name resolution can be an issue but, on small private networks, you don't really need to bother with the complication of local DNS service, you can just synchronize your hosts tables.
So what went wrong in my case? The symptom is that sometimes FTP works, and sometimes not. A sequence of commands will succeed but inevitably, at some unpredictable point in a long FTP session, things get stuck. This never happens through an alternate dialup connection, so the problem is almost certainly related to my the Cisco router's NAT.
What could be wrong? A little spelunking led me to RFC2633, IP Network Address Translator (NAT) Terminology and Considerations, which contained a likely explanation. "NAT devices often cause difficulties," says RFC2633, "when an application payload includes an IP address." Such is the case with FTP, as RFC2633 explains:
"PORT" command and "PASV" response in FTP control session payload identify the IP address and TCP port that must be used for the data session it supports. The arguments to the PORT command and PASV response are an IP address and a TCP port in ASCII. An FTP ALG [application-level gateway] is required to monitor and update the FTP control session payload so that information contained in the payload is relevant to end nodes. The ALG must also update NAT with appropriate data session tuples and session orientation so that NAT could set up state information for the FTP data sessions.
Because the address and TCP port are encoded in ASCII, this may result in a change in the size of packet. For instance, 10,18,177,42,64,87 is 18 ASCII characters, whereas 193,45,228,137,64,87 is 20 ASCII characters. If the new size is same as the previous, only the TCP checksum needs adjustment as a result of change of data. If the new size is less than or greater than the previous, TCP sequence numbers must also be changed to reflect the change in length of FTP control data portion. A special table may be used by the ALG to correct the TCP sequence and acknowledge numbers. The sequence number and acknowledgement correction will need to be performed on all future packet of the connection.
Could this be the problem? Consider this evidence:
ftp> ls ---> PORT 192,168,1,71,4,97 200 PORT command successful. ---> NLST 150 Opening ASCII mode data connection for file list. foo.txt 226 Transfer complete. 95 bytes received in 0.05 seconds (1.90 Kbytes/sec) ftp> ls ---> PORT 192,168,1,71,4,98 200 PORT command successful. ---> NLST 150 Opening ASCII mode data connection for file list. foo.txt 226 Transfer complete. 95 bytes received in 0.05 seconds (1.90 Kbytes/sec) ftp> ls ---> PORT 192,168,1,71,4,99 200 PORT command successful. ---> NLST 150 Opening ASCII mode data connection for file list. foo.txt 226 Transfer complete. 95 bytes received in 0.05 seconds (1.90 Kbytes/sec) ftp> ls ---> PORT 192,168,1,71,4,100 Connection closed by remote host.I'm running FTP in debug mode in this example. Look where it bombs out -- right at the point where the length of the address/port descriptor changes.
I'm not yet certain this is the right explanation. I'd think other 675 users would be complaining loudly if something this basic was wrong, and I haven't found evidence online of such complaints. So hopefully my problem is fixable. I've reported it, and am awaiting a response.
I still think a security appliance is a good idea. But it's sure frustrating to run into problems that you can't control. Linux is, of course, all about having such control -- and I've been thinking a lot about that this week. On the other hand, while I might be capable of building an effective Linux firewall, the DSL market as a whole can't depend on very many consumers being willing or able to undertake that challenge.
What do you think? Security appliance, or Linux firewall? Drop by the networking newsgroup and let us know what your experiences have been on both sides of the fence.
Jon Udell (http://udell.roninhouse.com/) was BYTE Magazine's executive editor for new media, the architect of the original www.byte.com, and author of BYTE's Web Project column. He's now an independent Web/Internet consultant, and is the author of Practical Internet Groupware, from O'Reilly and Associates.
This work is licensed under a
Creative Commons License.