Linux IP Masquerade HOWTO David A. Ranch November 13, 2005 November 13, 2005 This document describes how to enable the Linux IP Masquerade feature on a given Linux host. IP Masquerade is a form of Network Address Translation or NAT which NAT allows internally connected computers that do not have one or more registered Internet IP addresses to communicate to the Internet via the Linux server's Internet IP address. ----------------------------------------------------------------------------- Table of Contents 1. Introduction 1.1. Introduction to IP Masquerading or IP MASQ 1.2. Foreword, Feedback & Credits 1.3. Copyright & Disclaimer 2. Background Knowledge 2.1. What is IP Masquerade? 2.2. Current Status 2.3. Who Can Benefit From IP Masquerade? 2.4. Who Doesn't Need IP Masquerade? 2.5. How does IP Masquerade Work? 2.6. Requirements for IP Masquerade on Linux 2.4.x 2.7. Requirements for IP Masquerade on Linux 2.2.x 2.8. Requirements for IP Masquerade on Linux 2.0.x 3. Setting Up IP Masquerade 3.1. Compiling a new kernel if needed 3.2. Checking your existing kernel for MASQ functionality 3.2.1. Compiling Linux 2.4.x Kernels 3.2.2. Compiling Linux 2.2.x Kernels 3.2.3. Compiling Linux 2.0.x Kernels 3.3. Assigning Private Network IP Addresses to the Internal LAN 3.4. Configuring IP Forwarding Policies 3.4.1. Configuring IP Masquerade on Linux 2.6.x and 2.4.x Kernels 3.4.2. Configuring IP Masquerade on Linux 2.2.x Kernels 3.4.3. Configuring IP Masquerade on Linux 2.0.x Kernels 4. Configuring the other internal to-be MASQed machines 4.1. Configuring Microsoft Windows 95 and OSR2 4.2. Configuring Windows NT 4.3. Configuring Windows for Workgroup 3.11 4.4. Configuring UNIX Based Systems 4.5. Configuring DOS using NCSA Telnet package 4.6. Configuring MacOS Based System Running MacTCP 4.7. Configuring MacOS Based System Running Open Transport 4.8. Configuring Novell network using DNS 4.9. Configuring OS/2 Warp 4.10. Configuring OS/400 on a IBM AS/400 4.11. Configuring Other Systems 5. Testing IP Masquerade 5.1. Loading up the rc.firewall ruleset 5.2. Testing internal MASQ client PC connectivity 5.3. Testing internal MASQ client to MASQ server connectivity 5.4. Testing internal MASQ server connectivity 5.5. Testing internal MASQ server to MASQ client connectivity 5.6. Testing External MASQ server Internet connectivity 5.7. Testing internal MASQ client to external MASQ server connectivity 5.8. Testing external MASQ ICMP forwarding 5.9. Testing MASQ functionality without DNS 5.10. Testing MASQ functionality with DNS resolution 5.11. Testing more MASQ functionality with DNS 5.12. Any remaining functional, performance, etc. issues... 6. Other IP Masquerade Issues and Software Support 6.1. Problems with IP Masquerade 6.2. Incoming services 6.3. Supported Client Software and Other Setup Notes 6.3.1. Network Clients that -Work- with IP Masquerade 6.3.2. Clients that do not have full support in IP MASQ: 6.4. Stronger firewall rulesets to run after initial testing 6.4.1. Stronger IP Firewall (IPTABLES) rulesets 6.4.2. Stronger IP Firewall (IPCHAINS) rulesets 6.4.3. Stronger IP Firewall (IPFWADM) Rulesets 6.5. IP Masquerading multiple internal networks 6.5.1. iptables support for multiple internal lans 6.5.2. ipchains support for multiple internal lans 6.5.3. ipfwadm support for multiple internal lans 6.6. IP Masquerade and Dial-on-Demand Connections 6.7. Port Forwarding with IPTABLES or external tools like IPPORTFW, IPMASQADM, IPAUTOFW, REDIR, UDPRED, and other Port Forwarding tools 6.7.1. IPTABLES-based PORTFWD'ing: Using IPTABLES's PREROUTING option for 2.6.x and 2.4.x kernels 6.7.2. IPMASQADM-based PORTFWD'ing: Using IPMASQADM with 2.2.x kernels 6.7.3. IPPORTFW-based PORTFWD'ing: Using IPPORTFW on 2.0.x kernels 6.8. CU-SeeMe and Linux IP-Masquerade 6.9. Mirabilis ICQ 6.10. Gamers: The LooseUDP patch 7. Frequently Asked Questions 7.1. ( Distro ) - What Linux Distributions support IP Masquerading? 7.2. ( Requirements ) - What are the minimum hardware requirements and any limitations for IP Masquerade? How well does it perform? 7.3. ( Errors ) - When I run my specific rc.firewall-* ruleset, I get "command not found" errors. Why? 7.4. ( Still wont work ) - I've checked all my configurations, I still can't get IP Masquerade to work. What should I do? 7.5. ( Email list ) - How do I join or view the IP Masquerade and/or IP Masqurade Developers mailing lists and archives? 7.6. ( NAT vs. Proxy ) - How does IP Masquerade differ from Proxy or NAT services? 7.7. ( GUI ) - Are there any GUI firewall creation/management tools? 7.8. ( MASQ and Dynamic IPs ) - Does IP Masquerade work with dynamically assigned IP addresses? 7.9. ( MASQ and various networks ) - Can I use a cable modem (both bi-directional and with modem returns), DSL, satellite link, etc. to connect to the Internet and use IP Masquerade? 7.10. ( Dial on Demand ) - Can I use Diald or the Dial-on-Demand feature of PPPd with IP MASQ? 7.11. ( Apps ) - What applications are supported with IP Masquerade? 7.12. ( Distro Setup ) - How can I get IP Masquerade running on Redhat, Debian, Slackware, etc.? 7.13. ( Timeouts ) - Connections seem to break if I don't use them often. Why is that? 7.14. ( Odd Behavior ) - When my Internet connection first comes up, nothing works. If I try again, everything then works fine. Why is this? 7.15. ( MTU ) - IP MASQ seems to be working fine but some sites don't work. This usually happens with WWW and some FTP sites. 7.15.1. Enabling PMTU Clamping for PPPoE and some PPP Users: 7.15.2. Clamping the MSS via IPTABLES: 7.15.3. Changing the External MTU of the MASQ server: 7.15.4. Changing the MTU of various operating systems: 7.16. ( FTP ) - MASQed FTP clients don't work. 7.17. ( Performance ) - IP Masquerading seems slow 7.18. ( PORTFW ) - IP Masquerading with PORTFWing seems to break when my line is idle for long periods 7.19. ( PORTFW - Locally ) - I can't reach my PORTFWed server from the INTERNAL lan 7.20. ( Logs ) - Now that I have IP Masquerading up, I'm getting all sorts of weird notices and errors in the SYSLOG log files. How do I read the IPTABLES/IPCHAINS/IPFWADM firewall errors? 7.21. ( Log Reduction ) - My logs are filling up with packet hits due to the new "stronger" rulesets. How can I fix this? 7.22. ( MASQ Security ) - Can I configure IP MASQ to allow Internet users to directly contact internal MASQed servers? 7.23. ( Free Ports ) - I'm getting "kernel: ip_masq_new(proto=UDP): no free ports." in my SYSLOG files. Whats up? 7.24. ( SETSOCKOPT ) - I'm getting "ipfwadm: setsockopt failed: Protocol not available" when I try to use IPPORTFW! 7.25. ( SAMBA ) - Microsoft File and Print Sharing and Microsoft Domain clients don't work through IP Masq! 7.26. ( IDENT ) - IRC won't work properly for MASQed IRC users. Why? 7.27. ( IRC DCC ) - mIRC doesn't work with DCC Sends 7.28. ( IP Aliasing ) - Can IP Masquerade work with only ONE Ethernet network card? 7.29. ( Multiple-LANs ) - I have two MASQed LANs but they cannot communicate with each other! 7.30. ( SHAPING ) - I want to be able to limit the speed of specific types of traffic 7.31. ( ACCOUNTING ) - I need to do accounting on who is using the network 7.32. ( MULTIPLE IPs - DMZ segments) - I have several EXTERNAL IP addresses that I want to PORTFW to several internal machines. How do I do this? 7.33. ( 1:1 NAT ) - I'd like to do 1:1 NAT but I can't figure out how to do it 7.34. ( Netstat ) - I'm trying to use the NETSTAT command to show my Masqueraded connections but its not working 7.35. ( VPNs ) - I would like to get Microsoft PPTP (GRE tunnels) and/or IPSEC (Linux SWAN) tunnels running through IP MASQ 7.36. ( Games ) - I want to get the XYZ network game to work through IP MASQ but it won't work. Help! 7.37. ( Stops working ) - IP MASQ works fine for a while but then it stops working. A reboot seems to fix this. Why? 7.38. ( SMTP Relay ) - Internal MASQed computers cannot send SMTP or POP-3 mail! 7.39. ( Source Routing ) - I need different internal MASQed networks to exit on different external IP addresses 7.40. ( IPCHAINS rulesets on 2.4.x kernels ) - What the ipchains.o module can do on 2.4.x kernels 7.41. ( IPTABLES vs. IPCHAINS vs. IPFWADM ) - Why do the 2.4.x, 2.2.x, and 2.0.x kernels use different firewall systems? 7.42. ( Upgrades ) - I've just upgraded to the x.y.z kernel, why isn't IP Masquerade working? 7.43. ( EQL ) - I need help with EQL connections and IP Masq 7.44. ( Wussing out ) - I can't get IP Masquerade to work! What options do I have for Windows Platforms? 7.45. ( Developers ) - I want to help with IP Masquerade development. What can I do? 7.46. ( More INFO ) - Where can I find more information on IP Masquerade? 7.47. ( Translators ) - I want to translate this HOWTO to another language, what should I do? 7.48. ( Updates ) - This HOWTO seems out of date, are you still maintaining it? Can you include more information on ...? Are there any plans for making this better? 7.49. ( Thanks ) - I got IP Masquerade working, it's great! I want to thank you guys, what can I do? 8. Miscellaneous 8.1. Useful Resources 8.2. Linux IP Masquerade Resource 8.3. Thanks to the following supporters.. 8.4. Reference 8.5. ChangeLOG ----------------------------------------------------------------------------- Chapter 1. Introduction 1.1. Introduction to IP Masquerading or IP MASQ This document describes how to enable the Linux IP Masquerade feature on a given Linux host. IP Masquerade, called "IPMASQ" or "MASQ" for short, is a form of Network Address Translation (NAT) which allows internally connected computers that do not have one or more registered Internet IP addresses to communicate to the Internet via the Linux server's Internet IP address. Since IPMASQ is a generic technology, you can connect the Linux server's internal and external to other computers through LAN technologies like Ethernet, TokenRing, and FDDI, as well as dialup connections line PPP or SLIP links. This document primarily uses Ethernet and PPP connections in examples because it is most commonly used with DSL / Cablemodems and dialup connections. "This document is intended for systems running stable Linux kernels like 2.4.x, 2.2.x, and 2.0.x preferably on an IBM-compatible PC. IP Masquerade does work on other Linux-supported platforms like Sparc, Alpha, PowerPC, etc. but this HOWTO doesn't cover them in as much detail. Beta kernels such as 2.5.x, 2.3.x, 2.1.x, and ANY kernels less than 2.0.x are NOT covered in this document. The primary reason for this is because many of the older kernels are considered broken. If you are using an older kernel version, it is highly advisable to upgrade to one of the stable Linux kernels before using IP Masquerading. " ----------------------------------------------------------------------------- 1.2. Foreword, Feedback & Credits From the original IPMASQ HOWTO author: "As a new user, I found it very confusing to setup IP masquerade on the Linux kernel, (back then, its was a 1.2.x kernel). Although there was a FAQ and a mailing list, there was no documentation dedicated to this. There was also some requests on the mailing list for a HOWTO manual. So, I decided to write this HOWTO as a starting point for new users and possibly create a building block for other knowledgeable users. If you, the reader, have any additional ideas, corrections, or questions about this document, please feel free to contact us. " This document was originally written by [mailto:ambrose@writeme.com] Ambrose Au back in August, 1996, based on the 1.x kernel IPMASQ FAQ written by Ken Eves and numerous helpful messages from the original IP Masquerade mailing list. In particular, a mailing list message from Matthew Driver inspired Ambrose to set up IP Masquerade and eventually write version 0.80 of this HOWTO. In April 1997, Ambrose created the Linux IP Masquerade Resource Web site at [http://ipmasq.webhop.net] http://ipmasq.webhop.net which has provided up-to-date information on Linux IP Masquerading ever since. In February 1999, [dranch@trinnet.net] David Ranch took over maintenance of the HOWTO. David then re-wrote the HOWTO and added a substantial number of sections to the document. Today, the HOWTO is still maintained by David where he constantly updates it and fixes any reported bugs, etc. Please feel free to send any feedback or comments regarding this HOWTO to [mailto:dranch@trinnet.net] dranch@trinnet.net if you have any corrections or if any information/URLs/etc. is missing. Your invaluable feedback will certainly influence the future of this HOWTO! This HOWTO is meant to be a fairly comprehensive guide to getting your Linux IP Masquerading system working in the shortest time possible. David only plays a technical writer on T.V. so you might find the information in this document not as general and/or objective as it could be. If you think a section could be clearer, etc.. please let David know. The latest version of the MASQ HOWTO can be found at [http://www.ecst.csuchico.edu/~dranch/LINUX/ index-linux.html#ipmasq] Dranch's Linux Page. Additional news, mirrors of the HOWTO, and information regarding IPMASQ can be found at the [http:// ipmasq.webhop.net/] IP Masquerade Resource web page. If you have any technical questions on IP Masquerade, please join the [http:// home.indyramp.net/mailman/listinfo/masq] IP Masquerade Mailing List instead of sending email to David or Ambrose. Most MASQ problems are -common- for ALL MASQ users and can be easily solved by users on the list. In addition to this, the response time of the IP MASQ email list will be much faster than a reply from either David or Ambrose. The latest version of this document can be found at the following sites which also contains HTML, Postscript, PDF, etc. versions   * [http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#ipmasq] Dranch's Linux page   * http://ipmasq.webhop.net/: The IP Masquerade Resources   * http://ipmasq2.webhop.net/: The IP Masquerade Resources MIRROR   * [http://www.tldp.org] The Linux Documentation Project   * Also refer to IP Masquerade Resource Mirror Sites Listing for other local mirrored sites. ----------------------------------------------------------------------------- 1.3. Copyright & Disclaimer This document is copyrighted(c) 2003,2002,2001,2000 for David A. Ranch and it is a FREE document. You may redistribute it under the terms of the GNU General Public License (GPL). The information herein this document is, to the best of David's knowledge, correct. However, the Linux IP Masquerade feature is written by humans and thus, the chance of mistakes, bugs, etc. might occur from time to time. No person, group, or other body is responsible for any damage on your computer(s) and any other losses by using the information on this document. i.e. "THE AUTHORS AND ALL MAINTAINERS ARE NOT RESPONSIBLE FOR ANY DAMAGES INCURRED DUE TO ACTIONS TAKEN BASED ON THE INFORMATION IN THIS DOCUMENT. " Ok, with all this behind us... On with the show.. ----------------------------------------------------------------------------- Chapter 2. Background Knowledge 2.1. What is IP Masquerade? IP Masquerade is a networking function in Linux similar to the one-to-many (1:Many) NAT (Network Address Translation) servers found in many commercial firewalls and network routers. For example, if a Linux host is connected to the Internet via PPP, Ethernet, etc., the IP Masquerade feature allows other "internal" computers connected to this Linux box (via PPP, Ethernet, etc.) to also reach the Internet as well. Linux IP Masquerading allows for this functionality even though these internal machines don't have an officially assigned IP address. MASQ allows a set of machines to invisibly access the Internet via the MASQ gateway. To other machines on the Internet, the outgoing traffic will appear to be from the IP MASQ Linux server itself. In addition to the added functionality, IP Masquerade provides the foundation to create a HEAVILY secured networking environment. With a well built firewall, breaking the security of a well configured masquerading system and internal LAN should be considerably difficult to accomplish. If you would like to know more on how MASQ (1:Many) differs from 1:1 (true) NAT and Proxy solutions, please see the Section 7.6 FAQ entry. ----------------------------------------------------------------------------- 2.2. Current Status IP Masquerade has been in the Linux kernels for several years now and is quite mature as the kernel enters the 2.4.x stage. Kernels since Linux 1.3.x have had MASQ support built-in. Today, many individuals and commercial businesses are using it with excellent results. 2.4.x kernel users:   * The 2.4.x kernel hosts an entirely re-written set of NAT code which is both far superior, faster, and more secure than any previous versions written for Linux. Unfortunately, several kernel modules that were written for the 2.2.x kernel to support things like UDP-based RealAudio, etc. have not been ported to 2.4.x yet. Because of this, some people should consider NOT upgrading if these network applications are critical to them. But, at the same time, some of these programs have been updated and now use different, NAT-friendly protocols. Thus special NAT treatment is no longer required. As always, please see the http://ipmasq.webhop.net /: The IP Masquerade Resources site for updated news, etc. Common network functionalities like Web browsing, telnet, ssh, ping, traceroute, etc. work well over stock IP Masquerade setups. Other network applications such as ftp, irc, and Real Audio work well with the appropriate additional IP MASQ modules loaded into the kernel as modules. Other network-specific programs like streaming audio (MP3s, True Speech, etc) should work too without any special module. Some users on the mailing list also had good results with video conferencing software. It should be noted that running IP Masquerade with only ONE network card (NIC) to MASQ between internal and external Ethernet networks is NOT recommended. For more details, please see Section 7.28 FAQ section. Anyways, please refer to Section 6.3 for a more complete listing of software supported by IP Maquerade all kernel versions. IP Masquerade works well as a server to other 'client machines' running various operating systems and hardware platforms. Here is a sampling of successful reports with internal MASQed systems running :   * UNIX: Sun Solaris, [Net,Free,Open,*i]-BSD, Hp-UX, Linux, IBM AIX, Digital UNIX, Ultrix, etc.   * Microsoft Windows 2000, NT (3.x and 4.x), 95/98/ME, Windows for Workgroups (with the TCP/IP package)   * IBM OS/2   * Apple Macintosh MacOS machines running either MacTCP or Open Transport   * DOS-based systems with packet drivers and the NCSA Telnet package   * VAXen   * Compaq/Digital Alpha running Linux and NT   * Amiga computers with AmiTCP or AS225-stack. The list goes on and on but the point is, if your OS platform talks TCP/IP, it should work with Linux's IP Masquerade! ----------------------------------------------------------------------------- 2.3. Who Can Benefit From IP Masquerade?   * If you have a Linux host connected to the Internet and..   * if you have internal computers running TCP/IP connected that are connected to this Linux box via on a network, and/or   * if your Linux host has more than one modem and acts as a PPP or SLIP server connected to other computers, and these machines do not have official or public assigned IP addresses (i.e. addressed with private TCP /IP numbers).   * If you want those OTHER machines to communicate to the Internet without spending extra money to acquire additional Public / Official TCP/IP addresses from your ISP, then you should either configure Linux to be a router or purchase an external router. ----------------------------------------------------------------------------- 2.4. Who Doesn't Need IP Masquerade?   * If your machine is a stand-alone Linux host connected to the Internet (setting up a firewall is a good idea though), or   * if you already have multiple assigned public addresses for your OTHER machines, and   * if you don't like the idea of a 'free ride' using Linux and feel more comfortable using expensive commercial tools to perform the exact same functionalities. ----------------------------------------------------------------------------- 2.5. How does IP Masquerade Work? Based from the original IP Masquerade FAQ by Ken Eves: Here is a drawing of the most simplistic setup: +---------------------------------------------------------------------------+ |PPP/ETH/etc. +------------+ +-------------+ | |to ISP provider | Linux #1 | PPP/ETH/etc. | Anybox | | | | | | | | | <---------- modem1| |modem2 ----------- modem3| | | | | | | | | | 111.222.121.212 | | 192.168.0.100 | | | | +------------+ +-------------+ | +---------------------------------------------------------------------------+ In the above drawing, a Linux box with IP_MASQUERADING is installed as Linux #1 and is connected to the Internet via PPP, Ethernet, etc. It has an assigned public IP address of 111.222.121.212. It also has another network interface (e.g. modem2) connected to allow incoming network traffic be it from a PPP connection, Ethernet connection, etc. The second system (which does not need to be Linux) connects into the Linux # 1 box and starts its network traffic to the Internet. This second machine does NOT have a publicly assigned IP address from the Internet, so it uses an [http://www.ietf.org/rfc/rfc1918.txt?number=1918] RFC1918 private address, say 192.168.0.100. (see below for more info) With IP Masquerade and the routing configured properly, this second machine "Anybox" can interact with the Internet as if it was directly connected to the Internet with a few small exceptions [noted later]. Quoting Pauline Middelink (the founder of Linux's IPMASQ): "Do not forget to mention that the "ANYBOX" machine should have the Linux #1 box configured as its default gateway (whether it be the default route or just a subnet is no matter). If the "ANYBOX" machine is connected via a PPP or SLIP connection, the Linux #1 machine should be configured to support proxy arp for all routed addresses. But, the setup and configuration of proxy arp is beyond the scope of this document. Please see the [http://www.tldp.org /HOWTO/PPP-HOWTO/index.html] PPP-HOWTO for more details." The following is an excerpt on how IPMASQ briefly works though this will be explained in more detail later. This short text is based from a previous post on comp.os.linux.networking which has been edited to match the names used in the above example: +-------------------------------------------------------------------------------+ | o I tell machine ANYBOX that my PPP or Ethernet connected Linux box is its | | gateway. | | | | o When a packet comes into the Linux box from ANYBOX, it will assign the | | packet to a new TCP/IP source port number and insert its own IP address | | inside the packet header, saving the originals. The MASQ server will | | then send the modified packet over the PPP/ETH interface onto the | | Internet. | | | | o When a packet returns from the Internet into the Linux box, Linux | | examines if the port number is one of those ports that was assigned | | above. If so, the MASQ server will then take the original port and | | IP address, put them back in the returned packet header, and send | | the packet to ANYBOX. | | | | o The host that sent the packet will never know the difference. | +-------------------------------------------------------------------------------+ Another IP Masquerading Example: A typical example is given in the diagram below: +---------------------------------------------------------------------------+ | Ethernet | | 192.168.0.x | | +----------+ | | | | | | | A-box |:::::: | | | |.2 : | | +----------+ : | | : +----------+ PPP/ETH | | +----------+ : .1 | Linux | link | | | | :::::::| Masq-Gate|:::::::::::::::::::>> Internet | | | B-box |:::::: | | 111.222.121.212 | | | |.3 : +----------+ | | +----------+ : | | : | | +----------+ : | | | | : | | | C-box |:::::: | | | |.4 | | +----------+ | | | | | | | | | > | | | <-Internal Network--> | | <- External Network ----> > | | | connected via an | | Connected from the > | | | Ethernet hub or | | Linux server to your > | | | switch | | Internet connection > | +---------------------------------------------------------------------------+ In this example, there are (4) computer systems that we are concerned about. There is also presumably something on the far right that your PPP/ETH connection to the Internet comes through (modem server, DSL DSLAM, Cablemodem router, etc.). Out on the Internet, there exists some remote host (very far off to the right of the page) that you are interested in communicating with). The Linux system named Masq-Gate is the IP Masquerading gateway for ALL internal networked machines. In this example, the machines A-box, B-box, and C-box would have to go through the Masq-Gate to reach the Internet. The internal network uses one of several [http://www.cis.ohio-state.edu/cgi-bin/ rfc/rfc1918.html] RFC-1918 assigned private network addresses, where in this case, would be the Class-C network 192.168.0.0. If you aren't familiar with RFC1918, it is encouraged to read the first few chapters of the RFC but the jist of it is that the TCP/IP addresses 10.0.0.0/8, 172.16-31.0.0/12, and 192.168.0.0/16 are reserved. When we say "reserved", we mean that anyone can use these addresses as long as they aren't routed over the Internet. ISPs are even allowed to use this private addressing space as long as they keep these addresses within their own networks and NOT advertise them to other ISPs. Unfortunately, this isn't always the case but thats beyond the scope of this HOWTO. Anyway, the Linux box in the diagram above has the TCP/IP address 192.168.0.1 while the other systems has the addresses:   * A-Box: 192.168.0.2   * B-Box: 192.168.0.3   * C-Box: 192.168.0.4 The three machines, A-box, B-box and C-box, can have any one of several operating systems, just as long as they can speak TCP/IP. Some such as Windows 95, Macintosh MacTCP or OpenTransport , or even another Linux box have the ability to connect to other machines on the Internet. When running the IP Masquerade, the masquerading system or MASQ-gate converts all of these internal connections so that they appear to originate from the masq-gate itself. MASQ then arranges so that the data coming back to a masqueraded connection is relayed to the proper originating system. Therefore, the systems on the internal network are only able to see a direct route to the internet and are unaware that their data is being masqueraded. This is called a "Transparent" connection. NOTE: Please see Chapter 7 for more details on topics such as:   * The differences between NAT, MASQ, and Proxy servers.   * How packet firewalls work ----------------------------------------------------------------------------- 2.6. Requirements for IP Masquerade on Linux 2.4.x " ** Please refer to IP Masquerade Resource for the latest information. ** "   * The newest 2.4.x kernels are now using both a completely new TCP/IP network stack as well as a new NAT sub-system called NetFilter. Within this NetFilter suite of tools, we now have a tool called IPTABLES for the 2.4.x kernels much like there was IPCHAINS for the 2.2.x kernels and IPFWADM for the 2.0.x kernels. The new IPTABLES system is far more powerful (combines several functions into one place like true NAT functionality), offers better security (stateful inspection), and better performance with the new 2.4.x TCP/IP stack. But this new suite of tools can be a bit complicated in comparison to older generation kernels. Hopefully, if you follow along with this HOWTO carefully, setting up IPMASQ won't be too bad. If you find anything unclear, downright wrong, etc. please email David about it. Unlike the migration to IPCHAINS from IPFWADM, the new NetFilter tool has kernel modules that can actually support older IPCHAINS and IPFWADM rulesets with minimal changes. So re-writing your old MASQ or firewall ruleset scripts is not longer required. BUT.. with the 2.4.x kernels, you cannot use the old 2.2.x MASQ modules like ip_masq_ftp, ip_masq_irc, etc. AND IPCHAINS is incompatible with the new IPTABLES modules like ip_conntrack_ftp, etc. So, what does this mean? It basically means that if you want to use IPMASQ or PORTFW functionality under a 2.4.x kernel, you shouldn't use IPCHAINS rules but IPTABLES ones instead. Please also keep in mind that there might be several benefits in performing a full ruleset re-write to take advantage of the newer IPTABLES features like stateful tracking, etc. but that is dependant upon how much time you have to migrate your old rulesets. Please see Section 7.40 for additional details. Some new 2.4.x functionalities include the following: PROs:   * Lots of new protocols modules like: amanda, eggdrop, ipsec, ipv6, portscan, pptp, quota, rsh, talk, and tftp   * TRUE 1:1 NAT functionality for those who have TCP/IP addresses and subnets to use (no more iproute2 commands)   * Stateful application level (FTP, IRC, etc.) and stateful protocol level (TCP/UDP/ICMP) network traffic inspection   * Built-in PORT Forwarding (no more ipmasqadm or ipportfw commands)   * The built-in PORTFW'ing support works for both external and internal traffic. This means that users that have PORTFW for external traffic and REDIR for internal port redirection do not need to use two tools any more!   * PORT Forwarding of FTP traffic to internal hosts is now completely supported and is handled in the conn_trak_ftp module   * Full Policy-Based routing features (source-based TCP/IP address routing)   * Compatibility with Linux's FastRoute feature for significantly faster packet forwarding (a.k.a Linux network switching). Note that this feature is still not compatible with packet filtering for strong firewall rulesets.   * Fully supports TCP/IP v4, v6, and even DECnet (ack!)   * Supports wildcard interface names like "ppp*" for serial interfaces like ppp0, ppp1, etc   * Supports filtering on both input and output INTERFACES (not just IP addresses)   * Source Ethernet MAC filtering   * Denial of Service (DoS) packet rate limiting   * Packet REJECTs now have user-selectable return ICMP messages   * Variable levels of logging (different packets can go to different SYSLOG levels)   * Other features like traffic mirroring, securing traffic per login, etc. CONs:   * Netfilter is an entirely new architechure thus most of the older 2.2.x MASQ kernel modules written to make non-NAT friendly network applications work through IPMASQ need to be re-written for the 2.4.x kernels. Because of this, if you specifically need functionality from some of these modules (see below), you should stay with a 2.2.x kernel until these modules have been either ported or the application has been updated to use NAT-friendly protocols. If you are curious on the porting status of a given module, please email the author of the module and NOT David or Ambrose. We don't code.. we just document. :-) Here is the status of the known IP Masq kernel modules or patches as found on the IPMASQ WWW site's Application Support Matrix. In addition, you should also setup out the [http://www.netfilter.org/documentation/ pomlist/pom-summary.html] Netfilter Patch-o-Matic URL as well. If you have the time and knowledge to help in the porting of code, your efforts would be highly appreciated: +----------------------------------------------------------------------------+ | Status = Module name = Description and notes | |--------- ----------- ---------------------------------- | | Ported CuSeeme Used for Video conferencing | | | |NotPorted DirectPlay Used for online Microsoft-based games | | | | Ported FTP Used for file transfers | | - NOTEs: Built into the kernel and | | fully supports PORTFWed FTP | | | |ReWritten H.323 Used for Video conferencing | | | |NotPorted ICQ Used for Instant messaging | | * No longer required for modern ICQ clients | | | | Ported Irc Used for Online chat rooms | | | | Ported Quake Used for online Quake games | | | | Ported PPTP Allow for multiple clients to the same server | | | |NotPorted Real Audio Used for Streaming video / audio | | * No longer required for modern RealVideo clients | | | |NotPorted VDO Live Used for Streaming audio? | +----------------------------------------------------------------------------+ Documentation on how to perform MASQ module porting is available at [http://www.netfilter.org/documentation/HOWTO/ netfilter-hacking-HOWTO.html] http://www.netfilter.org/documentation/ HOWTO/netfilter-hacking-HOWTO.html. If you have the time and knowledge, your talent would highly be appreciated in porting these modules. If you'd like to read up more on NetFilter and IPTables, please see: [http:// www.netfilter.org/documentation/index.html#HOWTO] http://www.netfilter.org/ documentation/index.html#HOWTO and more specifically [http:// www.netfilter.org/documentation/HOWTO//NAT-HOWTO.html] http:// www.netfilter.org/documentation/HOWTO//NAT-HOWTO.html Linux 2.4.x IP Masquerade requirements include:   * Any decent computer hardware. See Section 7.2 for more details.   * The 2.4.x kernel source is available from [http://www.kernel.org/] http:/ /www.kernel.org/. NOTE: Most modern Linux distributions, Section 7.1, that natively come with 2.4.x kernels are typically modular kernels and have all the IP Masquerade functionality already included. In such cases, there is no need to compile a new Linux kernel. If you are UPGRADING your kernel, you should be aware of other programs that might be required and/or need to be upgraded as well (mentioned later in this HOWTO).   * The program "iptables" version 1.2.4 or newer ( 1.2.7a or newer is highly recommended ) archive available from [http://www.netfilter.org/] http:// www.netfilter.org/   + NOTE #1: All versions of IPTABLES less than 1.2.3 have a FTP module issue that can bypass any existing firewall rulesets. ALL IPTABLES users are highly recommended to upgrade to the newest version. The URL is above. NOTE #2: All versions of IPTABLES less than 1.2.2 have a FTP "port" security vulnerability in the ip_conntrack_ftp module. All IPTABLES users are highly recommended to upgrade to the newest version. The URL is above.   + This tool, much like the older IPCHAINS and IPFWADM tools enables the various Masquerding code, more advanced forms of NAT, packet filtering, etc. It also makes use of additional MASQ modules like the FTP and IRC modules. Additional information on version requirements for the newest IPTABLES howto, etc. is located at the [http:// www.netfilter.org/] Unreliable IPTABLES HOWTOs page.   * Loadable kernel modules, preferably 2.1.121 or higher, are available from [http://home.pi.se/blox/modutils/index.html] http://home.pi.se/blox/ modutils/index.html or [ftp://ftp.kernel.org/pub/linux/utils/kernel/ modutils ] ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils   * A properly configured and running TCP/IP network running on the Linux machine as covered in [http://www.tldp.org/HOWTO/Net-HOWTO/index.html] Linux NET HOWTO and the [http://www.tldp.org/LDP/nag2/index.html] Network Administrator's Guide . Also check out the [http://www.ecst.csuchico.edu/ ~dranch/LINUX/index-linux.html#TrinityOS] TrinityOS document which is also authored by David Ranch. TrinityOS is a very comprehensive guide for Linux networking. Some topics include IP MASQ, security, DNS, DHCP, Sendmail, PPP, Diald, NFS, IPSEC-based VPNs, and performance sections, to name a few. There are over Fifty sections in all!   * Connectivity to the Internet for your Linux host covered in Linux ISP Hookup HOWTO, [http://www.tldp.org/HOWTO/PPP-HOWTO/index.html] Linux PPP HOWTO, and [http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html# TrinityOS] TrinityOS. Other helpful HOWTOs could include: Linux DHCP mini-HOWTO, [http://www.tldp.org/HOWTO/Cable-Modem/index.html] Linux Cable Modem mini-HOWTO and [http://www.tldp.org/HOWTO/DSL-HOWTO/ index.html] http://www.tldp.org/HOWTO/DSL-HOWTO/index.html   * Know how to configure, compile, and install a new Linux kernel as described in the Linux Kernel HOWTO. This HOWTO does cover kernel compiling but only for IP Masquerade related options. ----------------------------------------------------------------------------- 2.7. Requirements for IP Masquerade on Linux 2.2.x " ** Please refer to IP Masquerade Resource for the latest information. ** "   * Any decent computer hardware. See Section 7.2 for more details.   * The 2.2.x kernel source is available from [http://www.kernel.org/] http:/ /www.kernel.org/. NOTE: Most modern Linux distributions, Section 7.1, that natively come with 2.2.x kernels are typically modular kernels and have all the IP Masquerade functionality already included. In such cases, there is no need to compile a new Linux kernel. If you are UPGRADING your kernel, you should be aware of other programs that might be required and/or need to be upgraded as well (mentioned later in this HOWTO).   + NOTE #1: --- UPDATE YOUR KERNEL --- Linux 2.2.x kernels less than version 2.2.20 contain several different security vulnerabilities (some were MASQ specific). Kernels less than 2.2.20 have a few local vulnerabilities. Kernel versions less than 2.2.16 have a TCP root exploit vulnerability and versions less than 2.2.11 have a IPCHAINS fragmentation bug. Because of these issues, users running a firewall with strong IPCHAINS rulesets are open to possible instrusion. Please upgrade your kernel to a fixed version.   * NOTE #2: Some newer Section 7.1 such as Redhat 5.2 might not be Linux 2.2.x ready (upgradable). Tools like DHCP, NetUtils, etc. will need to be upgraded. More details can be found later in the HOWTO.   * Loadable kernel modules, preferably 2.1.121 or higher, are available from [http://home.pi.se/blox/modutils/index.html] http://home.pi.se/blox/ modutils/index.html or [ftp://ftp.kernel.org/pub/linux/utils/kernel/ modutils ] ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils   * A properly configured and running TCP/IP network running on the Linux machine as covered in [http://www.tldp.org/HOWTO/Net-HOWTO/index.html] Linux NET HOWTO and the [http://www.tldp.org/LDP/nag2/index.html] Network Administrator's Guide . Also check out the [http://www.ecst.csuchico.edu/ ~dranch/LINUX/index-linux.html#TrinityOS] TrinityOS document which is also authored by David Ranch. TrinityOS is a very comprehensive guide for Linux networking. Some topics include IP MASQ, security, DNS, DHCP, Sendmail, PPP, Diald, NFS, IPSEC-based VPNs, and performance sections, to name a few. There are over Fifty sections in all!   * Connectivity to the Internet for your Linux host covered in Linux ISP Hookup HOWTO, [http://www.tldp.org/HOWTO/PPP-HOWTO/index.html] Linux PPP HOWTO, and [http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html# TrinityOS] TrinityOS. Other helpful HOWTOs could include: Linux DHCP mini-HOWTO, [http://www.tldp.org/HOWTO/Cable-Modem/index.html] Linux Cable Modem mini-HOWTO and [http://www.tldp.org/HOWTO/DSL-HOWTO/ index.html] http://www.tldp.org/HOWTO/DSL-HOWTO/index.html   * IP Chains 1.3.10 or newer are available from [http://www.netfilter.org/ ipchains/] http://www.netfilter.org/ipchains/. Additional information on version requirements for the newest IPCHAINS HOWTO, etc is located at the Linux IP Chains page (mirror at Samba.org)   * Know how to configure, compile, and install a new Linux kernel as described in the Linux Kernel HOWTO. This HOWTO does cover kernel compiling but only for IP Masquerade related options. Other optional patches and tools for 2.2.x kernels   * TCP/IP port-forwarding or re-directing:   + IP PortForwarding (IPMASQADM) - RECOMMENDED - mirror   * PORTFW FTP Solutions:   + There are 2.2.x and 2.0.x kernel MASQ Module solutions for PORTFWed FTP to a MASQed machine (put an FTP server behind a MASQ server). Please see the Application Page on the [http://ipmasq.webhop.net] IPMASQ WWW site for full details. Please note that this is not required for 2.4.x kernels. There is a full FTP proxy application from SuSe that will also allow PORTFWed-like functionality to reach an internal FTP server. For more details, please refer to the SuSe Proxy URL.   * IPROUTE2 for True 1:1 NAT, Policy-based (source) routing, and Traffic Shaping:   + ftp://ftp.inr.ac.ru/ip-routing   + Documentation can be found at [http://www.compendium.com.ar/ policy-routing.txt] http://www.compendium.com.ar/policy-routing.txt   + The [http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/index.html] Advanced Routing HOWTO   + Some source code mirrors are at: [ftp://ftp.funet.fi/pub/mirrors/ftp.inr.ac.ru/ip-routing/] ftp:// ftp.funet.fi/pub/mirrors/ftp.inr.ac.ru/ip-routing/ (STM1 to USA) --- [ftp://sunsite.icm.edu.pl/pub/Linux/iproute/] ftp:// sunsite.icm.edu.pl/pub/Linux/iproute/ [ftp://ftp.sunet.se/pub/Linux/ip-routing/] ftp://ftp.sunet.se/pub/ Linux/ip-routing/ --- [ftp://ftp.nvg.ntnu.no/pub/linux/ip-routing/] ftp://ftp.nvg.ntnu.no/pub/linux/ip-routing/ [ftp://ftp.crc.ca/pub/systems/linux/ip-routing/] ftp://ftp.crc.ca/pub /systems/linux/ip-routing/ --- [ftp://ftp.paname.org] ftp:// ftp.paname.org (France) Please see the [http://ipmasq.webhop.net/] IP Masquerade Resource page for more information available on these patches and possibly others as well. ----------------------------------------------------------------------------- 2.8. Requirements for IP Masquerade on Linux 2.0.x " ** Please refer to IP Masquerade Resource for the latest information. ** "   * Any decent computer hardware. See Section 7.2 for more details.   * The 2.0.x kernel source is available from [http://www.kernel.org/] http:/ /www.kernel.org/. NOTE: Most modern Linux Section 7.1 that natively come with 2.0.x kernels are typically modular kernels and have all the IP Masquerade functionality already included. In such cases, there is no need to compile a new Linux kernel. If you are UPGRADING your kernel, you should be aware of other programs that might be required and/or need to be upgraded as well (mentioned later in this HOWTO).   * Loadable kernel modules, preferably 2.1.85 or newer is available from [http://home.pi.se/blox/modutils/index.html] http://home.pi.se/blox/ modutils/index.html or [ftp://ftp.kernel.org/pub/linux/utils/kernel/ modutils ] ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils (modules-1.3.57 is the minimal requirement)   * A properly configured and running TCP/IP network running on the Linux machine as covered in Linux NET HOWTO and the [http://www.tldp.org/LDP/ nag2/index.html] Network Administrator's GuideAlso check out the [http:// www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#TrinityOS] TrinityOS document which is also authored by David Ranch. TrinityOS is a very comprehensive guide to Linux networking. Topics include IP MASQ, security, DNS, DHCP, Sendmail, PPP, Diald, NFS, IPSEC-based VPNs, performance issues, and many more. There exists over fifty sections in all!   * Connectivity to the Internet for your Linux host is covered in Linux ISP Hookup HOWTO, [http://www.tldp.org/HOWTO/PPP-HOWTO/index.html] Linux PPP HOWTO, and [http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html# TrinityOS] TrinityOS. Other helpful HOWTOs could include: Linux DHCP mini-HOWTO, [http://www.tldp.org/HOWTO/Cable-Modem/index.html] Linux Cable Modem mini-HOWTO and [http://www.tldp.org/HOWTO/DSL-HOWTO/ index.html] Linux DSL HOWTO   * Ipfwadm 2.3.0 or newer is available from [http://www.xos.nl/linux/ipfwadm /download.html] http://www.xos.nl/linux/ipfwadm/download.html   * More information on version requirements are on the [http://www.xos.nl/ linux/ipfwadm/] Linux IPFWADM page   * If you are interested in running IPCHAINS on a 2.0.x+ kernel, see Willy Tarreau's IPCHAINS enabler for 2.0.36+ or Rusty's IPCHAINS for 2.0.x kernels. Please note that these patches are NOT compatible with the IPPORTFW patches for the 2.0.x kernels. Unfortunately, its an either/or deal.   * Know how to configure, compile, and install a new Linux kernel as described in the [http://www.tldp.org/HOWTO/Kernel-HOWTO/index.html] Linux Kernel HOWTO. This HOWTO does cover kernel compiling but only for IP Masquerade related options. Here is a list of IP Masquerading patches for 2.0.x kernels:   * Steven Clarke's IP PortForwarding (IPPORTFW) - RECOMMENDED   * [http://ipmasq.webhop.net/ipautofw.tar.gz] IP AutoForward - NOT Recommended   * [http://ipmasq.webhop.net/redir_0.7.orig.tar.gz] REDIR for TCP (REDIR) - NOT Recommended unless required for internal PORTFW   * [http://ipmasq.webhop.net/udpred.c.gz] UDP redirector (UDPRED) - NOT Recommended   * PORTFWed FTP:   + If you are going to port forward FTP traffic to an internal FTP server, you might need to download [http://ipmasq.webhop.net/files22/ ip_masq-v0.27-for_2.2.18pre9.patch.gz] Fred Viles's FTP server patch The reason for "might" is that some users have had success without the use of these pathches, while others need it. Explicit details on this topic can be found in Section 6.7 of this HOWTO.   * X-Windows display forwarders:   + [ftp://sunsite.unc.edu/pub/Linux/X11/compress/dxpc-3.7.0.tar.gz] X-windows forwarding (DXCP)   * PPTP (GRE) and SWAN (IPSEC) VPNs tunneling forwarders:   + If you plan connecting an internal MASQed PC to a remote PPTP server, you MUST INSTALL the PPTP-Masquerade kernel patch available from the URLsbelow. If you plan on having external PPTP users connect to an internal masqueraded PPTP server, not only do you need the kernel patch installed but you also need PORTFW support enabled in the kernel. Please see the following URLs for the patches and more information: [http://www.impsec.org/linux/masquerade/ip_masq_vpn.html] John Hardin's VPN Masquerade forwarders or the old patch for just [http:// ipmasq.webhop.net/ip_masq_pptp.patch.gz] PPTP Support.   * Game specific patches:   + Glenn Lamb's [http://ipmasq.webhop.net/files20/ loose-udp-2.0.36.patch.gz] LooseUDP for 2.0.36+ patch. ----------------------------------------------------------------------------- Chapter 3. Setting Up IP Masquerade 3.1. Compiling a new kernel if needed If your private network contains any vital information, think carefully in terms of SECURITY before implementing IP Masquerade. By default, IP MASQ becomes a GATEWAY for you to get onto the Internet, but it also can allow someone from the Internet to possibly get into your internal network. Once you have IP MASQ functioning, it is HIGHLY recommended for the user to implement a STRONG IPFWADM/IPCHAINS firewall ruleset. Please see Section 6.4.1, Section 6.4.2 and Section 6.4.3 located below for more details. ----------------------------------------------------------------------------- 3.2. Checking your existing kernel for MASQ functionality Almost ALL modern Linux distributions come MASQ-Ready these days but its always good to check your system before you try to set things up. Follow these few steps for your kernel to see if your kernel is MASQ ready. To see which kernel your system is running, run the following command: +---------------------------------------------------------------------------+ |uname -a | +---------------------------------------------------------------------------+   * Just for clarity: 2.4.x kernels run IPTABLES :: 2.2.x kernels run IPCHAINS :: 2.0.x kernels run IPFWADM   * In general, you must have kernel support for:   + IP forwarding   + IP masquerading   + IP Firewalling   + etc. You will also need to have most MASQ-related modules compiled (most modular kernels will already have all you need already done. Then you will NOT need to re-compile the kernel. If you AREN'T SURE if your Linux distribution is MASQ ready, do the following:   * 2.4.x kernels (look for most of the following entries out of the much longer list):   + Run the command "ls /proc/sys/net/ipv4" while logged into the Linux box. These items are required and should be present regardless if your kernel built IPMASQ as modules or statically.   o ip_dynaddr ip_forward   + To check if IPMASQ was compiled statically into the kernel, run the command "/sbin/lsmod" and see if and modules like the ones shown below for the MODULE section are loaded. No? Ok, now run the command "ls /proc/net/" and see if you see additional /proc files such as:   o ip_masquerade ip_conntrack ip_tables_names If you see these /proc entries and there WEREN'T any kernel modules loaded (shown via the "lsmod" command mentioned above), then your kernel has the IPTABLES subsystem statically compiled into it and is ready to go to use IPMASQ on this system.   + If your kernel uses IPTABLES via modules, most of the stuff listed above should have been missing (because the modules probably aren't loaded). Run the command "ls /lib/modules/`uname -r`/kernel/net/ipv4/ netfilter/" where you should see files like:   o ip_conntrack.o, ip_conntrack_ftp.o, ip_conntrack_irc.o, ip_nat_ftp.o, ip_nat_irc.o ip_tables.o, ipt_MASQUERADE.o, iptable_nat.o, iptable_mangle.o, iptable_filter.o And some optional ones like: ipchains.o, ipt_REJECT.o, and ipt_tcpmss.o If you see those kernel files, IPTABLES was compiled using modules and things look ready to go to use IPMASQ on this system.   * 2.2.x kernels (look for most of the following entries out of the much longer list): list):   + Run the command "ls /proc/sys/net/ipv4" while logged into the Linux box. These items are required and should be present regardless if your kernel built IPMASQ as modules or statically.   o ip_always_defrag ip_dynaddr ip_forward ip_masq_debug ip_masq_udp_dloose (some distros don't support this -- ignore it for now Other 2.2.x options can be checked by running "ls /proc/net/"   # ip_fwchains ip_fwnames ip_masquerade Even more 2.2.x options can be checked by running "ls /proc/net/"   # app icmp icq mfw portfw tcp udp/   * 2.0.x kernels (look for most of the following entries out of the much longer list):   + Run the command "ls /proc/sys/net/ipv4" while logged into the Linux box. These items are required and should be present regardless if your kernel built IPMASQ as modules or statically.   o ip_dynaddr ip_forward running "ls /proc/net"   # ip_forward ip_masq_app ip_masquerade ip_portfw Ultimately, it comes down to the fact if you see /proc files such as "iip_forward", "ip_masq_debug", "ip_masq_udp_dloose"(optional), and "ip_always_defrag" (optional) exist. So. Do most of the above /proc entries or kernel modules show up for your respective kernel? If so, thats good! If you cannot find any of the above entries or if you aren't sure if your distribution supports IP Masquerading by default, ASSUME IT DOESN'T SUPPORT MASQ. You can do one last check by looking at the Section 7.1 section and see if your Linux Distribution is listed. Still not there? Sounds like you'll need to compile a kernel but don't worry.. it isn't hard. Regardless if your current kernel has MASQ support or not, reading the remainder of this section is still highly recommended as it contains other useful information. ----------------------------------------------------------------------------- 3.2.1. Compiling Linux 2.4.x Kernels   * First, you'll need to get some 2.4.x kernel sources (preferably the latest kernel version - NEWER *IS* BETTER IN LINUX LAND)   + NOTE #1: As both the 2.4.x kernel train and the iptables program development progresses, the compile configurion options will change over time. As of this version of the IPMASQ howto, this section reflects the settings for IPTABLES 1.2.7a and the 2.4.20 kernel. If you are compiling against a newer or previous kernel or IPTABLES version, the dialogs and even commands might look different. It is recommended that you update to the newest versions of both the kernel and IPTABLES for added capability, performance, and stability of the kernel.   * Next, depending on the version of the Linux kernel and IPTABLES archive you downloaded, you might want to apply some IPTABLES "patch-o-matic" patches against the kernel. These OPTIONAL patches might fix some known problems, add additional functionality you might need (H.323 protocol, specific issues with network games), etc. It should be noted that the Patch-O-Matic patches used to come with the IPTABLES archive. This is no longer the case and you have to download them (if any) seperately. You can find the the various URLs for downloading IPTABLES, the Patch-o-matic system, etc. Section 2.6.   * If this is your first time compiling the kernel, don't be scared. In fact, it's rather easy and it's covered in several URLs found in Section 2.6. Please note that the instructions included here is just one way to do build a kernel. Please see the Kernel HOWTO for full details. NOTE: Please notice that it IS NOT recommended to put the new kernel sources into the /usr/src/linux directory. You should leave the original kernel sources that came with your Linux distribution in /usr/src/linux. For more details on this topic, please read the "README" file in the top level directory of the kernel sources.   * For this HOWTO example, create a directory called /usr/src/kernel. Next, "cd" into this directory and download the newest 2.4.x kernel sources into it. Once downloaded, issue the following command (if the file ends in a .tar.gz): tar xvzf linux-2.4.x.tar.gz or (if the file ends in a .tar.bzip2): tar xyvf linux-2.4.x.tar.bz2. Please substitute the "x" in the 2.4.x filename with the Linux 2.4 kernel version you downloaded. BZ2 Note: Some Linux distributions use the "I" option instead of the "y" option to decompress bzip2 archives. Once uncompressed, I recommend that you rename the directory from the stock "linux" name to "linux-2.4.x" (replace the "x" with the specific version of your newly installed kernel) for clarity. To do this, run the command "mv linux linux-2.4.x". Next, make sure there is a directory or symbolic link pointing to "/usr/src/kernel/linux" ie. run the command: +---------------------------------------------------------------+ |ln -s /usr/src/kernel/linux-2.4.x /usr/src/kernel/linux | +---------------------------------------------------------------+ again subsituting the "x" for your proper kernel version.   * As mentioned above, you might consider applying any appropriate or optional patches to the kernel's MASQ code BEFORE you compile the final kernel. The IP MASQ code found in the stock kernels is already very useful and does not require any specific patching in order for the system to work for NAT-friendly network applications. Many of these patches are only to fix possible known bugs, add new features (some are /very/ cool), etc. Please refer to Section 2.6 for URLs and the [http:// ipmasq.webhop.net/] IP Masquerade Resources for up-to-date information and patch URLs.   * Applying IPTABLES and Patch-o-Matic kernel patches Download the iptables package and optional Patch-O-matics from the Section 2.6 and put it into a directory, say "/usr/src/archive/ netfilter". Next, go into this new netfilter directory and uncompress the iptables archive with the command: +---------------------------------------------------------------+ |tar xyvf iptables-x.y.z.tar.bz2 | |tar xyvf patch-o-matic-x.tar.bz2 | +---------------------------------------------------------------+ Now, go into the new iptables-x.y.x directory (/usr/src/archive/netfilter /iptables-x.y.z) and run the command +---------------------------------------------------------------+ | #For iptables v1.2.7a: | | make KERNEL_DIR=/usr/src/kernel/linux | | | | #For iptables v1.2.4 (when Patch-o-matic was built-in): | | make pending-patches KERNEL_DIR=/usr/src/kernel/linux | | | +---------------------------------------------------------------+ NOTE: this assumes that your 2.4.x kernel sources are in the /usr/src/ kernel/linux directory. NOTE #2: If you append a "/" to the end of the above command line, you will get an error stating: +-----------------------------------------------------------------+ |"make: *** [/usr/src/kernel/linux/include/asm/socket.h] Error 1".| +-----------------------------------------------------------------+ Remove the trailing "/" and try again. Here is an example of compiling IPTABLES v1.2.7a. Your output might look different depending on what version you are trying to use.   * +------------------------------------------------------------------------------+ |# make KERNEL_DIR=/usr/src/kernel/linux | | | |Extensions found: | | | |cc -O2 -Wall -Wunused -I/usr/src/kernel/linux/include -Iinclude/ | |-DIPTABLES_VERSION=\"1.2.7a\" -fPIC -o extensions/libipt_ah_sh.o -c | |extensions/libipt_ah.c | |ld -shared -o extensions/libipt_ah.so extensions/libipt_ah_sh.o | |cc -O2 -Wall -Wunused -I/usr/src/kernel/linux/include -Iinclude/ | |-DIPTABLES_VERSION=\"1.2.7a\" -fPIC -o extensions/libipt_conntrack_sh.o -c | |extensions/libipt_conntrack.c | |ld -shared -o extensions/libipt_conntrack.so extensions/libipt_conntrack_sh.o | |cc -O2 -Wall -Wunused -I/usr/src/kernel/linux/include -Iinclude/ | |-DIPTABLES_VERSION=\"1.2.7a\" -fPIC -o extensions/libipt_dscp_sh.o -c | |extensions/libipt_dscp.c | |extensions/libipt_dscp_helper.c:69: warning: `dscp_to_name' defined but not | |used | |ld -shared -o extensions/libipt_dscp.so extensions/libipt_dscp_sh.o | |. | |. | |. | |cc -O2 -Wall -Wunused -I/usr/src/kernel/linux/include -Iinclude/ | |-DIPTABLES_VERSION=\"1.2.7a\" -c -o libipulog/libipulog.o | |libipulog/libipulog.c | |ar rv libipulog/libipulog.a libipulog/libipulog.o | |a - libipulog/libipulog.o | |rm libiptc/libip6tc.o libiptc/libip4tc.o libipulog/libipulog.o libipq/libipq.o| +------------------------------------------------------------------------------+   * Ok, hopefully the IPTABLES program compiled up for you. Now, you need to install it. To do this, directory and run the command +---------------------------------------------------------------+ | make install KERNEL_DIR=/usr/src/kernel/linux | +---------------------------------------------------------------+   * Here is an example of installing IPTABLES v1.2.7a. Your output might look different depending on what version you are trying to use.   * +------------------------------------------------------------------------------+ |# make install KERNEL_DIR=/usr/src/kernel/linux | | | |cp iptables /usr/local/sbin/iptables | |cp iptables-save /usr/local/sbin/iptables-save | |cp iptables-restore /usr/local/sbin/iptables-restore | |cp ip6tables /usr/local/sbin/ip6tables | |cp extensions/libipt_ah.so /usr/local/lib/iptables/libipt_ah.so | |cp extensions/libipt_conntrack.so /usr/local/lib/iptables/libipt_conntrack.so | |cp extensions/libipt_dscp.so /usr/local/lib/iptables/libipt_dscp.so | |cp extensions/libipt_ecn.so /usr/local/lib/iptables/libipt_ecn.so | |cp extensions/libipt_esp.so /usr/local/lib/iptables/libipt_esp.so | |cp extensions/libipt_helper.so /usr/local/lib/iptables/libipt_helper.so | |. | |. | |. | |cp extensions/libip6t_udp.so /usr/local/lib/iptables/libip6t_udp.so | |cp extensions/libip6t_LOG.so /usr/local/lib/iptables/libip6t_LOG.so | |cp extensions/libip6t_MARK.so /usr/local/lib/iptables/libip6t_MARK.so | +------------------------------------------------------------------------------+ Next, if you are interested in applying a Patch-O-Matic patch set, go into the patch-o-matic-X directory (/usr/src/archive/netfilter/patch-o-matic-X) and run the command   * +----------------------------------------------------------------+ | #For Patch-O-Matic later than the release of iptables v1.2.7a: | | KERNEL_DIR=/usr/src/kernel/linux | | ./runme pending | | | +----------------------------------------------------------------+ NOTE #1: The use of the "pending" batch is the most common for IPMASQ functionality but there are several others. See below. NOTE #2: this assumes that your 2.4.x kernel sources are in the /usr/src/ kernel/linux directory. NOTE #3: If you append a "/" to the end of the command line, you will get an error stating: +------------------------------------------------------------------+ |"make: *** [/usr/src/kernel/linux/include/asm/socket.h] Error 1". | |Remove the trailing "/" and try again. | +------------------------------------------------------------------+ Here is an example of the Patch-O-Matic prompts you might receive for a 2.4.20 kernel with the "20030107" Patch-O-Matic set. You can also run the "runme" program in a batch mode to speed things up, add experimental patches, etc. if you'd like. To better understand your options, simply run the "./runme" command by itself. Please note that these prompts WILL CHANGE over time.   * +--------------------------------------------------------------------------------+ |Welcome to Rusty's Patch-o-matic! | | | |Each patch is a new feature: many have minimal impact, some do not. | |Almost every one has bugs, so I don't recommend applying them all! | |------------------------------------------------------- | |Already applied: submitted/01_2.4.19 | | submitted/02_2.4.20 | | submitted/ipt_ULOG-mac_len-fix | | submitted/ipt_multiport-invfix | | pending/01_ip_conntrack_proto_tcp-lockfix | | pending/02_newnat-udp-helper | | pending/03_REJECT-fwspotting-phrack60-fix | | pending/04_ftp-conntrack-msg-fix | | | |Testing... 05_ECN-tcpchecksum-littleendian-fix.patch NOT APPLIED (1 rejects out | |of 1 hunks) | |The pending/05_ECN-tcpchecksum-littleendian-fix patch: | | Author: Patrick McHardy | | Status: Pending for kernel inclusion | | | | The 2.4.20 kernel included the new iptables 'ECN' target, enabling a | |selective | | ECN disable mechanism. Unfortunately there was a bug in the incremental | |TCP | | checksum update, resulting in broken TCP checksums on little endian | |machines. | | | | This patch fixes the Bug. | | | |Testing patch pending/05_ECN-tcpchecksum-littleendian-fix.patch... | | Patch pending/05_ECN-tcpchecksum-littleendian-fix.patch applied cleanly. | |Applying patch pending/05_ECN-tcpchecksum-littleendian-fix.patch... | | Patch pending/05_ECN-tcpchecksum-littleendian-fix.patch applied cleanly. | | | |Excellent! Kernel is now ready for compilation. | +--------------------------------------------------------------------------------+   * If everything patches fine, you should see something like the text +---------------------------------------------------------------+ |Excellent! Kernel is now ready for compilation. | +---------------------------------------------------------------+ towards the bottom of the screen. Beyond that, you don't have to install anything at this point. The next step is to compile the new PATCHED kernel.   * Ok, now the new kernel is ready to be compiled but you should make sure that you also have the proper matching iptables program on your machine too (just to make sure). Run the command:   + +------------------------------------------------------------+ |whereis iptables | +------------------------------------------------------------+ and make sure its installed on the machine (the default place is in /usr/ local/sbin/iptables. If you cannot find it or patched up your kernel sources as shown above, I recommend you just re-compile it up as shown above. Now that the kernel sources are patched up, you need to configure it to know what kinds of features you need (HD support, Networking support, MASQ support, etc.). Here are the MINIMUM kernel configuration options required to enable IP Masquerade functionality. Please understand that this HOWTO illustrates just ONE way to configure and compile a kernel (modules vs static). The main difference from this example vs. an example given by a different MASQ guide is that some people might wish to compile kernel components either as modules OR monolithically into the kernel. Basically, compiling things as modules gives you added flexibility to what is or isn't installed into the kernel (reduces unneeded memory use for things you aren't / won't use and modules also allow for drop-in software upgrades [usually no need to reboot the machine]). On the flip side, kernel modules add more complexity to your configuration and sometimes the kernel auto-loader might make mistakes (not that I've ever seen this happen). Compiling things directly into the kernel makes things simpler BUT you loose a huge level of flexibility. The following kernel configuration example is a mixture of both a selection of kernel modules and building them in monolithically (you probably will ALWAYS need MASQ functionality ready to go).   * Side Note: It is assumed that you will also configure the kernel to use your other installed hardware such as USB printers, Ethernet network interfaces, SCSI and IDE HD controllers, etc. as well. Please refer to the [http://www.tldp.org/HOWTO/Kernel-HOWTO/index.html] Linux Kernel HOWTO and the kernel source's "README" file and "Documentation/" directory for detailed help on compiling a kernel. You will need to answer either YES, NO, or MODULE to the following program. Not all options will be available without the proper kernel patches described later in this HOWTO. This shouldn't be an issue as most 3rd party patches are only needed for a very select group of users. Run the following commands to configure your kernel:   * cd /usr/src/kernel/linux   * make menuconfig Please note the following kernel prompts reflect a 2.4.14 kernel (with some of the optional Patch-O-Matic additions. Please read the following carefully for recommendations: +--------------------------------------------------------------------------------------------------+ |[ Code maturity level options ] | | | | * Prompt for development and/or incomplete code/drivers (CONFIG_EXPERIMENTAL) [Y/n/?] | | - YES: though not required for IP MASQ, this option allows the kernel to create | | the MASQ modules and enable the option for port forwarding | | | | * Enable loadable module support (CONFIG_MODULES) [Y/n/?] | | - YES: allows you to load kernel IP MASQ modules | | | | * Set version information on all module symbols (CONFIG_MODVERSIONS) [Y/n/?] | | - YES: allows newer kernels to load older modules if possible | | | | * Kernel module loader (CONFIG_KMOD) [Y/n/?] | | - OPTIONAL: Recommended : allows the kernel to load various kernel modules as it needs them | | | | == Non-MASQ options skipped | | == (CPU type, memory, SMP, FPU, specific stuff) | | | | | |[ General setup ] | | | | * Networking support (CONFIG_NET) [Y/n/?] | | - YES: Enables the network subsystem | | | | == Non-MASQ options skipped | | == (specific hardware, PCI, kernel binaries, PCMCIA, etc.) | | | | | | * Sysctl support (CONFIG_SYSCTL) [Y/n/?] | | - YES: Enables the ability to enable disable options such as forwarding, | | dynamic IPs, etc. via the /proc interface | | | | | |[ Block devices ] | | | | == Non-MASQ options skipped | | == (kernel binaries, power management, PnP, RAID, etc.) | | | | == Don't forget to compile in support for hardware that you might need: | | == IDE controllers, HDs, CDROMs, etc. | | | |[ Networking options ] | | | | * Packet socket (CONFIG_PACKET) [Y/m/n/?] | | - YES: Though this is OPTIONAL, this recommended feature will allow you | | to use TCPDUMP to debug any problems with IP MASQ | | | | * Packet socket: mmapped IO (CONFIG_PACKET_MMAP) [N/y/?] y | | - YES: Speed up the packet protocol | | | | * Kernel/User netlink socket (CONFIG_NETLINK) [Y/n/?] | | - OPTIONAL: Recommended : this feature will allow the logging of | | advanced firewall issues such as routing messages, etc | | | | * Routing messages (CONFIG_RTNETLINK) [N/y/?] (NEW) y | | - OPTIONAL: Allows for support of advanced kernel routing messages | | if you enabled the CONFIG_NETLINK option | | | | * Netlink device emulation (CONFIG_NETLINK_DEV) [N/y/m/?] (NEW) | | - NO: This option does not have anything to do with packet firewall | | logging | | | | * Network packet filtering (replaces ipchains) (CONFIG_NETFILTER) [N/y/?] y | | - YES: Enable this option to let IPTABLES configure the TCP/IP subsection | | of the kernel. By enabling this, then you can turn on advanced | | routing mechanisms like IP Masq, packet filtering, etc. | | | | * Network packet filtering debugging (CONFIG_NETFILTER_DEBUG) [N/y/?] (NEW) n | | - NO: Not required for Masquerading functionality though it may help | | for troubleshooting. There might be a performance penalty when | | enabling this. | | | | * Socket Filtering (CONFIG_FILTER) [Y/n/?] | | - OPTIONAL: Recommended : Though this doesn't have anything do with IPMASQ, | | if you plan on implimenting a DHCP server on the internal network, you WILL | | need to enable this option. | | | | * Unix domain sockets (CONFIG_UNIX) [Y/m/n/?] | | - YES: This enables the UNIX TCP/IP sockets mechanisms | | | | * TCP/IP networking (CONFIG_INET) [Y/n/?] | | - YES: Enables the TCP/IP protocol | | | | * IP: multicasting (CONFIG_IP_MULTICAST) [N/y/?] | | - OPTIONAL: You can enable this if you want to be able to receive | | Multicast traffic. Please note that your ISP must | | support Multicast as well for this all to work at all | | | | * IP: advanced router (CONFIG_IP_ADVANCED_ROUTER) [Y/n/?] | | - OPTIONAL: Though there is nothing in this section mandatory for | | Masquerade, some specific options might be useful | | | | == Non-MASQ options skipped | | == ( autoconf, tunneling ) | | | | * IP: multicast routing (CONFIG_IP_MROUTE) [N/y/?] n | | - OPTIONAL: Though not needed for IPMASQ, enabling this feature will | | let you route multicast traffic through your Linux box. | | Please note that this requires that your ISP be multicast | | enabled as well. | | | | == Non-MASQ options skipped | | == (ARPd) | | | | * IP: TCP Explicit Congestion Notification support (CONFIG_INET_ECN) [N/y/?] n | | - NO: Though enabling this option would be great, there are many Internet | | sites out there that will block this. Hit the "?" when configuring | | the kernel to learn more about it but it is recommended to say NO for | | now. | | | | * IP: TCP syncookie support (disabled per default) (CONFIG_SYN_COOKIES) [Y/n/?] | | - YES: Recommended : for basic TCP/IP network security | | | | | |[ Networking options --> IP: Netfilter Configuration ] | | | | | | * Connection tracking (required for masq/NAT) (CONFIG_IP_NF_CONNTRACK) [N/y/m/?] (NEW) m | | - YES: (Module) This enables the kernel to track various network connections. | | This option is required for Masquerading support as well as to enable | | Stateful tracking for various filewall mechanisms. Please note that | | if you compile this directly into the kernel, you cannot enable | | the legacy IPCHAINS or IPFWADM compatibility modules. | | | | * FTP protocol support (CONFIG_IP_NF_FTP) [M/n/?] (NEW) m | | - YES: (Module) This enables the proper Masquerading of FTP connections if | | CONFIG_IP_NF_CONNTRACK was enabled above | | | | * IRC protocol support (CONFIG_IP_NF_IRC) [M/n/?] (NEW) m | | - YES: (Module) This enables the proper Masquerading of IRC connections if | | CONFIG_IP_NF_CONNTRACK was enabled above | | | | * Userspace queueing via NETLINK (EXPERIMENTAL) (CONFIG_IP_NF_QUEUE) [N/y/m/?] (NEW) m | | - OPTIONAL: Though this is OPTIONAL, this feature will allow IPTABLES to | | copy specific packets to UserSpace tools for additional checks | | | | * IP tables support (required for filtering/masq/NAT) (CONFIG_IP_NF_IPTABLES) [N/y/m/?] (NEW) m | | - YES: (Module) Enables IPTABLES support | | | | * limit match support (CONFIG_IP_NF_MATCH_LIMIT) [N/y/m/?] (NEW) y | | - OPTIONAL: (Module) Recommended : Though not required, this option can used to | | enable rate limiting of both traffic and loggin messages help slow down denial | | of service (DoS) attacks. | | | | * MAC address match support (CONFIG_IP_NF_MATCH_MAC) [N/y/m/?] (NEW) m | | - OPTIONAL: Though not required, the option can allow you to | | filter traffic based upon the SOURCE Ethernet MAC address. | | | | * netfilter MARK match support (CONFIG_IP_NF_MATCH_MARK) [N/y/m/?] (NEW) y | | - YES: (Module) Recommended : This enables IPTABLES to take action upon marked packets. | | This mechanism can allow for PORTFW functionality, TOS marking, etc. | | | | * Multiple port match support (CONFIG_IP_NF_MATCH_MULTIPORT) [N/y/m/?] (NEW) y | | - YES: (Module) Recommended : This enables IPTABLES to accept mutliple SRC/DST port | | ranges (non-contiguous) instead of one port range per IPTABLES | | statement. | | | | * TOS match support (CONFIG_IP_NF_MATCH_TOS) [Y/m/n/?] n | | - OPTIONAL: This allows IPTABLES to match packets based upon their | | DIFFSERV settings. | | | | * LENGTH match support (CONFIG_IP_NF_MATCH_LENGTH) [N/m/?] (NEW) n | | - OPTIONAL: This allows IPTABLES to match packets based upon their | | packet length. | | | | * TTL match support (CONFIG_IP_NF_MATCH_TTL) [N/m/?] (NEW) ? n | | - OPTIONAL: This allows IPTABLES to match packets based upon their | | TTL settings. | | | | * tcpmss match support (CONFIG_IP_NF_MATCH_TCPMSS) [N/y/m/?] m | | - OPTIONAL: (Module) Recommended : This option allows users to examine the MSS value in | | TCP SYN packets. This is an advanced knob but can be very valuable in | | troubleshooting MTU problems. | | | | * Connection state match support (CONFIG_IP_NF_MATCH_STATE) [M/n/?] m | | - YES: (Module) Recommended : This option allows for Stateful tracking of network | | connections. | | | | * Unclean match support (EXPERIMENTAL) (CONFIG_IP_NF_MATCH_UNCLEAN) [N/y/m/?] y | | - YES: (Module) Recommended : This option allows for connection tracking on odd packets. | | It cal also help in the detection of possibly malicious packets. | | This can be a valuable tool in tracking hostile people on the network. | | | | * Owner match support (EXPERIMENTAL) (CONFIG_IP_NF_MATCH_OWNER) [N/y/m/?] n | | - OPTIONAL: This option allows IPTABLES to match traffic based upon the | | user login, group, etc. who created the traffic. | | | | * Packet filtering (CONFIG_IP_NF_FILTER) [N/y/m/?] ? y | | - YES: (Module) This option allows for the kernel to be able filter traffic at | | the INPUT, FORWARDING, and OUTPUT traffic points. | | | | * REJECT target support (CONFIG_IP_NF_TARGET_REJECT) [N/y/m/?] (NEW) y | | - YES: (Module) With this option, a packet firewall can send an ICMP Reject packet | | back to the originator when a packet is blocked. | | | | * MIRROR target support (EXPERIMENTAL) (CONFIG_IP_NF_TARGET_MIRROR) [N/y/m/?] (NEW) n | | - OPTIONAL: This option allows the packet firewall to mirror the exact same | | network packet back to the originator when it is supposed to be | | blocked. This is similar to the REJECT option above but it actually | | sends the original packet back to the originator. i.e. a | | hostile user could actually portscan themselves. | | | | | | * Full NAT (CONFIG_IP_NF_NAT) [M/n/?] m | | - YES: (Module) This option enables the future menus to enable Masquerading, | | PORTFWing, Full (1:1) NAT, etc. | | | | | | * MASQUERADE target support (CONFIG_IP_NF_TARGET_MASQUERADE) [M/n/?] (NEW) m | | - YES: (Module) This option specifically enables Masquerade into the | | kernel | | | | * REDIRECT target support (CONFIG_IP_NF_TARGET_REDIRECT) [N/y/m/?] n | | - OPTIONAL: Not needed for normal MASQ functionality though people who | | want to do transparent proxy via Squid will want this. | | | | * Basic SNMP-ALG support (EXPERIMENTAL) (CONFIG_IP_NF_NAT_SNMP_BASIC) [N/m/?] n | | - OPTIONAL: This enables IPTABLES to properly NAT internal SNMP packets so | | that machines with duplicate addressing ranges can be properly | | managed. | | | | | | * Packet mangling (CONFIG_IP_NF_MANGLE) [N/y/m/?] y | | - YES: (Module) This option allows for advanced IPTABLES packet manipulation | | options. | | | | | | * TOS target support (CONFIG_IP_NF_TARGET_TOS) [N/y/m/?] (NEW) n | | - OPTIONAL: Enables the kernel to modify the TOS field in a packet | | before routing it on | | | | * MARK target support (CONFIG_IP_NF_TARGET_MARK) [N/y/m/?] (NEW) m | | - OPTIONAL: (Module) Recommended : This enables the kernel to manipulate | | packets based upon the MARK field. This can be used for PORTFW | | as well as many other things. | | | | * LOG target support (CONFIG_IP_NF_TARGET_LOG) [N/y/m/?] m | | - YES: (Module) This allows for the logging of packets before they are accepted, | | denied, rejected, etc. | | | | * TCPMSS target support (CONFIG_IP_NF_TARGET_TCPMSS) [N/y/m/?] ? m | | - YES: (Module) This option help some people with MTU problems. Typically, | | most users have to set their Internet connection's MTU to | | 1500 as well as ALL internal machines to 1500. With this | | option, this whole MTU issue might be finally solved. | | | | * ipchains (2.2-style) support (CONFIG_IP_NF_COMPAT_IPCHAINS) [N/y/m/?] m | | - OPTIONAL: (Module) Recommended : If you have an existing IPCHAINS ruleset | | (2.2.x kernels) and enable this option, you can continue to use the | | IPCHAINS program and the majority of your old ruleset except for the | | use of any 2.2.x kernel-specific modules. Please note that if this | | IPCHAINS module is loaded, ALL IPTABLES modules will be non- | | operational. This is an either/or deal only intended for legacy | | rulesets. | | | | * ipfwadm (2.0-style) support (CONFIG_IP_NF_COMPAT_IPFWADM) [N/y/m/?] n | | - OPTIONAL: If you have an existing IPFWADM ruleset (2.0.x kernels) and | | enable this option, you can continue to use the IPFWADM program and | | the majority of your old ruleset except for the use of any 2.0.x | | kernel-specific modules. Please note that if this IPFWADM module | | is loaded, ALL IPTABLES modules will be non operational. This is | | an either/or deal only intended to support legacy rulesets. | | | | | | == Non-MASQ options skipped | | == (IPv6, khttpd, ATM, IPX, AppleTalk, etc.) -- | | | | * Fast switching (read help!) (CONFIG_NET_FASTROUTE) [N/y/?] n | | - NO: This performance optimization is NOT compatible with IP MASQ and/or | | packet filtering | | | | | | == Non-MASQ options skipped | | == (QoS, Telephony, IDE, SCSI, 1394FW, I2O, etc) | | | | == Don't forget to compile in support for hardware that you might need: | | == IDE: HDs, CDROMs, etc. | | == SCSI: HDs, CDROMs, etc. | | | | | |[ Network device support ] | | | | * Network device support (CONFIG_NETDEVICES) [Y/n/?] | | - YES: Enables the Linux Network device sublayer | | | | == Non-MASQ options skipped | | == (Arcnet) | | | | | | * Dummy net driver support (CONFIG_DUMMY) [M/n/y/?] | | - YES: Though OPTIONAL, this option can help when debugging problems | | | | == Non-MASQ options skipped | | == (EQL, etc..) | | | | == Don't forget to compile in support for hardware that you might need: | | == NICs: eth, tr, etc. | | == MODEMs: ppp (ppp async) and/or slip | | == WANs: T1, T3, ISDN, etc. | | == ISDN: for internal ISDN modems | | | | | | == Non-MASQ options skipped | | == (Amateur Radio, IrDA, ISDN, USB, etc.) | | | | | |[ Character devices ] | | | | == Don't forget to compile in serial port support if you are a modem user | | == Don't forget to compile in mouse support | | | | == Non-MASQ options skipped | | == (I2C, Watchdog cards, Ftape, Video for Linux, etc. ) | | | | | |[ File systems ] | | | | == Non-MASQ options skipped | | == (Quota, ISO9660, NTFS, etc ) | | | | * /proc filesystem support (CONFIG_PROC_FS) [Y/n/?] | | - YES: Required to dynamically configure the Linux forwarding | | and NATing systems | | | | | | == Non-MASQ options skipped | | == (Console drivers, Sound, USB, Kernel Hacking) | +--------------------------------------------------------------------------------------------------+ So go ahead and select "exit" and you should be prompted to save your config. NOTE: These are just the kernel components you need for IP Masquerade networking support. You will need to select whatever other options needed for your specific setup. If you want more information on what each one of these kernel modules does, please see the FAQ section of this HOWTO for details.   * Now compile the kernel (make dep; make clean; make bzImage; make modules; make modules_install) , etc. Again, it is beyond the scope of this HOWTO if you have problems compiling your kernel. Please see Section 2.6 for URLs to the KERNEL howto, etc.   * You will then have move over the kernel binary, update your bootloader (LILO, Grub, etc.), and reboot. If you have questions about kernel compiling, I highly recommend to consult some of the URLs mentioned above in this section. ----------------------------------------------------------------------------- 3.2.2. Compiling Linux 2.2.x Kernels Please see Section 2.7 for any required software, patches, etc.   * First of all, you need the kernel source for 2.2.x (preferably the latest kernel version)   + NOTE #1: --- UPDATE YOUR KERNEL --- Linux 2.2.x kernels less than version 2.2.20 contain several different security vulnerabilities (some were MASQ specific). Kernels less than 2.2.20 have a few local vulnerabilities. Kernel versions less than 2.2.16 have a TCP root exploit vulnerability and versions less than 2.2.11 have a IPCHAINS fragmentation bug. Because of these issues, users running a firewall with strong IPCHAINS rulesets are open to possible instrusion. Please upgrade your kernel to a fixed version.   + NOTE #2: As the 2.2.x train progressed, the compile-time options keep on changing. As of this version, this section reflects the settings for a 2.2.20 kernel. If you are running either a newer or older kernel version, the dialogs will look different. It is recommended that you update to the newest kernel for added capability and stability of the system.   * If this is your first time compiling the kernel, don't be scared. In fact, it's rather easy and it's covered in several URLs found in Section 2.7. Please note that the instructions included here is just one way to do build a kernel. Please see the Kernel HOWTO for full details. NOTE: Please notice that it isn't recommended to put the new kernel sources into /usr/src/linux. You should leave the original kernel sources that came with your Linux distribution in /usr/src/linux. For more details on this topic, please read the "README" file in the top level directory of your kernel sources.   * For this HOWTO example, create a directory called /usr/src/kernel. Next, "cd" into this directory and download the newest 2.2.x kernel sources into it. Once downloaded, issue the following command (if the file ends in a .tar.gz): tar xvzf linux-2.2.x.tar.gz or (if the file ends in a .tar.bzip2): tar xyvf linux-2.2.x.tar.bz2. Please substitute the "x" in the 2.2.x filename with the Linux 2.2 kernel version you downloaded. NOTE: Some Linux distributions use the "I" option instead of the "y" option to decompress bzip2 archives. Once uncompressed, I recommend that you rename the directory from "linux" to "linux-2.2.x" for clarity. To do this, run the command mv linux linux-2.2.x. Next, make sure there is a directory or symbolic link pointing to /usr/src/kernel/linux ie. run the command: ln -s /usr/src/ kernel/linux-2.2.x /usr/src/kernel/linuxo again subsituting the "x" for your proper kernel version.   * Apply any appropriate or optional patches to the kernel source code. By default, stock Linux kernels do not require any specific patching in order for the system to work. Features like PPTP/IPSEC masqurading are already built-in in the newest kernels but other tools like Xwindows forwarders are optional. Please refer to Section 2.7 for URLs and the [http://ipmasq.webhop.net/] IP Masquerade Resources for up-to-date information and patch URLs.   * Now that the kernel is patched up (if required), here are the MINIMUM kernel configuration options required to enable IP Masquerade functionality. Please understand that this HOWTO illustrates just ONE way to compile a kernel. The main difference from this method vs. a different one is some people wish to compile things either as modules OR monolithically right into the kernel. Basically, compiling things as modules gives you added flexibility to what is or isn't installed into the kernel (reduces unneeded memory use and allow for drop-in upgrades [no need to reboot]) BUT they add more complexity to your configuration. On the flip side, compiling things directly into the kernel makes things simpler BUT you loose a level of flexibility. The following example is a mixture of both built-in AND modules. Side Note: It is assumed that you will also configure the kernel to use your other installed hardware such as network interfaces, optional SCSI controllers, etc. as well. Please refer to the Linux Kernel HOWTO and the kernel source's README file and Documentation/ directory for detailed help on compiling a kernel. Please note the YES or NO ANSWERS to the following. Not all options will be available without the proper kernel patches described later in this HOWTO. Run the following commands to configure your kernel:   * cd /usr/src/kernel/linux   * make menuconfig The following kernel prompts reflect a 2.2.20 kernel: +------------------------------------------------------------------------------------------------+ |[ Code maturity level options ] | | | | * Prompt for development and/or incomplete code/drivers (CONFIG_EXPERIMENTAL) [Y/n/?] | | - YES: though not entirely required for IP MASQ, this option allows the kernel | | to create possible additional MASQ modules such as PORTFW, etc. | | | | == Non-MASQ options skipped | | == (CPU, memory, MTRR, SMP, etc.) | | | | | |[ Loadable module support ] | | | | * Enable loadable module support (CONFIG_MODULES) [Y/n/?] y | | - YES: allows you to load kernel IP MASQ modules | | | | * Set version information on all symbols for modules (CONFIG_MODVERSIONS) [N/y/?] y | | - YES: allows newer kernels to load older modules if possible | | | | * Kernel module loader (CONFIG_KMOD) [Y/n/?] y | | - OPTIONAL: Recommended : allows the kernel to load various kernel modules as | | it needs them | | | | | |[ General setup ] | | | | * Networking support (CONFIG_NET) [Y/n/?] | | - YES: This enables the network subsystem | | | | == Non-MASQ options skipped | | == (PCI, kernel binaries, specific hardware options, etc.) | | | | | | * Sysctl support (CONFIG_SYSCTL) [Y/n/?] | | - YES: Enables the ability to enable disable options such as forwarding, | | dynamic IPs, etc. via the /proc interface | | | | | |[ Block devices ] | | | | == Non-MASQ options skipped | | == (kernel binaries, power management, PnP, IDE, SCSI, etc.) | | | | == Don't forget to compile in support for hardware that you might need: | | == IDE controllers, HDs, CDROMs, etc. | | | | | |[ Networking options ] | | | | | | * Packet socket (CONFIG_PACKET) [Y/m/n/?] y | | - YES: Though this is OPTIONAL, this recommended feature will allow you | | to use TCPDUMP to debug any problems with IP MASQ | | | | * Kernel/User netlink socket (CONFIG_NETLINK) [Y/n/?] y | | - OPTIONAL: Recommended : This feature will allow the logging of | | advanced firewall issues such as routing messages, etc | | | | * Routing messages (CONFIG_RTNETLINK) [Y/n/?] y | | - OPTIONAL: If you enabled the CONFIG_NETLINK option above, this option | | will send routing messages and other information to SYSLOG. | | | | * Netlink device emulation (CONFIG_NETLINK_DEV) [N/y/m/?] (NEW) n | | - NO: This option does not have anything to do with packet firewall | | logging | | | | * Network firewalls (CONFIG_FIREWALL) [Y/n/?] y | | - YES: Enables the kernel to be comfigured by the IPCHAINS firewall tool | | | | * Socket Filtering (CONFIG_FILTER) [Y/n/?] y | | - OPTIONAL: Though this doesn't have anything do with IPMASQ, if you | | plan on implimenting a DHCP server on the internal network, you | | WILL need this option. | | | | * Unix domain sockets (CONFIG_UNIX) [Y/m/n/?] y | | - YES: This enables the UNIX TCP/IP sockets mechanisms | | | | * TCP/IP networking (CONFIG_INET) [Y/n/?] y | | - YES: Enables the TCP/IP protocol | | | | * IP: multicasting (CONFIG_IP_MULTICAST) [N/y/?] y | | - OPTIONAL: You can enable this if you want to be able to receive | | Multicast traffic. Please note that your ISP must | | support Multicast as well for this all to work | | | | * IP: advanced router (CONFIG_IP_ADVANCED_ROUTER) [Y/n/?] n | | - OPTIONAL: Though there is nothing in this section mandatory for | | Masquerade, some specific options might be useful | | | | * IP: kernel level autoconfiguration (CONFIG_IP_PNP) [N/y/?] ? | | - NO: Not needed for normal MASQ functionality | | | | * IP: firewalling (CONFIG_IP_FIREWALL) [Y/n/?] y | | - YES: This enables the kernel to support packet filtering, NAT, etc. | | | | * IP: firewall packet netlink device (CONFIG_IP_FIREWALL_NETLINK) [Y/n/?] n | | - OPTIONAL: Though this is OPTIONAL, this feature will allow IPCHAINS to | | copy some packets to UserSpace tools for additional checks | | | | * IP: transparent proxy support (CONFIG_IP_TRANSPARENT_PROXY) [N/y/?] n | | - OPTIONAL: Not needed for normal MASQ functionality though people who | | want to do transparent proxy via Squid will want this. Please note | | that there is a PERFORMANCE PENALTY enabling this feature. | | | | * IP: masquerading (CONFIG_IP_MASQUERADE) [Y/n/?] y | | - YES: Enable IP Masquerade to re-address specific internal to external | | TCP/IP packets | | | | * IP: ICMP masquerading (CONFIG_IP_MASQUERADE_ICMP) [Y/n/?] y | | - YES: Enable support for masquerading ICMP ping packets (ICMP error | | codes will be MASQed regardless). This is an important feature | | for troubleshooting connections. | | | | * IP: masquerading special modules support (CONFIG_IP_MASQUERADE_MOD) [Y/n/?] y | | - YES: Though OPTIONAL, this enables the option to later enable other | | modules like the PORTFW to give external computers a directly | | connection to specified internal MASQed machines. | | | | * IP: ipautofw masq support (EXPERIMENTAL) (CONFIG_IP_MASQUERADE_IPAUTOFW) [N/y/m/?] n | | - NO: NOT recommended : IPautofw is a legacy method of port forwarding. It | | is mainly old code and has been found to have some issues. | | | | * IP: ipportfw masq support (EXPERIMENTAL) (CONFIG_IP_MASQUERADE_IPPORTFW) [Y/m/n/?] y | | - OPTIONAL: Recommended : This enables PORTFW which allows external computers | | on the Internet to directly communicate to specified internal MASQed | | machines. This feature is typically used to allow access to internal | | SMTP, TELNET, and WWW servers. Please note that FTP port forwarding | | needs an additional patch, as described in the FAQ section of the MASQ | | HOWTO. Please see the this FAQ section in the HOWTO for additional | | information. | | | | * IP: ip fwmark masq-forwarding support (EXPERIMENTAL) (CONFIG_IP_MASQUERADE_MFW) [Y/m/n/?] y | | - OPTIONAL: This is a NEW method of performing PORTFW-like functionality which is | | similar to how the new 2.4.x kernels do things. With this option, IPCHAINS | | can mark packets that should have additional work done upon it. Using a | | UserSpace tool, much like IPMASQADM or IPPORFW, IPCHAINS would then | | do things like re-address the packets, change their TOS value, etc. | | Currently, this code is less tested than PORTFW but it looks promising. | | For now, this HOWTO recommends to use IPMASQADM and IPPORTFW. If you | | have specific thoughts or comments on MFW, please email dranch. | | | | * IP: optimize as a router not host (CONFIG_IP_ROUTER) [Y/n/?] y | | - YES: This optimizes the kernel for the network subsystem, though it | | isn't well known if this makes a siginificant performance difference | | or not. | | | | == Non-MASQ options skipped | | == ( autoconf, tunneling, GRE ) | | | | | | * IP: multicast routing (CONFIG_IP_MROUTE) [N/y/?] n | | - OPTIONAL: Though not needed for IPMASQ, enabling this feature will | | let you route multicast traffic through your Linux box. | | Please note that this requires that your ISP be multicast | | enabled as well. | | | | | | == Non-MASQ options skipped | | == (Aliasing, ARPd) | | | | * IP: TCP syncookie support (disabled per default) (CONFIG_SYN_COOKIES) [Y/n/?] | | - YES: Recommended : for basic TCP/IP network security | | | | * IP: GRE tunnels over IP (CONFIG_NET_IPGRE) [N/y/m/?] | | - NO: This OPTIONAL selection is to enable PPTP and GRE tunnels through | | the IP MASQ box | | | | == Non-MASQ options skipped | | == (aliasing, ARPd) | | | | | | * IP: TCP syncookie support (not enabled per default) (CONFIG_SYN_COOKIES) [Y/n/?] | | - YES: HIGHLY recommended for basic TCP/IP network security | | | | == Non-MASQ options skipped | | == (RARP) | | | | | | * IP: Allow large windows (not recommended if <16Mb of memory) * (CONFIG_SKB_LARGE) [Y/n/?] | | - YES: This is recommended to optimize Linux's TCP window | | | | == Non-MASQ options skipped | | == (IPv6, IPX, WAN router, etc.) | | | | * Fast switching (read help!) (CONFIG_NET_FASTROUTE) [N/y/?] n | | - NO: This performance optimization is NOT compatible with IP MASQ and/or | | packet filtering | | | | | | == Non-MASQ options skipped | | == (Slow CPU, Telephony, SCSI, I2O, etc. ) | | | | == Don't forget to compile in support for hardware that you might need: | | == SCSI: HDs, CDROMs, etc. | | | | | |[ Network device support ] | | | | * Network device support (CONFIG_NETDEVICES) [Y/n/?] | | - YES: Enables the Linux Network device sublayer | | | | | | == Non-MASQ options skipped | | == (Arcnet) | | | | | | * Dummy net driver support (CONFIG_DUMMY) [M/n/y/?] | | - YES: Though OPTIONAL, this option can help when debugging problems | | | | | | == Non-MASQ options skipped | | == (EQL, NICs, Wireless, IrDA, ISDN, etc..) | | | | == Don't forget to compile in support for hardware that you might need: | | == NICs: eth, tr, etc. | | == MODEMs: ppp and/or slip | | == WANs: T1, T3, ISDN, etc. | | == ISDN: for internal ISDN modems | | | | | | [ Character devices ] | | | | == Don't forget to compile in serial port support for modem users | | == Don't forget to compile in mouse support | | | | | | == Non-MASQ options skipped | | == (I2C, Watchdog cards, Ftape, Video for Linux, USB, etc. ) | | | | | |[ File systems ] | | | | == Non-MASQ options skipped | | == (Quota, ISO9660, NTFS, etc ) | | | | | | * /proc filesystem support (CONFIG_PROC_FS) [Y/n/?] | | - YES: Required to dynamically configure the Linux forwarding | | and NATing systems | | | | | | == Non-MASQ options skipped | | == (network fs, NLS, video section, sound, kernel hacking) | +------------------------------------------------------------------------------------------------+ So go ahead and "exit" and you should be prompted to save your config. NOTE: These are just the components you need for IP Masquerade. You will need to select whatever other options needed for your specific setup.   * Now compile the kernel (make dep; make clean; make bzImage; make modules; make modules_install) , etc. Again, it is beyond the scope of this HOWTO if you have problems compiling your kernel. Please see Section 2.7 for URLs to the KERNEL howto, etc.   * You will then have move over the kernel binary, update your bootloader (LILO, Grub, etc.), and reboot. If you have questions about kernel compiling, I highly recommend to consult some of the URLs above in this section. ----------------------------------------------------------------------------- 3.2.3. Compiling Linux 2.0.x Kernels Please see Section 2.8 for any required software, patches, etc.   * First of all, you need the kernel source for 2.0.x (preferably the latest kernel version)   + As the 2.0.x train progress, the compile-time options keep on changing. As of this version, this section reflects the settings for a 2.0.39 kernel.   * If this is your first time compiling the kernel, don't be scared. In fact, it's rather easy and it's covered in several URLs found in Section 2.8. Please note that the instructions included here is just one way to do build a kernel. Please see the Kernel HOWTO for full details. NOTE: Please notice that it isn't recommended to put the new kernel sources into /usr/src/linux. You should leave the original kernel sources that came with your Linux distribution in /usr/src/linux. For more details on this topic, please read the "README" file in the top level directory of your kernel sources.   * For this HOWTO example, create a directory called /usr/src/kernel. Next, "cd" into this directory and download the newest 2.0.x kernel sources into it. Once downloaded, issue the following command: tar xvzf linux-2.0.x.tar.gz . Please substitute the "x" in the 2.0.x filename with the Linux 2.0 kernel version you downloaded. Once uncompressed, I recommend that you rename the directory from "linux" to "linux-2.0.x" for clarity. To do this, run the command mv linux linux-2.0.x. Next, make sure there is a directory or symbolic link pointing to /usr/src/kernel/linux ie. run the command: ln -s /usr/src/ kernel/linux-2.0.x /usr/src/kernel/linuxo again subsituting the "x" for your proper kernel version.   * Apply any appropriate or optional patches to the kernel source code. By default, stock Linux kernels do not require any specific patching in order for the system to work. Features like IPPORTFW, PPTP, and Xwindows forwarders are optional but very useful. Please refer to Section 2.8 for URLs and the [http://ipmasq.webhop.net/] IP Masquerade Resources for up-to-date information and patch URLs.   * Now that the kernel is patched up (if required), here are the MINIMUM kernel configuration options required to enable IP Masquerade functionality. Please understand that this HOWTO illustrates just ONE way to compile a kernel. The main difference from this method vs. a different one is some people wish to compile things either as modules OR monolithically right into the kernel. Basically, compiling things as modules gives you added flexibility to what is or isn't installed into the kernel (reduces unneeded memory use and allow for drop-in upgrades [no need to reboot]) BUT they add more complexity to your configuration. On the flip side, compiling things directly into the kernel makes things simpler BUT you loose a level of flexibility. The following example is a mixture of both built-in AND modules. Side Note: It is assumed that you will also configure the kernel to use your other installed hardware such as network interfaces, optional SCSI controllers, etc. as well. Please refer to the Linux Kernel HOWTO and the kernel source's "README" file and "Documentation/" directory for detailed help on compiling a kernel. Please note the YES or NO ANSWERS to the following options. Not all options will be available without the proper kernel patches described later in this HOWTO: Run the following commands to configure your kernel:   * cd /usr/src/kernel/linux   * make menuconfig The following kernel prompts reflect a 2.0.39 kernel: +--------------------------------------------------------------------------------------------------+ |[ Code maturity level options ] | | | | * Prompt for development and/or incomplete code/drivers (CONFIG_EXPERIMENTAL) [Y/n/?] | | - YES: this will allow you to later select the IP Masquerade feature code | | | | | |[ Loadable module support ] | | | | * Enable loadable module support (CONFIG_MODULES) [Y/n/?] y | | - YES: allows you to load kernel IP MASQ modules | | | | * Set version information on all module symbols (CONFIG_MODVERSIONS) [N/y/?] y | | - YES: allows newer kernels to load older modules if possible | | | | * Kernel daemon support (e.g. autoload of modules) (CONFIG_KERNELD) [N/y/?] y | | - OPTIONAL: Recommended : allows the kernel to load various kernel modules as | | it needs them | | | | | |[ General setup ] | | | | == Non-MASQ options skipped | | == (FPU, memory) | | | | * Networking support (CONFIG_NET) [Y/n/?] y | | - YES: Enables the network subsystem | | | | == Non-MASQ options skipped | | == (memory, PCI, binary format, APM, etc.) | | | | == Don't forget to compile in support for hardware that you might need: | | == IDE controllers, HDs, CDROMs, etc. | | | | | |[ Networking options ] | | | | * Network firewalls (CONFIG_FIREWALL) [Y/n/?] y | | - YES: Enables the IPFWADM firewall tool | | | | == Non-MASQ options skipped | | == (Aliasing) | | | | | | * TCP/IP networking (CONFIG_INET) [Y/n/?] y | | - YES: Enables the TCP/IP protocol | | | | * IP: forwarding/gatewaying (CONFIG_IP_FORWARD) [N/y/?] y | | - YES: Enables Linux network packet forwarding and routing | | - Controlled by IPFWADM | | | | * IP: multicasting (CONFIG_IP_MULTICAST) [N/y/?] y | | - OPTIONAL: You can enable this if you want to be able to receive | | Multicast traffic. Please note that your ISP must | | support Multicast as well for this all to work | | | | * IP: syn cookies (CONFIG_SYN_COOKIES) [Y/n/?] y | | - YES: HIGHLY recommended for basic network security | | | | * IP: firewalling (CONFIG_IP_FIREWALL) [Y/n/?] y | | - YES: Enable the packet firewall features | | | | * IP: firewall packet logging (CONFIG_IP_FIREWALL_VERBOSE) [Y/n/?] y | | - YES: Allows the kernel to report back on various packets traversing | | the firewall. | | | | * IP: masquerading (CONFIG_IP_MASQUERADE [Y/n/?] y | | - YES: Enable the kernel to perform IP MASQ NAT functionality | | | | * IP: ipautofw masquerade support (EXPERIMENTAL) (CONFIG_IP_MASQUERADE_IPAUTOFW) [Y/n/?] n | | - NO: NOT Recommended : IPautofw is a legacy method of TCP/IP port forwarding. | | Though IPautofw works, IPPORTFW is a better choice. | | | | | | * IP: ipportfw masq support (EXPERIMENTAL) (CONFIG_IP_MASQUERADE_IPPORTFW) [Y/n/?] y | | - YES: This option is ONLY AVAILABLE VIA A PATCH for the 2.0.x kernels. | | With this option, external computers on the Internet can directly | | communicate to specified internal MASQed machines. This feature is | | typically used to access internal SMTP, TELNET, and WWW servers. | | FTP port forwarding sometimes might require an additional patch as | | described in the FAQ section. Additional information on port | | forwarding is available in the Forwards section of this HOWTO. | | | | | | * IP: MS PPTP masq support (EXPERIMENTAL) (CONFIG_IP_MASQUERADE_PPTP) [N/y/?] (NEW) n | | - OPTIONAL: Enabling this feature will allow internal MASQ clients to | | properly connect to PPTP servers on the Internet. | | | | * IP: MS PPTP Call ID masq support (CONFIG_IP_MASQUERADE_PPTP_MULTICLIENT) [N/y/?] (NEW) n | | - OPTIONAL: If you enabled the CONFIG_IP_MASQUERADE_PPTP above, this | | option will allow for multiple internal PPTP clients behind the MASQ | | server to communicate to the same PPTP server. | | | | * IP: MS PPTP masq debugging (DEBUG_IP_MASQUERADE_PPTP) [N/y/?] n | | - OPTIONAL: NOT recommended : This is not required for IP MASQ or MASQing PPTP | | connections unless you need additional troubleshooting help. If enabled, | | this can fill up your logs quickly. | | | | * IP: MS PPTP masq verbose debugging (DEBUG_IP_MASQUERADE_PPTP_VERBOSE) [N/y/?] (NEW) n | | - OPTIONAL: NOT Recommended : If you enabled the DEBUG_IP_MASQUERADE_PPTP | | option above, this will make the logging even more verbose. | | | | * IP: IPSEC ESP & ISAKMP masq support (EXPERIMENTAL) * (CONFIG_IP_MASQUERADE_IPSEC) [N/y/?] m | | - OPTIONAL: This option allows for some forms of IPSEC tunnels to be | | masquraded | | | | * IP: IPSEC masq table lifetime (minutes) (CONFIG_IP_MASQUERADE_IPSEC_EXPIRE) * [30] (NEW) | | - OPTIONAL: This feature allows to change the MASQ table timeouts so that | | idle IPSEC tunnels won't be prematurely disconnected. | | | | * IP: Disable inbound ESP destination guessing * (CONFIG_IP_MASQUERADE_IPSEC_NOGUESS) [N/y/?] n | | - OPTIONAL: This feature allows the kernel to guess where the fully encrypted IPSEC VPN | | might be going and add it to the MASQ table. | | | | * IP: IPSEC masq debugging (DEBUG_IP_MASQUERADE_IPSEC) [N/y/?] ? n | | - OPTIONAL: NOT recommended : This is not required for IP MASQ or MASQing IPSEC | | connections unless you need additional troubleshooting help. If enabled, | | this can fill up your logs quickly. | | | | * IP: IPSEC masq verbose debugging (DEBUG_IP_MASQUERADE_IPSEC_VERBOSE) [N/y/?] (NEW) n | | - OPTIONAL: NOT Recommended : If you enabled the DEBUG_IP_MASQUERADE_IPSEC | | option above, this will make the logging even more verbose. | | | | | | * IP: ICMP masquerading (CONFIG_IP_MASQUERADE_ICMP) [Y/n/?] | | - YES: Enable support for masquerading ICMP packets. Though thought of as | | optional, many programs will NOT function properly with out ICMP | | support. | | | | * IP: transparent proxy support (EXPERIMENTAL) (CONFIG_IP_TRANSPARENT_PROXY) [N/y/?] n | | - OPTIONAL: Not needed for normal MASQ functionality though people who | | want to do transparent proxy via Squid will want this. Please note | | that there is a PERFORMANCE PENALTY enabling this feature. | | | | * IP: loose UDP port managing (EXPERIMENTAL) (CONFIG_IP_MASQ_LOOSE_UDP) [Y/n/?] | | - YES: This option is ONLY AVAILABLE VIA A PATCH for the 2.0.x kernels. | | With this option, internally masqueraded computers can play | | NAT-friendly games over the Internet. Explicit details are given | | in the FAQ section of this HOWTO. | | | | * IP: always defragment (CONFIG_IP_ALWAYS_DEFRAG) [Y/n/?] | | - YES: This feature optimizes IP MASQ connections | | | | == Non-MASQ options skipped | | == (Accounting) | | | | | | * IP: optimize as router not host (CONFIG_IP_ROUTER) [Y/n/?] | | - YES: This optimizes the kernel for the network subsystem | | | | == Non-MASQ options skipped | | == (Tunneling, Mcast routing, RARP, PMTU, etc.) | | | | | | * IP: Drop source routed frames (CONFIG_IP_NOSR) [Y/n/?] | | - YES: HIGHLY recommended for basic network security | | | | == Non-MASQ options skipped | | == (IPX, Bridging, SCSI, etc.) | | | | == Don't forget to compile in support for hardware that you might need: | | == SCSI controllers, HDs, CDROMs, etc. | | | | | |[ Network device support ] | | | | * Network device support (CONFIG_NETDEVICES) [Y/n/?] | | - YES: Enables the Linux Network device sublayer | | | | | | == Non-MASQ options skipped | | == (Dummy, EQL, PPP, SLIP, NICs, Wireless, etc.) | | | | == Don't forget to compile in support for hardware that you might need: | | == NICs: eth, tr, etc. | | == MODEMs: ppp and/or slip | | == WANs: T1, T3, ISDN, etc. | | == ISDN: for internal ISDN modems | | | | | |[ File systems ] | | | | == Non-MASQ options skipped | | == (Quota, ISO9660, Codepages, NTFS, etc ) | | | | | | * /proc filesystem support (CONFIG_PROC_FS) [Y/n/?] | | - YES: Required to dynamically configure the Linux forwarding | | and NATing systems | | | | | | [ Character devices ] | | | | == Non-MASQ options skipped | | == (multi-port serial, parallel, mice, Ftape, Sound, etc. ) | | | | == Don't forget to compile in serial port support for modem users | | == Don't forget to compile in mouse support | | | +--------------------------------------------------------------------------------------------------+ So go ahead and "exit" and you should be prompted to save your config. NOTE: These are only components for IP Masquerade functionality. You may need to also select additional options to match your specific network and hardware setup.   * Now compile the kernel (make dep; make clean; make bzImage; make modules; make modules_install) , etc. Again, it is beyond the scope of this HOWTO if you have problems compiling your kernel. Please see Section 2.8 for URLs to the KERNEL howto, etc.   * You will then have move over the kernel binary, update your bootloader (LILO, Grub, etc.), and reboot. If you have questions about kernel compiling, I highly recommend to consult some of the URLs above in this section. ----------------------------------------------------------------------------- 3.3. Assigning Private Network IP Addresses to the Internal LAN Since all INTERNAL MASQed machines should NOT have official Internet assigned addressees, there must be a specific and accepted way to allocate addresses to those machines without conflicting with anyone else's Internet address. From the original IP Masquerade FAQ: RFC 1918 is the official document on which IP addresses are to be used in a non-connected or "private" network. There are 3 blocks of numbers set aside specifically for this purpose. +-------------------------------------------------------------------------------+ |Section 3: Private Address Space | | | |The Internet Assigned Numbers Authority (IANA) has reserved the | |following three blocks of the IP address space for private networks: | | | | 10.0.0.0 - 10.255.255.255 | | 172.16.0.0 - 172.31.255.255 | | 192.168.0.0 - 192.168.255.255 | | | |We will refer to the first block as "24-bit block", the second as "20-bit | |block", and the third as "16-bit" block". Note that the first block is | |nothing but a single class A network number, while the second block is a set | |of 16 continuous class B network numbers, and the third block is a set of 255 | |continuous class C network numbers. | +-------------------------------------------------------------------------------+ For the record, my preference is to use the 192.168.0.0 network with a 255.255.255.0 Class-C subnet mask and thus this HOWTO reflects this. Any of the above private networks are valid, but just be SURE to use the correct subnet-mask. So, if you're using a Class-C network, you should number your TCP/IP enabled machines as 192.168.0.1, 192.168.0.2, 192.168.0.3, .., 192.168.0.x 192.168.0.1 is usually set as the internal gateway or Linux MASQ machine which reaches the external network. Please note that 192.168.0.0 and 192.168.0.255 are the Network and Broadcast address respectively (these addresses are RESERVED). Avoid using these addresses on your machines or your network will not function properly. ----------------------------------------------------------------------------- 3.4. Configuring IP Forwarding Policies At this point, you should have your kernel and other required packages installed. All network IP addresses, gateway, and DNS addresses should be configured on your Linux MASQ server. If you don't know how to configure your Linux network cards, please consult the HOWTOs listed in either the 2.4.x Section 2.6, the 2.2.x Section 2.7, or the 2.0.x Section 2.8. Now, the only thing left to do is to configure the IP firewalling tools to both FORWARD and MASQUERADE the appropriate packets to the correct machine. ** This section ONLY provides the user with the bare minimum firewall ruleset to get IP Masquerading working. Once IP MASQ has been successfully tested (as described later in this HOWTO), please refer to the Stronger IPTABLES ruleset for 2.4.x kernels in Section 6.4.1, the Stronger IPCHAINS ruleset for 2.2.x kernels in Section 6.4.2, and the Stronger IPFWADM ruleset for 2.0.x kernels in Section 6.4.3. Please note that these stronger firewall rulesets are more of a template than anything else. For truly secure firewall rulesets, check out the the requirements section of the HOWTO ( 2.4.x - Section 2.6, 2.2.x - Section 2.7, 2.0.x - Section 2.8 ). Instead of manually typing one of these files by hand, I recommend to simply browse the Example directory or [http://www.ecst.csuchico.edu/~dranch/LINUX/ ipmasq/examples/rc.firewall-examples.tar.gz] download an archive of all of these rc.firewall-* files. ----------------------------------------------------------------------------- 3.4.1. Configuring IP Masquerade on Linux 2.6.x and 2.4.x Kernels Please note that IPCHAINS is no longer the primary firewall configuration tool for the 2.6.x and 2.4.x kernels. The new kernels now use the IPTABLES toolkit though the new 2.4.x kernels CAN still run most old IPCHAINS or IPFWADM rulesets via a compatiblity module. It should also be noted that when running in this compatibility mode, NO IPTABLES modules can be loaded. The reason for this is that none of the 2.2.x IPMASQ modules are compatible with 2.4.x kernels. For a more detailes for these changes, please see the Section 7.40 section. Ok, as mentioned before, the /etc/rc.d/rc.local-* script can be loaded once after every reboot. The mechanism to load the script varies between different Linux distros (please see below for some exampels). The rc.firewall-iptables script will load all required IPMASQ modules as well as enable the final IPMASQ functionality. For advanced setups, this same file would contain very secure firewall rulesets as well. Anyway, create the file /etc/rc.d/rc.firewall-iptables with the following initial SIMPLE ruleset: +----------------------------------------------------------------------------------------+ |#!/bin/sh | |# | |# rc.firewall-iptables | |FWVER=0.76 | |# | |# Initial SIMPLE IP Masquerade test for 2.6 / 2.4 kernels | |# using IPTABLES. | |# | |# Once IP Masquerading has been tested, with this simple | |# ruleset, it is highly recommended to use a stronger | |# IPTABLES ruleset either given later in this HOWTO or | |# from another reputable resource. | |# | |# | |# | |# Log: | |# 0.76 - Added comments on why the default policy is ACCEPT | |# 0.75 - Added more kernel modules to the comments section | |# 0.74 - the ruleset now uses modprobe vs. insmod | |# 0.73 - REJECT is not a legal policy yet; back to DROP | |# 0.72 - Changed the default block behavior to REJECT not DROP | |# 0.71 - Added clarification that PPPoE users need to use | |# "ppp0" instead of "eth0" for their external interface | |# 0.70 - Added commented option for IRC nat module | |# - Added additional use of environment variables | |# - Added additional formatting | |# 0.63 - Added support for the IRC IPTABLES module | |# 0.62 - Fixed a typo on the MASQ enable line that used eth0 | |# instead of $EXTIF | |# 0.61 - Changed the firewall to use variables for the internal | |# and external interfaces. | |# 0.60 - 0.50 had a mistake where the ruleset had a rule to DROP | |# all forwarded packets but it didn't have a rule to ACCEPT | |# any packets to be forwarded either | |# - Load the ip_nat_ftp and ip_conntrack_ftp modules by default | |# 0.50 - Initial draft | |# | | | |echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n" | | | | | |# The location of the iptables and kernel module programs | |# | |# If your Linux distribution came with a copy of iptables, | |# most likely all the programs will be located in /sbin. If | |# you manually compiled iptables, the default location will | |# be in /usr/local/sbin | |# | |# ** Please use the "whereis iptables" command to figure out | |# ** where your copy is and change the path below to reflect | |# ** your setup | |# | |#IPTABLES=/sbin/iptables | |IPTABLES=/usr/local/sbin/iptables | |DEPMOD=/sbin/depmod | |MODPROBE=/sbin/modprobe | | | | | |#Setting the EXTERNAL and INTERNAL interfaces for the network | |# | |# Each IP Masquerade network needs to have at least one | |# external and one internal network. The external network | |# is where the natting will occur and the internal network | |# should preferably be addressed with a RFC1918 private address | |# scheme. | |# | |# For this example, "eth0" is external and "eth1" is internal" | |# | |# | |# NOTE: If this doesnt EXACTLY fit your configuration, you must | |# change the EXTIF or INTIF variables above. For example: | |# | |# If you are a PPPoE or analog modem user: | |# | |# EXTIF="ppp0" | |# | |# | |EXTIF="eth0" | |INTIF="eth1" | |echo " External Interface: $EXTIF" | |echo " Internal Interface: $INTIF" | | | | | |#====================================================================== | |#== No editing beyond this line is required for initial MASQ testing == | | | | | |echo -en " loading modules: " | | | |# Need to verify that all modules have all required dependencies | |# | |echo " - Verifying that all kernel modules are ok" | |$DEPMOD -a | | | |# With the new IPTABLES code, the core MASQ functionality is now either | |# modular or compiled into the kernel. This HOWTO shows ALL IPTABLES | |# options as MODULES. If your kernel is compiled correctly, there is | |# NO need to load the kernel modules manually. | |# | |# NOTE: The following items are listed ONLY for informational reasons. | |# There is no reason to manual load these modules unless your | |# kernel is either mis-configured or you intentionally disabled | |# the kernel module autoloader. | |# | | | |# Upon the commands of starting up IP Masq on the server, the | |# following kernel modules will be automatically loaded: | |# | |# NOTE: Only load the IP MASQ modules you need. All current IP MASQ | |# modules are shown below but are commented out from loading. | |# =============================================================== | | | |echo "----------------------------------------------------------------------" | | | |#Load the main body of the IPTABLES module - "iptable" | |# - Loaded automatically when the "iptables" command is invoked | |# | |# - Loaded manually to clean up kernel auto-loading timing issues | |# | |echo -en "ip_tables, " | |$MODPROBE ip_tables | | | | | |#Load the IPTABLES filtering module - "iptable_filter" | |# - Loaded automatically when filter policies are activated | | | | | |#Load the stateful connection tracking framework - "ip_conntrack" | |# | |# The conntrack module in itself does nothing without other specific | |# conntrack modules being loaded afterwards such as the "ip_conntrack_ftp" | |# module | |# | |# - This module is loaded automatically when MASQ functionality is | |# enabled | |# | |# - Loaded manually to clean up kernel auto-loading timing issues | |# | |echo -en "ip_conntrack, " | |$MODPROBE ip_conntrack | | | | | |#Load the FTP tracking mechanism for full FTP tracking | |# | |# Enabled by default -- insert a "#" on the next line to deactivate | |# | |echo -en "ip_conntrack_ftp, " | |$MODPROBE ip_conntrack_ftp | | | | | |#Load the IRC tracking mechanism for full IRC tracking | |# | |# Enabled by default -- insert a "#" on the next line to deactivate | |# | |echo -en "ip_conntrack_irc, " | |$MODPROBE ip_conntrack_irc | | | | | |#Load the general IPTABLES NAT code - "iptable_nat" | |# - Loaded automatically when MASQ functionality is turned on | |# | |# - Loaded manually to clean up kernel auto-loading timing issues | |# | |echo -en "iptable_nat, " | |$MODPROBE iptable_nat | | | | | |#Loads the FTP NAT functionality into the core IPTABLES code | |# Required to support non-PASV FTP. | |# | |# Enabled by default -- insert a "#" on the next line to deactivate | |# | |echo -en "ip_nat_ftp, " | |$MODPROBE ip_nat_ftp | | | | | |#Loads the IRC NAT functionality into the core IPTABLES code | |# Required to support NAT of IRC DCC requests | |# | |# Disabled by default -- remove the "#" on the next line to activate | |# | |#echo -e "ip_nat_irc" | |#$MODPROBE ip_nat_irc | | | |echo "----------------------------------------------------------------------" | | | |# Just to be complete, here is a partial list of some of the other | |# IPTABLES kernel modules and their function. Please note that most | |# of these modules (the ipt ones) are automatically loaded by the | |# master kernel module for proper operation and don't need to be | |# manually loaded. | |# -------------------------------------------------------------------- | |# | |# ip_nat_snmp_basic - this module allows for proper NATing of some | |# SNMP traffic | |# | |# iptable_mangle - this target allows for packets to be | |# manipulated for things like the TCPMSS | |# option, etc. | |# | |# -- | |# | |# ipt_mark - this target marks a given packet for future action. | |# This automatically loads the ipt_MARK module | |# | |# ipt_tcpmss - this target allows to manipulate the TCP MSS | |# option for braindead remote firewalls. | |# This automatically loads the ipt_TCPMSS module | |# | |# ipt_limit - this target allows for packets to be limited to | |# to many hits per sec/min/hr | |# | |# ipt_multiport - this match allows for targets within a range | |# of port numbers vs. listing each port individually | |# | |# ipt_state - this match allows to catch packets with various | |# IP and TCP flags set/unset | |# | |# ipt_unclean - this match allows to catch packets that have invalid | |# IP/TCP flags set | |# | |# iptable_filter - this module allows for packets to be DROPped, | |# REJECTed, or LOGged. This module automatically | |# loads the following modules: | |# | |# ipt_LOG - this target allows for packets to be | |# logged | |# | |# ipt_REJECT - this target DROPs the packet and returns | |# a configurable ICMP packet back to the | |# sender. | |# | | | |echo -e " Done loading modules.\n" | | | | | | | |#CRITICAL: Enable IP forwarding since it is disabled by default since | |# | |# Redhat Users: you may try changing the options in | |# /etc/sysconfig/network from: | |# | |# FORWARD_IPV4=false | |# to | |# FORWARD_IPV4=true | |# | |echo " Enabling forwarding.." | |echo "1" > /proc/sys/net/ipv4/ip_forward | | | | | |# Dynamic IP users: | |# | |# If you get your IP address dynamically from SLIP, PPP, or DHCP, | |# enable this following option. This enables dynamic-address hacking | |# which makes the life with Diald and similar programs much easier. | |# | |echo " Enabling DynamicAddr.." | |echo "1" > /proc/sys/net/ipv4/ip_dynaddr | | | | | |# Enable simple IP forwarding and Masquerading | |# | |# NOTE: In IPTABLES speak, IP Masquerading is a form of SourceNAT or SNAT. | |# | |# NOTE #2: The following is an example for an internal LAN address in the | |# 192.168.0.x network with a 255.255.255.0 or a "24" bit subnet mask | |# connecting to the Internet on external interface "eth0". This | |# example will MASQ internal traffic out to the Internet but not | |# allow non-initiated traffic into your internal network. | |# | |# | |# ** Please change the above network numbers, subnet mask, and your | |# *** Internet connection interface name to match your setup | |# | | | | | |#Clearing any previous configuration | |# | |# Unless specified, the defaults for INPUT and OUTPUT is ACCEPT | |# The default for FORWARD is DROP (REJECT is not a valid policy) | |# | |# Isn't ACCEPT insecure? To some degree, YES, but this is our testing | |# phase. Once we know that IPMASQ is working well, I recommend you run | |# the rc.firewall-*-stronger rulesets which set the defaults to DROP but | |# also include the critical additional rulesets to still let you connect to | |# the IPMASQ server, etc. | |# | |echo " Clearing any existing rules and setting default policy.." | |$IPTABLES -P INPUT ACCEPT | |$IPTABLES -F INPUT | |$IPTABLES -P OUTPUT ACCEPT | |$IPTABLES -F OUTPUT | |$IPTABLES -P FORWARD DROP | |$IPTABLES -F FORWARD | |$IPTABLES -t nat -F | | | |echo " FWD: Allow all connections OUT and only existing and related ones IN" | |$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED -j ACCEPT | |$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT | |$IPTABLES -A FORWARD -j LOG | | | |echo " Enabling SNAT (MASQUERADE) functionality on $EXTIF" | |$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE | | | |echo -e "\nrc.firewall-iptables v$FWVER done.\n" | +----------------------------------------------------------------------------------------+ Once you are finished with editing this /etc/rc.d/rc.firewall-iptables ruleset, make it executable by typing in chmod 700 /etc/rc.d/ rc.firewall-iptables Now that the firewall ruleset is ready, you need to let it run after every reboot. You could either do this by running it by hand everytime (such a pain) or add it to the boot scripts. We have covered two methods below: Redhat (SyS-V style) and Slackware (BSD style) 1. Redhat and Redhat-derived distros:   * There are two ways to automatically load things in Redhat: /etc/rc.d/ rc.local or a init script in /etc/rc.d/init.d/. The first method is the easiest but isn't doing things the SYS-V way. All you have to do is add the line: +---------------------------------------------------------------+ |echo "Loading the rc.firewall-iptables ruleset.. " | |/etc/rc.d/rc.firewall-iptables | +---------------------------------------------------------------+ to the end of the /etc/rc.d/rc.local file and thats it (as described earlier in the HOWTO). The problem with this approach is that the firewall isn't executed until the last stages of booting.   * The preferred approach is to have the firewall loaded just after the networking subsystem is loaded. To do this, copy the following file into the /etc/rc.d/init.d directory: +-------------------------------------------------------------------------------+ |#!/bin/sh | |# | |# chkconfig: 2345 11 89 | |# | |# description: Loads the rc.firewall-iptables ruleset. | |# | |# processname: firewall-iptables | |# pidfile: /var/run/firewall.pid | |# config: /etc/rc.d/rc.firewall-iptables | |# probe: true | | | |# ---------------------------------------------------------------------------- | |# v05/24/03 | |# | |# Part of the copyrighted and trademarked TrinityOS document. | |# http://www.ecst.csuchico.edu/~dranch | |# | |# Written and Maintained by David A. Ranch | |# dranch@trinnet.net | |# | |# Updates | |# ------- | |# 05/24/03 - removed a old networking up check that had some | |# improper SGML ampersand conversions. | |# ---------------------------------------------------------------------------- | | | | | |# Source function library. | |. /etc/rc.d/init.d/functions | | | |# Check that networking is up. | | | |[ "XXXX${NETWORKING}" = "XXXXno" ] && exit 0 | | | |[ -x /sbin/ifconfig ] || exit 0 | | | |# The location of various iptables and other shell programs | |# | |# If your Linux distribution came with a copy of iptables, most | |# likely it is located in /sbin. If you manually compiled | |# iptables, the default location is in /usr/local/sbin | |# | |# ** Please use the "whereis iptables" command to figure out | |# ** where your copy is and change the path below to reflect | |# ** your setup | |# | |IPTABLES=/usr/local/sbin/iptables | | | | | |# See how we were called. | |case "$1" in | | start) | | /etc/rc.d/rc.firewall-iptables | | ;; | | | | stop) | | echo -e "\nFlushing firewall and setting default policies to DROP\n" | | $IPTABLES -P INPUT DROP | | $IPTABLES -F INPUT | | $IPTABLES -P OUTPUT DROP | | $IPTABLES -F OUTPUT | | $IPTABLES -P FORWARD DROP | | $IPTABLES -F FORWARD | | $IPTABLES -F -t nat | | | | # Delete all User-specified chains | | $IPTABLES -X | | # | | # Reset all IPTABLES counters | | $IPTABLES -Z | | ;; | | | | restart) | | $0 stop | | $0 start | | ;; | | | | status) | | $IPTABLES -L | | ;; | | | | mlist) | | cat /proc/net/ip_conntrack | | ;; | | | | *) | | echo "Usage: firewall-iptables {start|stop|status|mlist}" | | exit 1 | |esac | | | |exit 0 | +-------------------------------------------------------------------------------+ With this script in place, all you need to do now is make it executable and then make it load upon reboot. First, make it executable by running: +---------------------------------------------------------------+ |#Redhat-style | |# | |chmod 700 /etc/rc.d/init.d/firewall-iptables | +---------------------------------------------------------------+ Now, enable the ruleset load upon reboot: +---------------------------------------------------------------+ |#Redhat style | |# | |/sbin/chkconfig --level=345 firewall-iptables on | +---------------------------------------------------------------+ That's it! Now upon reboot, the firewall will be loaded automatically. Just to make sure, run the following command to see that the firewall should start upon reboot by running the command: +---------------------------------------------------------------+ |#Redhat style | |# | |chkconfig --list firewall-iptables | | | |#The output should look like: | |# | |firewall-iptables 0:off 1:off 2:off 3:on 4:on 5:on 6:off | +---------------------------------------------------------------+ 2. Slackware:   * There are two ways to load things in Slackware: /etc/rc.d/rc.local or editing the /etc/rc.d/rc.inet2 file. The first method is the easiest but isn't the most secure (see below). All you have to do is append the following lines to the /etc/rc.d/rc.local file: +---------------------------------------------------------------+ |echo "Loading the rc.firewall-iptables ruleset.." | | | |/etc/rc.d/rc.firewall-iptables | +---------------------------------------------------------------+ The problem with this approach is that if you are running a STRONG firewall ruleset, the firewall isn't executed until the last stages of booting. The preferred approach is to have the firewall loaded just after the networking subsystem is loaded. For now, the HOWTO only covers how to do so using /etc/rc.d/rc.local but if you know what you're doing (it's easy), go ahead and and modify the inet2 startup script to load the /etc/ rc.d/rc.firewall-iptables file just after the network is up. If you want a more detailed guide and/or a stronger firewall ruleset, I recommend you check out Section 10 of TrinityOS found in the links section at the bottom of this HOWTO. Notes on how users might want to change the above firewall ruleset: You could also have IP Masquerading enabled on a PER MACHINE basis instead of the above method, which is enabling an ENTIRE TCP/IP network. For example, say if I wanted only the 192.168.0.2 and 192.168.0.8 hosts to have access to the Internet and NOT any of the other internal machines. I would change the in the "Enable simple IP forwarding and Masquerading" section (shown above) of the /etc/rc.d/rc.firewall-iptables ruleset. +---------------------------------------------------------------------------------+ |#!/bin/sh | |# | |# Partial IPTABLES config to enable simple IP forwarding and Masquerading | |# v0.61 | |# | |# NOTE: The following is an example to allow only IP Masquerading for the | |# 192.168.0.2 and 192.168.0.8 machines with a 255.255.255.0 or a | |# "/24" subnet mask connecting to the Internet on interface eth0. | |# | |# ** Please change the network number, subnet mask, and the Internet | |# ** connection interface name to match your internal LAN setup | |# | |echo " - Setting the default FORWARD policy to DROP" | |$IPTABLES -P FORWARD DROP | | | |echo " - Enabling SNAT (IPMASQ) functionality on $EXTIF" | |$IPTABLES -t nat -A POSTROUTING -o $EXTIF -s 192.168.0.2/32 -j MASQUERADE | |$IPTABLES -t nat -A POSTROUTING -o $EXTIF -s 192.168.0.8/32 -j MASQUERADE | | | |echo " - Setting the FORWARD policy to 'DROP' all incoming / unrelated traffic" | |$IPTABLES -A INPUT -i $EXTIF -m state --state NEW,INVALID -j DROP | |$IPTABLES -A FORWARD -i $EXTIF -m state --state NEW,INVALID -j DROP | +---------------------------------------------------------------------------------+ Common mistakes: It appears that a common mistake with new IP Masq users is to make the first command simply the following: +---------------------------------------------------------------------------+ |IPTABLES: | |--------- | |iptables -t nat -A POSTROUTING -j MASQUERADE | +---------------------------------------------------------------------------+ Do NOT make your default policy MASQUERADING. Otherwise, someone can manipulate their routing tables to tunnel straight back through your gateway, using it to masquerade their OWN identity! Again, you can add these lines to the /etc/rc.d/rc.firewall-iptables file, one of the other rc files you prefer, or do it manually every time you need IP Masquerade. Please see Section 6.4.1 for a detailed guide on a strong IPTABLES ruleset example. For additional details on IPTABLES usage, please refer to [http:// www.netfilter.org/] http://www.netfilter.org/ for the primary IPTABLES site. ----------------------------------------------------------------------------- 3.4.2. Configuring IP Masquerade on Linux 2.2.x Kernels Please note that IPFWADM is no longer the firewall tool for manipulating IP Masquerading rules for both the 2.1.x and 2.2.x kernels. These new kernels now use the IPCHAINS toolkit. For a more detailed reason for this change, please see Chapter 7. Create the file /etc/rc.d/rc.firewall-ipchains with the following initial SIMPLE ruleset: +---------------------------------------------------------------------------------+ |#!/bin/sh | |# | |# rc.firewall-ipchains | |# | |# - Initial SIMPLE IP Masquerade test for 2.1.x and 2.2.x kernels | |# using IPCHAINS. | |# | |# Once IP Masquerading has been tested, with this simple | |# ruleset, it is highly recommended to use a stronger | |# IPTABLES ruleset either given later in this HOWTO or | |# from another reputable resource. | | | |FWVER="1.23" | |# | |# 1.23 - Added comments on why the default policy is ACCEPT | |# 1.22 - ruleset now uses modprobe instead of insmod | |# 1.21 - Added clarification that PPPoE users need to use | |# "ppp0" instead of "eth0" for their external interface | |# 1.20 - Updated the script to use environment vars | |# 1.01 - Original version | | | | | |echo -e "\n\nLoading simple rc.firewall-ipchains : version $FWVER..\n" | | | | | |# The location of the ipchains and kernel module programs | |# | |# If your Linux distribution came with a copy of ipchains, | |# most likely all the programs will be located in /sbin. If | |# you manually compiled ipchains, the default location will | |# be in /usr/local/sbin | |# | |# ** Please use the "whereis ipchains" command to figure out | |# ** where your copy is and change the path below to reflect | |# ** your setup | |# | |IPCHAINS=/sbin/ipchains | |#IPTABLES=/usr/local/sbin/ipchains | |DEPMOD=/sbin/depmod | |MODPROBE=/sbin/modprobe | | | | | |#Setting the EXTERNAL and INTERNAL interfaces for the network | |# | |# Each IP Masquerade network needs to have at least one | |# external and one internal network. The external network | |# is where the NATing will occur and the internal network | |# should preferably be addressed with a RFC1918 private addressing | |# scheme. | |# | |# For this example, "eth0" is external and "eth1" is internal" | |# | |# NOTE: If this doesnt EXACTLY fit your configuration, you must | |# change the EXTIF or INTIF variables above. For example: | |# | |# If you are a PPPoE or analog modem user: | |# | |# EXTIF="ppp0" | |# | |# ** Please change this to reflect your specific configuration ** | |# | |EXTIF="eth0" | |INTIF="eth1" | |echo " External Interface: $EXTIF" | |echo " Internal Interface: $INTIF" | | | | | |# Network Address of the Internal Network | |# | |# This example rc.firewall-ipchains file uses the 192.168.0.0 network | |# with a /24 or 255.255.255.0 netmask. | |# | |# ** Change this variable to reflect your specific setup ** | |# | |INTLAN="192.168.0.0/24" | |echo -e " Internal Interface: $INTLAN\n" | | | | | | | |# Load all required IP MASQ modules | |# | |# NOTE: Only load the IP MASQ modules you need. All current IP MASQ modules | |# are shown below but are commented out from loading. | |echo " loading required IPMASQ kernel modules.." | | | |# Needed to initially load modules | |# | |$DEPMOD -a | | | |echo -en " Loading modules: " | | | |# Supports the proper masquerading of FTP file transfers using the PORT method | |# | |echo -en "FTP, " | |$MODPROBE ip_masq_ftp | | | |# Supports the masquerading of RealAudio over UDP. Without this module, | |# RealAudio WILL function but in TCP mode. This can cause a reduction | |# in sound quality | |# | |#echo -en "RealAudio, " | |$MODPROBE ip_masq_raudio | | | |# Supports the masquerading of IRC DCC file transfers | |# | |#echo -en "Irc, " | |#$MODPROBE ip_masq_irc | | | | | |# Supports the masquerading of Quake and QuakeWorld by default. This modules is | |# for for multiple users behind the Linux MASQ server. If you are going to | |# play Quake I, II, and III, use the second example. | |# | |# NOTE: If you get ERRORs loading the QUAKE module, you are running an old | |# ----- kernel that has bugs in it. Please upgrade to the newest kernel. | |# | |#echo -en "Quake, " | |#Quake I / QuakeWorld (ports 26000 and 27000) | |#$MODPROBE ip_masq_quake | |# | |#Quake I/II/III / QuakeWorld (ports 26000, 27000, 27910, 27960) | |#$MODPROBE ip_masq_quake 26000,27000,27910,27960 | | | | | |# Supports the masquerading of the CuSeeme video conferencing software | |# | |#echo -en "CuSeeme, " | |#$MODPROBE ip_masq_cuseeme | | | |#Supports the masquerading of the VDO-live video conferencing software | |# | |#echo -en "VdoLive " | |#$MODPROBE ip_masq_vdolive | | | |echo ". Done loading modules." | | | | | |#CRITICAL: Enable IP forwarding since it is disabled by default since | |# | |# Redhat Users: you may try changing the options in | |# /etc/sysconfig/network from: | |# | |# FORWARD_IPV4=false | |# to | |# FORWARD_IPV4=true | |# | |echo " enabling forwarding.." | |echo "1" > /proc/sys/net/ipv4/ip_forward | | | | | |#CRITICAL: Enable automatic IP defragmenting since it is disabled by default | |# in 2.2.x kernels. This used to be a compile-time option but the | |# behavior was changed in 2.2.12 | |# | |echo " enabling AlwaysDefrag.." | |echo "1" > /proc/sys/net/ipv4/ip_always_defrag | | | | | |# Dynamic IP users: | |# | |# If you get your IP address dynamically from SLIP, PPP, or DHCP, enable this | |# following option. This enables dynamic-ip address hacking in IP MASQ, | |# making the life with Diald and similar programs much easier. | |# | |#echo " enabling DynamicAddr.." | |#echo "1" > /proc/sys/net/ipv4/ip_dynaddr | | | | | |# Enable the LooseUDP patch which some Internet-based games require | |# | |# If you are trying to get an Internet game to work through your IP MASQ box, | |# and you have set it up to the best of your ability without it working, try | |# enabling this option (delete the "#" character). This option is disabled | |# by default due to possible internal machine UDP port scanning | |# vulnerabilities. | |# | |#echo " enabling LooseUDP.." | |#echo "1" > /proc/sys/net/ipv4/ip_masq_udp_dloose | | | | | |#Clearing any previous configuration | |# | |# Unless specified, the defaults for INPUT and OUTPUT is ACCEPT | |# The default for FORWARD is REJECT | |# | |# Isn't ACCEPT insecure? To some degree, YES, but this is our testing | |# phase. Once we know that IPMASQ is working well, I recommend you run | |# the rc.firewall-*-stronger rulesets which set the defaults to DROP but | |# also include the critical additional rulesets to still let you connect to | |# the IPMASQ server, etc. | |# | |echo " clearing any existing rules and setting default policy.." | |$IPCHAINS -P input ACCEPT | |$IPCHAINS -P output ACCEPT | |$IPCHAINS -P forward REJECT | |$IPCHAINS -F input | |$IPCHAINS -F output | |$IPCHAINS -F forward | | | | | |# MASQ timeouts | |# | |# 2 hrs timeout for TCP session timeouts | |# 10 sec timeout for traffic after the TCP/IP "FIN" packet is received | |# 160 sec timeout for UDP traffic (Important for MASQ'ed ICQ users) | |# | |echo " setting default timers.." | |$IPCHAINS -M -S 7200 10 160 | | | | | |# DHCP: For people who receive their external IP address from either DHCP or | |# BOOTP for connctions such as DSL or Cablemodem users, it is necessary | |# to use the following before the deny command. | |# | |# This example is currently commented out. | |# | |# | |#$IPCHAINS -A input -j ACCEPT -i $EXTIF -s 0/0 67 -d 0/0 68 -p udp | | | |# Enable simple IP forwarding and Masquerading | |# | |# NOTE: The following is an example for an internal LAN address in the | |# 192.168.0.x network with a 255.255.255.0 or a "24" bit subnet mask | |# connecting to the Internet on interface eth0. | |# | |# ** Please change this network number, subnet mask, and your Internet | |# ** connection interface name to match your internal LAN setup | |# | |echo " enabling IPMASQ functionality on $EXTIF" | |$IPCHAINS -P forward DENY | |$IPCHAINS -A forward -i $EXTIF -s $INTLAN -j MASQ | | | |echo -e "\nrc.firewall-ipchains v$FWVER done.\n" | +---------------------------------------------------------------------------------+ Once you are finished with editing the /etc/rc.d/rc.firewall-ipchains ruleset, make it executable by typing in chmod 700 /etc/rc.d/ rc.firewall-ipchains Now that the firewall ruleset is ready, you need to let it run after every reboot. You could either do this by running it by hand everytime (such a pain) or add it to the boot scripts. We have covered two methods below: Redhat (SyS-V style) and Slackware (BSD style) 1. Redhat and Redhat-derived distros:   * There are two ways to automatically load things in Redhat: /etc/rc.d/ rc.local or a init script in /etc/rc.d/init.d/. The first method is the easiest but isn't doing things the Sys-V way. All you have to do is add the line: +---------------------------------------------------------------+ |echo "Loading the rc.firewall ruleset.." | |/etc/rc.d/rc.firewall-ipchains | +---------------------------------------------------------------+ to the end of the /etc/rc.d/rc.local file and thats it (as described earlier in the HOWTO). The problem with this approach is that the firewall isn't executed until the last stages of booting. The preferred approach is to have the firewall loaded just after the networking subsystem is loaded. To do this, copy the following file into the /etc/rc.d/init.d directory: +-------------------------------------------------------------------------------+ |#!/bin/sh | |# | |# chkconfig: 2345 11 89 | |# | |# description: Loads the rc.firewall-ipchains ruleset. | |# | |# processname: firewall-ipchains | |# pidfile: /var/run/firewall.pid | |# config: /etc/rc.d/rc.firewall-ipchains | |# probe: true | | | |# ---------------------------------------------------------------------------- | |# v08/29/02 | |# | |# Part of the copyrighted and trademarked TrinityOS document. | |# http://www.ecst.csuchico.edu/~dranch | |# | |# Written and Maintained by David A. Ranch | |# dranch@trinnet.net | |# | |# Updates | |# ------- | |# | |# ---------------------------------------------------------------------------- | | | | | |# Source function library. | |. /etc/rc.d/init.d/functions | | | |# Check that networking is up. | | | |# This line no longer work with bash2 | |#[ ${NETWORKING} = "no" ] && exit 0 | |# This should be OK. | |[ "XXXX${NETWORKING}" = "XXXXno" ] && exit 0 | | | |[ -x /sbin/ifconfig ] || exit 0 | | | |# The location of various iptables and other shell programs | |# | |# If your Linux distribution came with a copy of iptables, most | |# likely it is located in /sbin. If you manually compiled | |# iptables, the default location is in /usr/local/sbin | |# | |# ** Please use the "whereis iptables" command to figure out | |# ** where your copy is and change the path below to reflect | |# ** your setup | |# | |IPCHAINS=/sbin/ipchains | | | | | |# See how we were called. | |case "$1" in | | start) | | /etc/rc.d/rc.firewall-ipchains | | ;; | | | | stop) | | echo -e "\nFlushing firewall and setting default policies to REJECT\n" | | | | $IPCHAINS -P input REJECT | | $IPCHAINS -P output REJECT | | $IPCHAINS -P forward REJECT | | | | $IPCHAINS -F input | | $IPCHAINS -F output | | $IPCHAINS -F forward | | ;; | | | | restart) | | $0 stop | | $0 start | | ;; | | | | status) | | $IPCHAINS -L | | ;; | | | | mlist) | | $IPCHAINS -M -L | | ;; | | | | *) | | echo "Usage: firewall-ipchains {start|stop|status|mlist}" | | exit 1 | |esac | | | |exit 0 | +-------------------------------------------------------------------------------+ With this script in place, all you need to do now is make it executable and then make it load upon reboot. First, make it executable by running: +---------------------------------------------------------------+ |#Redhat-style | |# | |chmod 700 /etc/rc.d/init.d/firewall-ipchains | +---------------------------------------------------------------+ Now, make the ruleset load upon reboot: +---------------------------------------------------------------+ |#Redhat style | |# | |chkconfig --level=345 firewall-ipchains on | +---------------------------------------------------------------+ That's it! Now upon boot, the firewall will be loaded automatically. Just to make sure, run the command to see that the firewall should start upon reboot by running the command: +---------------------------------------------------------------+ |#Redhat style | |# | |chkconfig --list firewall-ipchains | | | |#The output should look like: | |# | |firewall-ipchains 0:off 1:off 2:off 3:on 4:on 5:on 6:off | +---------------------------------------------------------------+ 2. Slackware:   * There are two ways to load things in Slackware: /etc/rc.d/rc.local or editing the /etc/rc.d/rc.inet2 file. The first method is the easiest but isn't the most secure (see below). All you have to do is append the following lines to the /etc/rc.d/rc.local file: +---------------------------------------------------------------+ |echo "Loading the rc.firewall-ipchains ruleset.." | |/etc/rc.d/rc.firewall-ipchains | +---------------------------------------------------------------+ The problem with this approach is that if you are running a STRONG firewall ruleset, the firewall isn't executed until the last stages of booting. The preferred approach is to have the firewall loaded just after the networking subsystem is loaded. For now, the HOWTO only covers how to do so using /etc/rc.d/rc.local but if you know what you're doing (it's easy), go ahead and and modify the inet2 startup script to load the /etc/ rc.d/rc.firewall-ipchains file just after the network is up. If you want a more detailed guide and/or a stronger firewall ruleset, I recommend you check out Section 10 of TrinityOS found in the links section at the bottom of this HOWTO. Notes on how users might want to change the above firewall ruleset: You could also have IP Masquerading enabled on a PER MACHINE basis instead of the above method, which is enabling an ENTIRE TCP/IP network. For example, say if I wanted only the 192.168.0.2 and 192.168.0.8 hosts to have access to the Internet and NOT any of the other internal machines. I would change the in the "Enable simple IP forwarding and Masquerading" section (shown above) of the /etc/rc.d/rc.firewall-ipchains ruleset. +-------------------------------------------------------------------------------+ |#!/bin/sh | |# | |# Enable simple IP forwarding and Masquerading | |# v1.01 | |# | |# NOTE: The following is an example used in addition to the simple | |# IPCHAINS ruleset anove to allow only IP Masquerading for the | |# 192.168.0.2 and 192.168.0.8 machines with a 255.255.255.0 or a | |# "24" bit subnet mask connecting to the Internet on interface $EXTIF. | |# | |# ** Please change the network number, subnet mask, and the Internet | |# ** connection interface name to match your internal LAN setup | |# | |$IPCHAINS -P forward DENY | |$IPCHAINS -A forward -i $EXTIF -s 192.168.0.2/32 -j MASQ | |$IPCHAINS -A forward -i $EXTIF -s 192.168.0.8/32 -j MASQ | +-------------------------------------------------------------------------------+ Common mistakes: What appears to be a common mistake with new IP MASQ users is to make the first command: +---------------------------------------------------------------------------+ |$IPCHAINS -P forward masquerade | +---------------------------------------------------------------------------+ Do NOT make your default policy MASQUERADING. Otherwise, someone can manipulate their routing tables to tunnel straight back through your gateway, using it to masquerade their OWN identity! Again, you can add these lines to the /etc/rc.d/rc.firewall-ipchains file, one of the other rc files you prefer, or do it manually every time you need IP Masquerade. Please see Section 6.4.2 for a detailed guide on IPCHAINS and a strong IPCHAINS ruleset example. For additional details on IPCHAINS usage, please refer to [http://www.netfilter.org/ipchains/] http://www.netfilter.org/ ipchains/ for the primary IPCHAINS site or the [http://www.tldp.org/HOWTO/ IPCHAINS-HOWTO.html] Linux IP CHAINS HOWTO Backup site ----------------------------------------------------------------------------- 3.4.3. Configuring IP Masquerade on Linux 2.0.x Kernels Create the file /etc/rc.d/rc.firewall-ipfwadm with the following initial SIMPLE ruleset: +---------------------------------------------------------------------------------+ |#!/bin/sh | |# | |# rc.firewall-ipfwadm | |# | |# A Initial SIMPLE IP Masquerade setup for 2.0.x kernels using IPFWADM | |# | |FWVER="2.03" | |# | |# 2.03 - Added comments on why the default policy is ACCEPT | |# 2.02 - Added clarification that PPPoE users need to use | |# "ppp0" instead of "eth0" for their external interface | |# | |# | |# Once IP Masquerading has been tested, with this simple | |# ruleset, it is highly recommended to use a stronger | |# IPTABLES ruleset either given later in this HOWTO or | |# from another reputable resource. | |# | |echo -e "\n\nLoading simple rc.firewall-ipfwadm version $FWVER..\n" | | | | | |#Setting the EXTERNAL and INTERNAL interfaces for the network | |# | |# Each IP Masquerade network needs to have at least one | |# external and one internal network. The external network | |# is where the NATing will occur and the internal network | |# should preferably be addressed with a RFC1918 private addressing | |# scheme. | |# | |# For this example, "eth0" is external and "eth1" is internal" | |# | |# NOTE: If this doesnt EXACTLY fit your configuration, you must | |# change the EXTIF or INTIF variables above. For example: | |# | |# If you are a PPPoE or analog modem user: | |# | |# EXTIF="ppp0" | |# | |# ** Please change this to reflect your specific configuration ** | |# | |EXTIF="eth0" | |INTIF="eth1" | |echo " External Interface: $EXTIF" | |echo " Internal Interface: $INTIF" | | | | | |# Network Address of the Internal Network | |# | |# This example rc.firewall-ipfwadm file uses the 192.168.0.0 network | |# with a /24 or 255.255.255.0 netmask. | |# | |# ** Change this variable to reflect your specific setup ** | |# | |INTLAN="192.168.0.0/24" | |echo -e " Internal Interface: $INTLAN\n" | | | | | |# Load all required IP MASQ modules | |# | |# NOTE: Only load the IP MASQ modules you need. All current available IP | |# MASQ modules are shown below but are commented out from loading. | |echo -en "Loading modules: " | | | | | |# Needed to initially load modules | |# | |/sbin/depmod -a | | | |# Supports the proper masquerading of FTP file transfers using the PORT method | |# | |echo -en "FTP, " | |/sbin/modprobe ip_masq_ftp | | | |# Supports the masquerading of RealAudio over UDP. Without this module, | |# RealAudio WILL function but in TCP mode. This can cause a reduction | |# in sound quality | |# | |#echo -en "RealAudio, " | |#/sbin/modprobe ip_masq_raudio | | | |# Supports the masquerading of IRC DCC file transfers | |# | |#echo -en "Irc, " | |#/sbin/modprobe ip_masq_irc | | | |# Supports the masquerading of Quake and QuakeWorld by default. These modules | |# are for multiple users behind the Linux MASQ server. If you are going to | |# play Quake I, II, and III, use the second example. | |# | |# NOTE: If you get ERRORs loading the QUAKE module, you are running an old | |# ----- kernel that has bugs in it. Please upgrade to the newest kernel. | |# | |#echo -en "Quake, " | |#Quake I / QuakeWorld (ports 26000 and 27000) | |#/sbin/modprobe ip_masq_quake | |# | |#Quake I/II/III / QuakeWorld (ports 26000, 27000, 27910, 27960) | |#/sbin/modprobe ip_masq_quake 26000,27000,27910,27960 | | | |# Supports the masquerading of the CuSeeme video conferencing software | |# | |#echo -en "CuSeeme, " | |#/sbin/modprobe ip_masq_cuseeme | | | |#Supports the masquerading of the VDO-live video conferencing software | |# | |#echo -en "VdoLive, " | |#/sbin/modprobe ip_masq_vdolive | | | |echo ". Done loading modules." | | | | | |#CRITICAL: Enable IP forwarding since it is disabled by default | |# | |# Redhat Users: you may try changing the options in | |# /etc/sysconfig/network from: | |# | |# FORWARD_IPV4=false | |# to | |# FORWARD_IPV4=true | |# | |echo " enabling forwarding.." | |echo "1" > /proc/sys/net/ipv4/ip_forward | | | | | |#CRITICAL: Enable automatic IP defragmenting since it is disabled by default | |# | |# This used to be a compile-time option but the behavior was changed | |# in 2.2.12. This option is required for both 2.0 and 2.2 kernels. | |# | |echo " enabling AlwaysDefrag.." | |echo "1" > /proc/sys/net/ipv4/ip_always_defrag | | | | | |# Dynamic IP users: | |# | |# If you get your Internet IP address dynamically from SLIP, PPP, or DHCP, | |# enable the following option. This enables dynamic-ip address hacking in | |# IP MASQ, making the life with DialD, PPPd, and similar programs much easier. | |# | |#echo " enabling DynamicAddr.." | |#echo "1" > /proc/sys/net/ipv4/ip_dynaddr | | | | | |#Clearing any previous configuration | |# | |# Unless specified, the defaults for INPUT and OUTPUT is ACCEPT | |# The default for FORWARD is REJECT | |# | |# Isn't ACCEPT insecure? To some degree, YES, but this is our testing | |# phase. Once we know that IPMASQ is working well, I recommend you run | |# the rc.firewall-*-stronger rulesets which set the defaults to DROP but | |# also include the critical additional rulesets to still let you connect to | |# the IPMASQ server, etc. | |# | |echo " clearing any existing rules and setting default policy.." | |/sbin/ipfwadm -I -p accept | |/sbin/ipfwadm -O -p accept | |/sbin/ipfwadm -F -p reject | |/sbin/ipfwadm -I -f | |/sbin/ipfwadm -O -f | |/sbin/ipfwadm -F -f | | | | | |# MASQ timeouts | |# | |# 2 hrs timeout for TCP session timeouts | |# 10 sec timeout for traffic after the TCP/IP "FIN" packet is received | |# 160 sec timeout for UDP traffic (Important for MASQ'ed ICQ users) | |# | |echo " setting default timers.." | |/sbin/ipfwadm -M -s 7200 10 160 | | | | | |# DHCP: For people who receive their external IP address from either DHCP or | |# BOOTP such as DSL or Cablemodem users, it is necessary to use the | |# following before the deny command. | |# | |# This example is currently commented out. | |# | |# | |#/sbin/ipfwadm -I -a accept -S 0/0 67 -D 0/0 68 -W $EXTIF -P udp | | | | | |# Enable simple IP forwarding and Masquerading | |# | |# NOTE: The following is an example for an internal LAN address in the | |# 192.168.0.x network with a 255.255.255.0 or a "24" bit subnet mask | |# connecting to the Internet on interface eth0. | |# | |# ** Please change this network number, subnet mask, and your Internet | |# ** connection interface name to match your internal LAN setup. | |# | |echo " enabling IPMASQ functionality on $EXTIF" | |/sbin/ipfwadm -F -p deny | |/sbin/ipfwadm -F -a m -W $EXTIF -S $INTLAN -D 0.0.0.0/0 | | | |echo -e "\nrc.firewall-ipfwadm v$FWVER done.\n" | +---------------------------------------------------------------------------------+ Once you are finished with editing the /etc/rc.d/rc.firewall-ipfwadm ruleset, make it executable by typing in "chmod 700 /etc/rc.d/rc.firewall-ipfwadm" Now that the firewall ruleset is ready to go, you need to let it run after every reboot. You could either do this by running it by hand everytime (such a pain) or add it to the boot scripts. We have covered two methods below: Redhat (SyS-V style) and Slackware (BSD style) Redhat and Redhat-derived distros:   * There are two ways to automatically load things in Redhat: /etc/rc.d/ rc.local or a init script in /etc/rc.d/init.d/. The first method is the easiest but isn't doing it the Sys-V way. All you have to do is add the line: +---------------------------------------------------------------+ |echo "Loading the rc.firewall-ipfwadm ruleset.." | | | |/etc/rc.d/rc.firewall-ipfwadm | +---------------------------------------------------------------+ The problem with this approach is that the firewall isn't executed until the last stages of booting. The preferred approach is to have the firewall loaded just after the networking subsystem is loaded. To do this, copy the following file into the /etc/rc.d/init.d directory: +-------------------------------------------------------------------------------+ |#!/bin/sh | |# | |# chkconfig: 2345 11 89 | |# | |# description: Loads the rc.firewall-ipfwadm ruleset. | |# | |# processname: firewall-ipfwadm | |# pidfile: /var/run/firewall.pid | |# config: /etc/rc.d/rc.firewall-ipfwadm | |# probe: true | | | |# ---------------------------------------------------------------------------- | |# v02/09/02 | |# | |# Part of the copyrighted and trademarked TrinityOS document. | |# http://www.ecst.csuchico.edu/~dranch | |# | |# Written and Maintained by David A. Ranch | |# dranch@trinnet.net | |# | |# Updates | |# ------- | |# | |# ---------------------------------------------------------------------------- | | | | | |# Source function library. | |. /etc/rc.d/init.d/functions | | | |# Check that networking is up. | | | |# This line no longer work with bash2 | |#[ ${NETWORKING} = "no" ] && exit 0 | |# This should be OK. | |[ "XXXX${NETWORKING}" = "XXXXno" ] && exit 0 | | | |[ -x /sbin/ifconfig ] || exit 0 | | | |# The location of various iptables and other shell programs | |# | |# If your Linux distribution came with a copy of iptables, most | |# likely it is located in /sbin. If you manually compiled | |# iptables, the default location is in /usr/local/sbin | |# | |# ** Please use the "whereis iptables" command to figure out | |# ** where your copy is and change the path below to reflect | |# ** your setup | |# | |IPFWADM=/sbin/ipfwadm | | | | | |# See how we were called. | |case "$1" in | | start) | | /etc/rc.d/rc.firewall-ipfwadm | | ;; | | | | stop) | | echo -e "\nFlushing firewall and setting default policies to REJECT\n" | | | | $IPFWADM -I -p REJECT | | $IPFWADM -O -p REJECT | | $IPFWADM -F -p REJECT | | | | $IPFWADM -I -f | | $IPFWADM -O -f | | $IPFWADM -F -f | | ;; | | | | restart) | | $0 stop | | $0 start | | ;; | | | | status) | | $IPFWADM -l | | ;; | | | | mlist) | | $IPFWADM -M -l | | ;; | | | | *) | | echo "Usage: firewall-ipfwadm {start|stop|status|mlist}" | | exit 1 | |esac | | | |exit 0 | +-------------------------------------------------------------------------------+ With this script in place, all you need to do now is make it executable and then make it load upon reboot. First, make it executable by running: +---------------------------------------------------------------+ |#Redhat-style | |# | |chmod 700 /etc/rc.d/init.d/firewall-ipfwadm | +---------------------------------------------------------------+ Now, make the ruleset load upon reboot: +---------------------------------------------------------------+ |#Redhat style | |# | |chkconfig --level=345 firewall-ipfwadm on | +---------------------------------------------------------------+ That's it! Now upon boot, the firewall will be loaded automatically. Just to make sure, run the command to see that the firewall should start upon reboot by running the command: +---------------------------------------------------------------+ |#Redhat style | |# | |chkconfig --list firewall-ipfwadm | | | |#The output should look like: | |# | |firewall-ipfwadm 0:off 1:off 2:off 3:on 4:on 5:on 6:off | +---------------------------------------------------------------+ Slackware:   * There are two ways to automatically load things in Slackware: /etc/rc.d/ rc.local or editing the /etc/rc.d/rc.inet2 file. The first method is the easiest but isn't the most secure (see below). All you have to do is append the following lines to the /etc/rc.d/rc.local file: +---------------------------------------------------------------+ |echo "Loading the rc.firewall-ipfwadm ruleset.." | | | |/etc/rc.d/rc.firewall-ipfwadm | +---------------------------------------------------------------+ The problem with this approach is that if you are running a STRONG firewall ruleset, the firewall isn't executed until the last stages of booting. The preferred approach is to have the firewall loaded just after the networking subsystem is loaded. For now, the HOWTO only covers how to do so using /etc/rc.d/rc.local but if you know what you're doing (it's easy), go ahead and and modify the inet2 startup script to load the /etc/ rc.d/rc.firewall-ipfwadm file just after the network is up. If you want a more detailed guide and/or a stronger firewall ruleset, I recommend you check out Section 10 of TrinityOS found in the links section at the bottom of this HOWTO. Notes on how users might want to change the above firewall ruleset: You could have also enabled IP Masquerading on a PER MACHINE basis instead of the above method enabling an ENTIRE TCP/IP network. For example, say if I wanted only the 192.168.0.2 and 192.168.0.8 hosts to have access to the Internet and NOT any of the other internal machines. I would change the in the "Enable simple IP forwarding and Masquerading" section (shown above) of the /etc/rc.d/rc.firewall-ipfwadm ruleset. +---------------------------------------------------------------------------------+ |# Enable simple IP forwarding and Masquerading | |# v2.01 | |# | |# NOTE: The following is an example to only allow IP Masquerading for the | |# 192.168.0.2 and 192.168.0.8 machines with a 255.255.255.0 or a "24" | |# bit subnet mask connected to the Internet on interface eth0. | |# | |# ** Please change this network number, subnet mask, and your Internet | |# ** connection interface name to match your internal LAN setup | |# | |# Please use the following in ADDITION to the simple rulesets above for | |# specific MASQ networks. | |# | |/sbin/ipfwadm -F -p deny | |/sbin/ipfwadm -F -a m -W $EXTIF -S 192.168.0.2/32 -D 0.0.0.0/0 | |/sbin/ipfwadm -F -a m -W $EXTIF -S 192.168.0.8/32 -D 0.0.0.0/0 | +---------------------------------------------------------------------------------+ Common mistakes: What appears to be a common mistake with new IP Masq users is to make the first command: +---------------------------------------------------------------------------+ |ipfwadm -F -p masquerade | +---------------------------------------------------------------------------+ Do NOT make your default policy MASQUERADING. Otherwise, someone who has the ability to manipulate their routing tables will be able to tunnel straight back through your gateway, using it to masquerade their OWN identity! Again, you can add these lines to the /etc/rc.d/rc.firewall-ipfwadm file, one of the other rc files (if you prefer), or manually add those lines every time you need IP Masquerade. Please see Section 6.4.3 and Section 6.4.3for a detailed guide and stronger examples of IPCHAINS and IPFWADM ruleset examples. ----------------------------------------------------------------------------- Chapter 4. Configuring the other internal to-be MASQed machines Besides setting the appropriate IP address for each internal MASQed machine (either statically or though DHCP), you should also set each internal machine with the appropriate gateway IP address of the Linux MASQ server and required DNS servers. In general, this is rather straight forward. You simply enter the address of your Linux host (192.168.0.1 is used throughout this HOWTO) as the machine's gateway address. For the Domain Name Service (DNS), you add in any DNS servers that are available to you to use. The most apparent one(s) should be the DNS servers that your Linux server uses. You can optionally add any "domain search" suffix as well for quicker connections, etc. After you have properly reconfigured the internal MASQed machines, remember to restart their appropriate network services or reboot them if need be. The following configuration instructions assume that you are using a Class C network with 192.168.0.1 as your Linux MASQ server's address. Please note that 192.168.0.0 and 192.168.0.255 are reserved TCP/IP address per RFC1918 for uses just like enabling IP Masquerade services. As it stands, the following Platforms have been tested as internal MASQed machines. This is only an EXAMPLE of all compatible OSes out there:   * Apple Macintosh OS and OS-X (with MacTCP or Open Transport or the BSD TCP /IP stack)   * AT&T Unix (Caldera)   * *BSD systems including Free/Net/Open/BSDi/386/etc.   * Commodore Amiga (with AmiTCP or AS225-stack)   * Digital VAX Stations 3520 and 3100 with UCX (TCP/IP stack for VMS)   * Digital Ultrix, Digital Unix (Compaq Tru/64)   * HP HP/UX   * IBM AIX running on RS/6000, PowerPC, etc.   * IBM OS/2 (including Warp v3)   * IBM OS400 running on a AS/400   * Linux distributions from vendors like Caldera, Corel, Debian, Mandrake, Redhat, Slackware, SuSe, etc. running various kernels like 1.2.x, 1.3.x, 2.0.x, 2.1.x, 2.2.x, 2.3.x, 2.4.x, etc.   * Microsoft DOS (with NCSA Telnet package, DOS Trumpet works partially)   * Microsoft Windows 3.1 (with the Netmanage or FTP packages)   * Microsoft Windows For Workgroup 3.11 (with a TCP/IP package)   * Microsoft Windows 95, OSR2, 98, 98se, Me   * Microsoft Windows NT 3.51, 4.0, 2000, XP - (both workstation (professional) and server versions)   * Novell Netware 4.01, 5.x, etc. with the TCP/IP service   * SCO Openserver (v3.2.4.2 and 5) and UnixWare (AT&T Unix)   * Sun Solaris 2.51, 2.6, 7, 8   * heheh.. what else am I missing? ----------------------------------------------------------------------------- 4.1. Configuring Microsoft Windows 95 and OSR2 1. ** Please note that some prompts might be different based upon the build version of Windows95 you are running ** If you haven't installed your network card and adapter driver, do so now. Descriptions to perform this step is beyond the scope of this document and though it is fairly simple, if you haven't done this before, please seek assitance. 2. Go to the 'Control Panel' --> 'Network'. 3. Click on Add --> Protocol --> Manufacture: Microsoft --> Protocol: 'TCP/ IP protocol' if you don't already have it installed. 4. Highlight the TCP/IP item bound to your correct Windows95 network card e.g. (TCP/IP --> Intel EtherExpress Pro/100+) and select 'Properties'. Here, you have two options: configure a static address or use DHCP. Static addresses are simple but require that you NEVER configure duplication IPs on different machines. The alternative is DHCP which automatically configures all DHCP-enabled workstations things like IP addresses, DNS servers, etc. from a central server (typically the Linux MASQ server). DHCP enabled: To use DHCP, simply click on the "Use DHCP to assign addresses" button. Please note that configuring a DHCP server is beyond the scope of this HOWTO but it is fully covered in TrinityOS and other Linux HOWTOs. Static Addresses: Now goto the 'IP Address' tab and set IP Address to 192.168.0.x, (1 < x < 255), and set the Subnet Mask to 255.255.255.0 5. Now select the "Gateway" tab and add 192.168.0.1 as your gateway under 'Gateway' and hit "Add". 6. Under the 'DNS Configuration' tab, make sure to put enter in a name for this machine and specify your official domain name. If you don't have your own domain, enter in the domain of your ISP. Next, you need to specify the DNS servers you plan on using. DHCP: No entries are required as this is configured dynamically via DHCP. STATIC: Add all of the DNS servers that your Linux MASQ server uses (usually found in /etc/resolv.conf). Usually these DNS servers are located at your ISP though you could be running either your own Caching or Authoritative DNS server on your Linux MASQ server as well. Again, setting up DNS services is beyond the scope of this HOWTO but it is covered by TrinityOS as well as the LDP's DNS HOWTO. Optionally, you can add any appropriate domain search suffixes as well. This allows users to simply type in the hostname of the destination computer instead of the fully qualified domain name (FQDN). This is similar to the PATH function for finding common Unix commands. 7. Leave all of the other settings alone as they are unless (even dangerous) if you don't know what you're doing. 8. Click 'OK' in all dialog boxes and restart your system. 9. As an initial test, Ping the Linux MASQ server to test the network connection: 'Start/Run', type: ping 192.168.0.1(This is only an INTERNAL LAN connection test, you might not be able to ping the outside world yet.) If you don't see "replies" to your PINGs, please verify your network configuration. 10. You can optionally create a HOSTS file in the C:\Windows directory so that you can ping the "hostname" of the machines on your LAN without the need for a DNS server. There is an example called HOSTS.SAM in the C:\ windows directory for an example. ----------------------------------------------------------------------------- 4.2. Configuring Windows NT 1. If you haven't installed your network card and adapter driver, do so now. Descriptions to perform this task is beyond the scope of this document. 2. Go to 'Control Panel' --> 'Network' --> Protocols 3. Add the TCP/IP Protocol and related Components from the 'Add Software' menu if you don't have TCP/IP service installed already. 4. Under 'Network Software and Adapter Cards' section, highlight the 'TCP/IP Protocol' in the 'Installed Network Software' selection box. 5. In 'TCP/IP Configuration', select the appropriate adapter, e.g. [1]Intel EtherExpress Pro/100+. Then set the IP Address to 192.168.0.x (1 < x < 255), then set the Subnet Mask to 255.255.255.0 and Default Gateway to 192.168.0.1. 6. Do not enable any of the following options (unless you know what you are doing):   + 'Automatic DHCP Configuration' : Unless you have a DHCP server running on your network.   + Put anything in the 'WINS Server' input areas : Unless you have setup one or more WINS servers.   + Enable IP Forwardings : Unless you are routing on your NT machine and really -REALLY- know EXACTLY what you're doing. 7. Click 'DNS', fill in the appropriate information that your Linux host uses (usually found in /etc/resolv.conf) and then click 'OK' when you're done. 8. Click 'Advanced', be sure to DISABLE 'DNS for Windows Name Resolution' and 'Enable LMHOSTS lookup' unless you known what these options do. If you want to use a LMHOSTS file, it is stored in C:\winnt\system32\drivers \etc. 9. Click 'OK' on all dialog boxes and restart the system. 10. As an initial test, ping the Linux MASQ server to test the network connection: 'File/Run', type: ping 192.168.0.1(This is only an INTERNAL LAN connection test, you you might not be able to ping the outside world yet.) If you don't see any "replies" to your PINGs, please verify your network configuration. ----------------------------------------------------------------------------- 4.3. Configuring Windows for Workgroup 3.11 1. If you haven't installed your network card and adapter driver, do so now. Descriptions to perform this task is beyond the scope of this document. 2. Install the TCP/IP 32b package if you haven't already. 3. In 'Main'/'Windows Setup'/'Network Setup', click on 'Drivers'. 4. Highlight 'Microsoft TCP/IP-32 3.11b' in the 'Network Drivers' section, click 'Setup'. 5. Set the IP Address to 192.168.0.x (1 < x < 255), then set the Subnet Mask to 255.255.255.0 and Default Gateway to 192.168.0.1 6. Do not enable any of the following options (unless you know what you are doing):   + 'Automatic DHCP Configuration' : Unless you have a DHCP server running on your network.   + Put anything in the 'WINS Server' input areas : Unless you have setup one or more WINS servers. 7. Click 'DNS', fill in the appropriate information your Linux host uses (usually found in /etc/resolv.conf). Then click 'OK' when you're done with it. 8. Click 'Advanced', check 'Enable DNS for Windows Name Resolution' and 'Enable LMHOSTS lookup' found in c:\windows. 9. Click 'OK' in all dialog boxes and restart the system. 10. As an initial test, ping the linux box to test the network connection: 'File/Run', type: ping 192.168.0.1 (This is only an INTERNAL LAN connection test so you might not be able to ping the outside world yet.) If you don't see "replies" to your PINGs, please verify your network configuration. ----------------------------------------------------------------------------- 4.4. Configuring UNIX Based Systems 1. If you haven't installed your network card and either re-configured the network subsystem or recompiled your kernel with the appropriate adapter driver, do so now. Descriptions to perform this task is beyond the scope of this document but are covered in the Networking HOWTO. 2. Install TCP/IP networking, such as the net-tools package, if you don't have it already. 3. Set IPADDR to 192.168.0.x (1 < x < 255), then set NETMASK to 255.255.255.0, GATEWAY to 192.168.0.1, and BROADCAST to 192.168.0.255.   + Redhat (Mandrake / TurboLinux / etc): You can edit the /etc/sysconfig /network-scripts/ifcfg-eth0 file, or simply do so through the Control Panel (Linuxconf).   + Slackware: You need to edit the /etc/rc.d/rc.inet1 file to configure the network subsystem.   + To Add: Debian, Suse, Caldera, etc. Please email dranch@trinnet.net if you can tell me what distro uses what files to configure the networking subsystem. Beyond this, most Linux distributions use significantly different network configuration mechanisms let alone other UNIXes such as SunOS, BSDi, Solaris, AIX, TruUnix, FreeBSD, etc.). Please refer to your specific UNIX documentation for more details. 4. Add your domain name service (DNS) and domain search suffix in /etc/ resolv.conf and for the appropreiate UNIX versions, edit the /etc/ nsswitch.conf file to enable DNS services. 5. You may also want to update your /etc/networks file depending on your version of UNIX and the system's settings. 6. Restart the appropriate services, or simply restart your system. 7. As an initial test, run the ping command: ping 192.168.0.1 to test the connection to your gateway machine. (This is only an INTERNAL LAN connection test, so you might not be able to ping the outside world yet.) If you don't see "replies" to your PINGs, please verify your network configuration. ----------------------------------------------------------------------------- 4.5. Configuring DOS using NCSA Telnet package 1. If you haven't installed your network card, do so now. Descriptions to perform this task is beyond the scope of this document. 2. Load the appropriate packet driver. For example: an NE2000 Ethernet card set for I/O port 300 and IRQ 10, would need to be issued nwpd 0x60 10 0x300 3. Make a new directory, and then unpack the NCSA Telnet package: pkunzip tel2308b.zip 4. Use a text editor to open the config.tel file 5. Set myip=192.168.0.x (1 < x < 255), and netmask=255.255.255.0 6. In this example, you should set hardware=packet, interrupt=10, ioaddr=60 7. You should have at least one individual machine specified as the gateway, i.e. the Linux host: +---------------------------------------------------------------+ | name=default | | host=yourlinuxhostname | | hostip=192.168.0.1 | | gateway=1 | +---------------------------------------------------------------+ 8. Have another specified as a domain name service: +---------------------------------------------------------------+ | name=dns.domain.com ; hostip=123.123.123.123; nameserver=1| +---------------------------------------------------------------+ Note: substitute the appropriate information about the DNS according what your Linux host uses 9. Save your config.tel file 10. As an initial test, ping the Linux MASQ server to test the network connection: ping 192.168.0.1 If you don't receive any replies, please verify your network configuration. ----------------------------------------------------------------------------- 4.6. Configuring MacOS Based System Running MacTCP 1. If you haven't installed the appropriate driver software for your Ethernet adapter, do so now. Descriptions to perform this task is beyond the scope of this document. 2. Open the MacTCP control panel. Select the appropriate network driver (Ethernet, NOT EtherTalk) and click on the 'More...' button. 3. Under 'Obtain Address:', click 'Manually'. 4. Under 'IP Address:', select class C from the popup menu. Ignore the rest of the dialog box sections. 5. Fill in the appropriate information under 'Domain Name Server Information:'. 6. Under 'Gateway Address:', enter 192.168.0.1 7. Click 'OK' to save the settings. In the main window of the MacTCP control panel, enter the IP address of your Mac (192.168.0.x, 1 < x < 255) in the 'IP Address:' box. 8. Close the MacTCP control panel. If a dialog box pops up, notifying you to do so, then restart the system. 9. You may optionally ping the Linux box to test the network connection. If you have the freeware program MacTCP Watcher , click on the 'Ping' button, and enter the address of your Linux box (192.168.0.1) in the dialog window that pops up. (This is only an INTERNAL LAN connection test, you can't ping the outside world yet.) If you don't see "replies" to your PINGs, please verify your network configuration. 10. You can optionally create a Hosts file in your System Folder so that you can use the hostnames of the machines on your LAN. The file should already exist in your System Folder, and should contain some (commented-out) sample entries which you can modify according to your needs. ----------------------------------------------------------------------------- 4.7. Configuring MacOS Based System Running Open Transport 1. If you haven't installed the appropriate driver software for your Ethernet adapter, do so now. Descriptions to perform this task is beyond the scope of this document. 2. Open the TCP/IP Control Panel and choose 'User Mode ...' from the Edit menu. Make sure the user mode is set to at least 'Advanced' and click the 'OK' button. 3. Choose 'Configurations...' from the File menu. Select your 'Default' configuration and click the 'Duplicate...' button. Enter 'IP Masq' (or something to let you know that this is a special configuration) in the 'Duplicate Configuration' dialog, it will probably say something like 'Default copy'. Then click the 'OK' button, and the 'Make Active' button 4. Select 'Ethernet' from the 'Connect via:' pop-up. 5. Select the appropriate item from the 'Configure:' pop-up. If you don't know which option to choose, you probably should re-select your 'Default' configuration and quit. I use 'Manually'. 6. Enter the IP address of your Mac (192.168.0.x, 1 < x < 255) in the 'IP Address:' box. 7. Enter 255.255.255.0 in the 'Subnet mask:' box. 8. Enter 192.168.0.1 in the 'Router address:' box. 9. Enter the IP addresses of your domain name servers in the 'Name server addr.:' box. 10. Enter the name of your Internet domain (e.g. 'microsoft.com') in the 'Starting domain name' box under 'Implicit Search Path:'. 11. The following procedures are optional. Incorrect values may cause erratic behavior. If you're not sure, it's probably better to leave them blank, unchecked and/or un-selected. Remove any information from those fields, if necessary. As far as I know, there is no way to use the TCP/IP dialogs to tell the system not to use a previously selected alternate "Hosts" file. If you know, I would be interested. Check the '802.3' if your network requires 802.3 frame types. 12. Click the 'Options...' button to make sure that the TCP/IP is active. I use the 'Load only when needed' option. If you continuously run and quit TCP/IP applications without rebooting your machine, you may find that unchecking the 'Load only when needed' option will prevent/reduce the effects on your machine's memory management. With the item unchecked, the TCP/IP protocol stacks are always loaded and available for use. If checked, the TCP/IP stacks are automatically loaded when needed and un-loaded when not. It's the loading and unloading process that can cause your machine's memory to become fragmented. 13. You may ping the Linux box to test the network connection. If you have the freeware program MacTCP Watcher, click on the 'Ping' button, and enter the address of your Linux box (192.168.0.1) in the dialog box that pops up. (This is only an INTERNAL LAN connection test, you can't ping the outside world yet.) If you don't see "replies" to your PINGs, please verify your network configuration. 14. You can optionally create a Hosts file in your System Folder so that you can use the hostnames of the machines on your LAN. The file may or may not already exist in your System Folder. If so, it should contain some (commented-out) sample entries which you can modify according to your needs. If not, you can get a copy of the file from a system running MacTCP, or just create your own (it follows a subset of the Unix /etc/ hosts file format, described on RFC1035). Once you've created the file, open the TCP/IP control panel, click on the 'Select Hosts File...' button, and open the Hosts file. 15. Click the close box or choose 'Close' or 'Quit' from the File menu, and then click the 'Save' button to save the changes you have made. 16. The changes take effect immediately, but rebooting the system won't hurt. ----------------------------------------------------------------------------- 4.8. Configuring Novell network using DNS 1. If you haven't installed the appropriate driver software for your Ethernet adapter, do so now. Descriptions to perform this task is beyond the scope of this document. 2. Downloaded tcpip16.exe from The Novell LanWorkPlace page 3. +---------------------------------------------------------------+ |edit c:\nwclient\startnet.bat: (here is a copy of mine) | |SET NWLANGUAGE=ENGLISH | |LH LSL.COM | |LH KTC2000.COM | |LH IPXODI.COM | |LH tcpip | |LH VLM.EXE | |F: | +---------------------------------------------------------------+ 4. +---------------------------------------------------------------------------+ |edit c:\nwclient\net.cfg: (change link driver to yours i.e. NE2000) | |Link Driver KTC2000 | | Protocol IPX 0 ETHERNET_802.3 | | Frame ETHERNET_802.3 | | Frame Ethernet_II | | FRAME Ethernet_802.2 | | | |NetWare DOS Requester | | FIRST NETWORK DRIVE = F | | USE DEFAULTS = OFF | | VLM = CONN.VLM | | VLM = IPXNCP.VLM | | VLM = TRAN.VLM | | VLM = SECURITY.VLM | | VLM = NDS.VLM | | VLM = BIND.VLM | | VLM = NWP.VLM | | VLM = FIO.VLM | | VLM = GENERAL.VLM | | VLM = REDIR.VLM | | VLM = PRINT.VLM | | VLM = NETX.VLM | | | |Link Support | | Buffers 8 1500 | | MemPool 4096 | | | |Protocol TCPIP | | PATH SCRIPT C:\NET\SCRIPT | | PATH PROFILE C:\NET\PROFILE | | PATH LWP_CFG C:\NET\HSTACC | | PATH TCP_CFG C:\NET\TCP | | ip_address 192.168.0.xxx | | ip_router 192.168.0.1 | | | | | |Change the IP address in the above "ip_address" field (192.168.0.x, 1 < x | |< 255) and finally create c:\bin\resolv.cfg: | | | |SEARCH DNS HOSTS SEQUENTIAL | |NAMESERVER xxx.xxx.xxx.xxx | |NAMESERVER yyy.yyy.yyy.yyy | +---------------------------------------------------------------------------+ 5. Now edit the above "NAMESERVER" entries and replace them with the correct IP addresses for your local DNS server. 6. Issue a ping command: ping 192.168.0.1 to test the connection to your gateway machine. (This is only an INTERNAL LAN connection test, you can't ping the outside world yet.) If you don't see "replies" to your PINGs, please verify your network configuration. ----------------------------------------------------------------------------- 4.9. Configuring OS/2 Warp 1. If you haven't installed the appropriate driver software for your Ethernet adapter, do so now. Descriptions to perform this task is beyond the scope of this document. 2. Install the TCP/IP protocol if you don't have it already. 3. Go to Programs/TCP/IP (LAN) / TCP/IP Settings 4. In 'Network', add your TCP/IP Address (192.168.0.x) and set your netmask (255.255.255.0) 5. Under 'Routing', press 'Add'. Set the Type to 'default' and type the IP Address of your Linux Box in the Field 'Router Address'. (192.168.0.1). 6. Set the same DNS (Nameserver) Address that your Linux host uses in 'Hosts'. 7. Close the TCP/IP control panel. Say yes to the following question(s). 8. Reboot your system 9. You may ping the Linux box to test the network configuration. Type 'ping 192.168.0.1' in a 'OS/2 Command prompt Window'. When ping packets are received all is ok. ----------------------------------------------------------------------------- 4.10. Configuring OS/400 on a IBM AS/400 The descriptions to configure TCP/IP on OS/400 version V4R1M0 running on a AS /400 is beyond the scope of this document. 1) To perform any communications configuration tasks on your AS/400, you must have the special authority of *IOSYSCFG (I/O System Configuration) defined in your user profile. You can check the characteristics of your user profile with the DSPUSRPRF command. 2) Type GO CFGTCP command th reach the Configure TCP/IP menu. 3) Select Option 2 - Work with TCP/IP Routes. 4) Enter a 1 on the Opt field to add a route. * In Route Destination type * DFTROUTE * In Subnet Mask type *NONE * In Type of Service type *NORMAL * In Nex Hop type the address of your gataway (the Linux box) ----------------------------------------------------------------------------- 4.11. Configuring Other Systems The same logic should apply to setting up other platforms. Consult the sections above. If you're interested in writing about any of systems that have not been covered yet, please send a detail setup instruction to [mailto: ambrose@writeme.com] ambrose@writeme.com and [mailto:dranch@trinnet.net] dranch@trinnet.net. ----------------------------------------------------------------------------- Chapter 5. Testing IP Masquerade Finally, it's time to give IP Masquerading an official try after all this hard work. If you haven't already rebooted your Linux box, do so to make sure the machines boots ok, executes the /etc/rc.d/rc.firewall-* ruleset, etc. Next, make sure that both the internal LAN connection and connection of your Linux hosts to the Internet is okay. Follow these -11- tests to make sure all aspects of your MASQ setup is running properly: ----------------------------------------------------------------------------- 5.1. Loading up the rc.firewall ruleset Step One: run the correct firewall for your machine via command "/etc/rc.d/ rc.firewall-[iptables / ipchains /ipfwadm]". For example, Linux 2.6 users would run "/etc/rc.d/rc.firewall-iptables" Does it load with some strange errors? Here are some exmaples and help to fix them:   * Problem #1: +--------------------------------------------------------------------------------+ |ip_tables, Using /lib/modules/2.4.2-2/kernel/net/ipv4/netfilter/ip_tables.o | |/lib/modules/2.4.2-2/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device | |or resource busy | |Hint: insmod errors can be caused by incorrect module parameters, including | |invalid IO or IRQ parameters | | | +--------------------------------------------------------------------------------+ Run the command "/sbin/lsmod" and make sure the module "ipchains.o" is NOT installed. If it is installed, your machine (most likely Redhat-7.x based) is probably trying to load an IPCHAINS ruleset which is incompatible with IPTABLES. To disable this from happening in the future, run the command: +---------------------------------------------------------------+ | chkconfig --level=2345 ipchains off | | | +---------------------------------------------------------------+ To remove the "ipchains" module without rebooting, run the command: +---------------------------------------------------------------+ | /sbin/rmmod ipchains | | | +---------------------------------------------------------------+ and the re-try to load the rc.firewall-* ruleset.   * Problem #2: +---------------------------------------------------------------+ | . | | . | | Creating a DROP chain.. | | iptables v1.2.3: log-level `info' ambiguous | | . | | . | | | +---------------------------------------------------------------+ Your version of IPTABLES it too old. You need to upgrade it with a newer version via an updated RPM, DEB, or via compiling up the source. You can get an updated version from your Linux distribution manufacturer or from the NetFilter WWW site. This is all covered in the Section 2.6 section.   * Problem #3: +---------------------------------------------------------------+ | No such file: | | | +---------------------------------------------------------------+ Did you copy this rc.firewall-* file from a DOS machine? Load the rc.firewall-* file in a binary editor such as ViM (vim -b /etc/rc.d/ rc.firewall-*) and make sure that every line is NOT finished with a ^M. ----------------------------------------------------------------------------- 5.2. Testing internal MASQ client PC connectivity   * Step Two: Testing internal MASQ client PC connectivity From an internal MASQed computer, try pinging its local IP address (i.e. ping 192.168.0.10 ). This will verify that TCP/IP is correctly working on the local machine. Almost ALL modern operating systems have built-in support for the "ping" command. If this ping doesn't work, make sure that TCP/IP is correctly configured on the MASQed PC as described earlier in Chapter 4 of this HOWTO. The output should look something like the following (hit Control-C to abort the ping): ------------------------------------ masq-client# ping 192.168.0.10 PING 192.168.0.10 (192.168.0.10): 56 data bytes 64 bytes from 192.168.0.10: icmp_seq=0 ttl=255 time=0.8 ms 64 bytes from 192.168.0.10: icmp_seq=1 ttl=255 time=0.4 ms 64 bytes from 192.168.0.10: icmp_seq=2 ttl=255 time=0.4 ms 64 bytes from 192.168.0.10: icmp_seq=3 ttl=255 time=0.5 ms ^C --- 192.168.0.10 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.4/0.5/0.8 ms ------------------------------------ ----------------------------------------------------------------------------- 5.3. Testing internal MASQ client to MASQ server connectivity   * Step Three: Testing internal MASQ client to MASQ server connectivity Next, from the same internal MASQed computer, try pinging the the IP address of the Linux MASQ server's INTERNAL interface (i.e. ping 192.168.0.1 ). This will verify that TCP/IP is correctly working on both the local and Linux MASQ machine. Almost ALL modern operating systems have built-in support for the "ping" command. If this ping doesn't work, make sure that TCP/IP is correctly configured on the MASQed Server as described by the various Network HOWTOs (URLs can be found in the requirements section for your 2.4.x kernel in Section 2.6, 2.2.x kernel in Section 2.7, or 2.0.x kernel in Section 2.8). The output should look something like the following (hit Control-C to abort the ping): ------------------------------------ masq-client# ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1): 56 data bytes 64 bytes from 192.168.0.1: icmp_seq=0 ttl=255 time=0.8 ms 64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=0.4 ms 64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=0.4 ms 64 bytes from 192.168.0.1: icmp_seq=3 ttl=255 time=0.5 ms ^C --- 192.168.0.1 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.4/0.5/0.8 ms ------------------------------------ If the ping failed, check the network connection between the MASQ server and the PC. If it's a DIRECT Ethernet connection (no hub or switch), you MUST have a "Ethernet cross-over cable". These cables are common and can be found at any computer store. Without this cable, the NICs (network cards) will not give you a "LINK" light. If you are using a hub or switch, make sure the ports connected to the MASQ server and MASQed client machine have a LINK light. If they do and the pings STILL don't work or there is a lot of packet loss, try different ports on the hub/ switch (it not all that uncommon to have hub/switch ports die). Finally, if things still don't work perfectly, try replacing each of the NICs in the machines. You would be surprised how many people I've helped have found that their NIC cards were going bad and caused them all kinds of grief. ----------------------------------------------------------------------------- 5.4. Testing internal MASQ server connectivity   * Step Four: Testing internal MASQ server connectivity On the MASQ server, ping the internal IP address of the MASQ server's network interface card (i.e. ping 192.168.0.1). If this ping doesn't work, make sure that TCP/IP is correctly configured on the MASQed Server as described by the various Network HOWTOs (URLs can be found in the requirements section for your 2.4.x kernel in Section 2.6, 2.2.x kernel in Section 2.7, or 2.0.x kernel in Section 2.8). The output should look something like the following (hit Control-C to abort the ping): -------------------------------------- masq-server# ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1): 56 data bytes 64 bytes from 192.168.0.1: icmp_seq=0 ttl=255 time=0.8 ms 64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=0.4 ms 64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=0.4 ms 64 bytes from 192.168.0.1: icmp_seq=3 ttl=255 time=0.5 ms ^C --- 192.168.0.1 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.4/0.5/0.8 ms --------------------------------------- ----------------------------------------------------------------------------- 5.5. Testing internal MASQ server to MASQ client connectivity   * Step Five: Testing internal MASQ server to MASQ client connectivity Next from MASQed server, try pinging the IP address of one of the internal MASQ client computers (i.e. ping 192.168.0.10 ). This will verify that TCP/IP is correctly working on both the local server machine and on the MASQ client machine. If this ping doesn't work, make sure that TCP/IP is correctly configured on the MASQed PC as described earlier in Chapter 4 of this HOWTO. Also be sure that the cabling is correct (Ethernet: the NICs connecting the internal MASQ PC and the MASQ server have the "link" light lit up). If the ping does work, the output should look something like the following (hit Control-C to abort the ping): ------------------------------------ masq-server# ping 192.168.0.10 PING 192.168.0.10 (192.168.0.10): 56 data bytes 64 bytes from 192.168.0.10: icmp_seq=0 ttl=255 time=0.8 ms 64 bytes from 192.168.0.10: icmp_seq=1 ttl=255 time=0.4 ms 64 bytes from 192.168.0.10: icmp_seq=2 ttl=255 time=0.4 ms 64 bytes from 192.168.0.10: icmp_seq=3 ttl=255 time=0.5 ms ^C --- 192.168.0.10 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.4/0.5/0.8 ms ------------------------------------ ----------------------------------------------------------------------------- 5.6. Testing External MASQ server Internet connectivity   * Step Six: Testing external MASQ server to Internet connectivity From the MASQ server, ping the external IP address of the MASQ server's EXTERNAL network interface that is connected to the Internet. This address might be a Ethernet interface, a PPP interface, etc. connection to your ISP. If you don't know what this external IP address is, run the Linux command "/sbin/ifconfig" on the MASQ server itself to get the Internet address. The output should look something like the following (we are looking for the IP address of eth0): ------------------------------------ eth0 Link encap:Ethernet HWaddr 00:08:C7:A4:CC:5B inet addr:12.13.14.15 Bcast:12.13.14.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:6108459 errors:0 dropped:0 overruns:0 frame:0 TX packets:5422798 errors:8 dropped:0 overruns:0 carrier:8 collisions:4675 txqueuelen:100 Interrupt:11 Base address:0xfcf0 ------------------------------------ As you can see from the above, the external IP address is "12.13.14.15" for this example. So, now that you have your IP address after running the "ipconfig" command, ping your external IP address. This will confirm that the MASQ server has full network connectivity. The output should look something like the following (hit Control-C to abort the ping): ------------------------------------- masq-server# ping 12.13.14.15 PING 12.13.14.15 (12.13.14.15): 56 data bytes 64 bytes from 12.13.14.15: icmp_seq=0 ttl=255 time=0.8 ms 64 bytes from 12.13.14.15: icmp_seq=1 ttl=255 time=0.4 ms 64 bytes from 12.13.14.15: icmp_seq=2 ttl=255 time=0.4 ms 64 bytes from 12.13.14.15: icmp_seq=3 ttl=255 time=0.5 ms ^C --- 12.13.14.15 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.4/0.5/0.8 ms ------------------------------------- If either of these tests doesn't work, you need to go back and double check your network cabling and verify that the two network interfaces on the MASQ server are seen in "dmesg". An example of this output would be the following towards the END of the "dmesg" command: ------------------------------------- . . PPP: version 2.3.7 (demand dialling) TCP compression code copyright 1989 Regents of the University of California PPP line discipline registered. 3c59x.c:v0.99H 11/17/98 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/ vortex.html eth0: 3Com 3c905 Boomerang 100baseTx at 0xfe80, 00:60:08:a7:4e:0e, IRQ 9 8K word-wide RAM 3:5 Rx:Tx split, autoselect/MII interface. MII transceiver found at address 24, status 786f. Enabling bus-master transmits and whole-frame receives. eth1: 3Com 3c905 Boomerang 100baseTx at 0xfd80, 00:60:97:92:69:f8, IRQ 9 8K word-wide RAM 3:5 Rx:Tx split, autoselect/MII interface. MII transceiver found at address 24, status 7849. Enabling bus-master transmits and whole-frame receives. Partition check: sda: sda1 sda2 < sda5 sda6 sda7 sda8 > sdb: . . ------------------------------------- Also be sure that the cabling is correct (Ethernet: the NICs connecting the external MASQ server to your ISP has the "link" light lit up). Finally, make sure that TCP/IP is correctly configured on the MASQed Server as described by the various Network HOWTOs (URLs can be found in the requirements section for your 2.4.x kernel in Section 2.6, 2.2.x kernel in Section 2.7, or 2.0.x kernel in Section 2.8). ----------------------------------------------------------------------------- 5.7. Testing internal MASQ client to external MASQ server connectivity   * Step Seven: Testing internal MASQ client to external MASQ server connectivity From an internal MASQed computer, ping the IP address of the MASQ server's EXTERNAL TCP/IP address obtained in Step FIVE above. This address could be from your Ethernet, PPP, etc. interface which is ultimately the address connected to your ISP. This ping test will prove that Linux masquerading (ICMP Masquerading specifically) and IP forwarding is working. If everthing thing is working correctly, the output should look something like the following (hit Control-C to abort the ping): ------------------------------------- masq-client# ping 12.13.14.15 PING 12.13.14.15 (12.13.14.15): 56 data bytes 64 bytes from 12.13.14.15: icmp_seq=0 ttl=255 time=0.8 ms 64 bytes from 12.13.14.15: icmp_seq=1 ttl=255 time=0.4 ms 64 bytes from 12.13.14.15: icmp_seq=2 ttl=255 time=0.4 ms 64 bytes from 12.13.14.15: icmp_seq=3 ttl=255 time=0.5 ms ^C --- 12.13.14.15 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.4/0.5/0.8 ms ------------------------------------- If this test doesn't work, first make sure that the "Default Gateway" on the MASQed PC is pointing to the IP address on the MASQ -SERVERs- INTERNAL NIC. Also double check that the /etc/rc.d/rc.firewall-* script was run without any errors. Just as a test, try re-running the /etc/rc.d/ rc.firewall-* script now to see if it runs OK. Also, though most kernels support it by default, make sure that you enabled "ICMP Masquerading" in the kernel comfiguration and "IP Forwarding" in your /etc/rc.d/ rc.firewall-* script. If you still can't get things to work, take a look at the output from the following commands run on the Linux MASQ SERVER:   + "ifconfig" : Make sure the interface for your Internet connection (be it ppp0, eth0, etc.) is UP and you have the correct IP address for the Internet connection. An example of this output is shown in STEP FIVE above.   + "netstat -rn" : Make sure your default gateway (the column with an IP address in the Gateway column) is set. An example of this output might look like: ------------------------------------- masq-server# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.0.1 0.0.0.0 255.255.255.255 UH 0 16384 0 eth1 12.13.14.15 0.0.0.0 255.255.255.255 UH 0 16384 0 eth0 12.13.14.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 127.0.0.0 0.0.0.0 255.0.0.0 U 0 16384 0 lo 0.0.0.0 12.13.14.1 0.0.0.0 UG 0 16384 0 eth0 ------------------------------------- Notice the very LAST line that starts with 0.0.0.0? Notice that it also has an IP address in the "Gateway" field? You should specify an IP address for your specific setup in that field (this is typically done automatically when your Internet connection is enabled).   + "cat /proc/sys/net/ipv4/ip_forward" : Make sure it says "1" so that Linux forwarding is enabled   + Run the command "/sbin/ipchains -n -L" for 2.2.x users or "/sbin/ ipfwadm -F -l" for 2.0.x users. Specifically, look for the FORWARDing section to make sure you have MASQ enabled. An example of an IPCHAINS output might look like for users using the SIMPLE rc.firewall-* ruleset: ------------------------------------ . . Chain forward (policy REJECT): target prot opt source destination ports MASQ all ------ 192.168.0.0/24 0.0.0.0/0 n/a ACCEPT all ----l- 0.0.0.0/0 0.0.0.0/0 n/a . . ------------------------------------ ----------------------------------------------------------------------------- 5.8. Testing external MASQ ICMP forwarding   * Step Eight: Testing external MASQ ICMP forwarding From an internal MASQed computer, ping a static TCP/IP address (NOT a machine by DNS name) out on the Internet (i.e. ping 152.2.210.80 (this technically the DNS name "metalab.unc.edu" which is home of MetaLabs' Linux Archive). If this works, it should look something like the result below and this ultimately shows that ICMP Masquerading is working properly. (hit Control-C to abort the ping): ------------------------------------- masq-client# ping 152.2.210.80 PING 12.13.14.15 (152.2.210.80): 56 data bytes 64 bytes from 152.2.210.80: icmp_seq=0 ttl=255 time=133.4 ms 64 bytes from 152.2.210.80: icmp_seq=1 ttl=255 time=132.5 ms 64 bytes from 152.2.210.80: icmp_seq=2 ttl=255 time=128.8 ms 64 bytes from 152.2.210.80: icmp_seq=3 ttl=255 time=132.2 ms ^C --- 152.2.210.80 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 128.8/131.7/133.4 ms ------------------------------------- If this didn't work, again check your Internet connection. Make sure that the MASQ server itself can ping this address. If this works from the MASQ server, make sure you are using the simple rc.firewall-* ruleset and that you have ICMP Masqurading compiled into the Linux kernel. Finally, make sure that the ruleset which enables IP MASQ is pointing to the correct EXTERNAL interface. PPPoE users should use the MASQ servers's logical PPP interface such as "ppp0" and /NOT/ the physical external interface like "eth0". ----------------------------------------------------------------------------- 5.9. Testing MASQ functionality without DNS   * Step Nine: Testing MASQ functionality without DNS Now try TELNETing to a remote IP address (i.e. telnet 152.2.210.81 ( this is technically the DNS name "metalab.unc.edu"). It might take a few seconds to get a login prompt since this is a VERY busy server. Did you get a login prompt like shown below? If so, it means that TCP Masquerading is running OK. If not, try TELNETing to some other hosts you think will support TELNET like 198.182.196.55 (www.linux.org). If this still doesn't work, make sure you are using the simple rc.firewall-* ruleset for this test. An example of this output might look like (hit Control-D to exit out of the TELNET): -------------------------------- masq-client# telnet 152.2.210.80 Trying 152.2.210.80... Connected to 152.2.210.80. Escape character is '^]'. SunOS 5.7 ******************** Welcome to MetaLab.unc.edu ******************* To login to MetaLab as a user, connect to login.metalab.unc.edu. This machine does not allow public telnet logins. login: Connection closed by foreign host. -------------------------------- ----------------------------------------------------------------------------- 5.10. Testing MASQ functionality with DNS resolution   * Step Ten: Testing MASQ functionality with DNS resolution Now try TELNETing to a remote machine by DNS name (i.e. "telnet metalab.unc.edu" (IP address 152.2.210.81). If this works, the output should look like something below. With this test, this shows that UDP-based DNS is working fine. -------------------------------- masq-client# telnet MetaLab.unc.edu Trying 152.2.210.80... Connected to 152.2.210.80. Escape character is '^]'. SunOS 5.7 ******************** Welcome to MetaLab.unc.edu ******************* To login to MetaLab as a user, connect to login.metalab.unc.edu. This machine does not allow public telnet logins. login: Connection closed by foreign host. -------------------------------- If this did not work, but Step EIGHT did work, make sure that you have one or more valid DNS servers configured on each of the MASQ CLIENT computer(s) as shown in Chapter 4. Please note that these DNS servers will typically be your ISP's DNS servers and NOT your local MASQ server. Some people might later choose to setup their OWN DNS servers but this is beyond the scope of this HOWTO. ----------------------------------------------------------------------------- 5.11. Testing more MASQ functionality with DNS   * Step Eleven: Testing more MASQ functionality with DNS As a last test, try browsing some 'INTERNET' WWW sites on one of your MASQ Client machines, and see if you can reach them. For example, access the Linux Documentation Project site at [http://www.tldp.org] http:// www.tldp.org. If you are successful in bringing up that page, you can be fairly certain that everything is working FINE! If some WWW or FTP sites have problems, where other sites seem to work just fine, see the next step for more ideas. If you see The Linux Documentation Project homepage, then CONGRATULATIONS! It's working! If the WWW site comes up correctly, then all other standard network tools such as PING, TELNET, SSH, and with their related IP MASQ modules loaded: FTP, Real Audio, IRC DCCs, Quake I/ II/III, CuSeeme, VDOLive, etc. should work fine too! If FTP, IRC, RealAudio, Quake I/II/III, etc. aren't working or are performing poorly, verify that their associated Masquerading modules are loaded by running "lsmod" and also be sure you are loading the module with any non-default server ports. If you don't see your needed module, make sure your /etc/ rc.d/rc.firewall-* script is loading them (i.e. remove the # character for a given IP MASQ module). ----------------------------------------------------------------------------- 5.12. Any remaining functional, performance, etc. issues...   * Step Twelve: Any remaining functional, performance, etc. issues... If your system passes all of the above tests, but functionality tests like WWW browsing, FTP, and other types of traffic aren't reliable or are slow, I recommend that you read the FAQ section of this HOWTO.. specifically the Section 7.15 FAQ entry. There might be other items in the FAQ section that will also help you as they have helped many other users in the past. ----------------------------------------------------------------------------- Chapter 6. Other IP Masquerade Issues and Software Support 6.1. Problems with IP Masquerade Some TCP/IP application protocols will not currently work with Linux IP Masquerading because they either assume things about port numbers or encode TCP/IP addresses and/or port numbers in their data stream. These latter protocols need specific proxies or IP MASQ modules built into the masquerading code to make them work. ----------------------------------------------------------------------------- 6.2. Incoming services By default, Linux IP Masquerading cannot handle incoming services at all but there are a few ways that would allow this. If you do not require high levels of security, then you can simply forward or redirect IP ports. There are various ways to perform this, though the most stable method is to use IPPORTFW. For more information, please see Section 6.7. If you wish to have some level of authorization on incoming connections, then you will need to either configure TCP-wrappers or Xinetd to allow only specific IP addresses to pass. The TIS Firewall Toolkit is a good place to look for tools and information. More details on incoming security can be found in the [http:// www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#TrinityOS] TrinityOS document and at IP Masquerade Resource. ----------------------------------------------------------------------------- 6.3. Supported Client Software and Other Setup Notes "** The Linux Masquerade Application list has a lot of good information regarding applications that work through Linux IP masquerading. This site was recently taken over by Steve Grevemeyer, who implemented it with a full database backend. It's a great resource! " Generally, any application that uses standard TCP and UDP should work. If you have any suggestion, hints, etc., please see the [http://ipmasq.webhop.net/] IP Masquerade Resource for more details. ----------------------------------------------------------------------------- 6.3.1. Network Clients that -Work- with IP Masquerade General Clients: Archie all supported platforms, file searching client (not all archie clients are supported) FTP all supported platforms, with the ip_masq_ftp.o kernel module for active FTP connections. Gopher client all supported platforms HTTP all supported platforms, WWW surfing IRC all IRC clients on various supported platforms, DCC is supported via the ip_masq_irc.o module NNTP (USENET) all supported platforms, USENET news client PING all platforms, with ICMP Masquerading kernel option POP3 all supported platforms, email clients SSH all supported platforms, Secure TELNET/FTP clients SMTP all supported platforms, email servers like Sendmail, Qmail, PostFix, etc. TELNET all supported platforms, remote session TRACEROUTE UNIX and Windows based platforms, some variations may not work VRML Windows(possibly all supported platforms), virtual reality surfing WAIS client all supported platforms Multimedia and Communication Clients: All H.323 programs - MS Netmeeting, Intel Internet Phone Beta , and other H.323 applications - There are now two solutions to accomplish this through IPMASQed connections: There is a stable BETA 2.2.x kernel module available on the [http:// ipmasq.webhop.net] MASQ WWW site or at [http://www.coritel.it/projects/ nat/implementation.htm] http://www.coritel.it/projects/nat/ implementation.htm to work with Microsoft Netmeeting v3.x code on 2.2.x kernels. There is also another module version on the MASQ WWW site specifically for Netmeeting 2.x with 2.0.x kernels, but this does not support Netmeeting v3.x. Another commercial solution is the Equivalence's PhonePatch H.323 gateway. Alpha Worlds Windows, Client-Server 3D chat program CU-SeeMe all supported platforms, with the ip_masq_cuseeme module loaded, please see Section 6.8 for more details. ICQ all supported clients. Requires the Linux kernel to be either compiled with PORTFW support, have the ip_masq_icq module (2.2.x and 2.0.x only), or have a SOCKS proxy running. A full description of this configuration is in Section 6.9. Internet Phone 3.2 Windows, Peer-to-peer audio communications, users can reach you only if you initiate the call, but those users cannot call you without a specific port forwarding setup. See Section 6.7for more details. Internet Wave Player Windows, network streaming audio Powwow Windows, Peer-to-peer Text audio whiteboard communications, users can reach you only if you initiate the call, but those users cannot call you without a specific port forwarding setup. See Section 6.7for more details. Real Audio Player Windows, network streaming audio, higher quality available with the ip_masq_raudio UDP module True Speech Player 1.1b Windows, network streaming audio VDOLive Windows, with the ip_masq_vdolive patch Worlds Chat 0.9a Windows, Client-Server 3D chat program Games - See Section 6.10for more details on the LooseUDP patch Battle.net Works but requires TCP ports 116, 118 and UDP port 6112 IPPORTFWed to the client game machine. See Section 6.7for more details. Please note that FSGS and Bnetd servers still require IPPORTFW because they have not been re-written to be NAT-friendly. BattleZone 1.4 Works with LooseUDP patch and new NAT-friendly -- email [mailto: dranch@trinnet.net] David Ranch for the .DLLs from Activision Dark Reign 1.4 Works with LooseUDP patch or requires TCP ports 116 and 118 and UDP port 6112 IPPORTFWed to the game machine. See Section 6.7for more details. Diablo Works with LooseUDP patch or requires TCP ports 116 and 118 and UDP port 6112 IPPORTFWed to the game machine. Newer versions of Diablo use only TCP port 6112 and UDP port 6112. See Section 6.7for more details. Heavy Gear 2 Works with LooseUDP patch or requires TCP ports 116 and 118 and UDP port 6112 IPPORTFWed to the game machine. See Section 6.7for more details. Quake I/II/III Works right out of the box but requires the ip_masq_quake module if there are more than one Quake I/II/III player behind a MASQ box. Also, this module only supports Quake I and QuakeWorld by default. If you need to support Quake II or non-default server ports, please see the module install section of Section 3.4.3 and Section 3.4.2 rulesets. StarCraft Works with the LooseUDP patch, IPPORTFWing TCP, and UDP ports 6112 to the internal MASQed game machine. See Section 6.7for more details. WorldCraft Works with LooseUDP patch Other Clients: Linux net-acct package Linux, network administration-account package NCSA Telnet 2.3.08 DOS, a suite containing telnet, ftp, ping, etc. PC-anywhere for Windows MS-Windows remotely controls a PC over TCP/IP, but only works if it is a client, but not a host without a specific port forwarding setup. See Section 6.7for more details. Socket Watch uses NTP - network time protocol ----------------------------------------------------------------------------- 6.3.2. Clients that do not have full support in IP MASQ: Intel Streaming Media Viewer Beta 1 Cannot connect to server Netscape CoolTalk Cannot connect to opposite side WebPhone Cannot work at present (it makes invalid assumptions about addresses). ----------------------------------------------------------------------------- 6.4. Stronger firewall rulesets to run after initial testing 6.4.1. Stronger IP Firewall (IPTABLES) rulesets +--------------------------------------------------------------------------------+ |#!/bin/sh | |# | |# rc.firewall-iptables-stronger | |# | |FWVER=0.88s | | | |# An example of a stronger IPTABLES firewall with IP Masquerade | |# support for 2.4.x kernels. | |# | |# Log: | |# | |# 0.88s - Updated the commands for dynamically addresses machines and | |# to point to an expanded FAQ section for more information | |# | |# 0.87s - Removed the unused drop-and-logit chain as it was only later | |# being deleted anyway | |# 0.86s - Fixed a typo that had a preceeding ; instead of a # | |# 0.85s - renamed from rc.firewall-2.4-stronger to rc.firewall-iptables- | |# stronger to reflect this script works for all IPTABLES enabled | |# platforms including 2.6.x kernels | |# - fixed an incorrect /24 netmask for the INTIP variable | |# - removed the unneeded SED variable | |# 0.84s - Changed the defaults from 192.168.1.0 to 192.168.0.x to align | |# with the rest of the IPMASQ howto | |# 0.83s - Added additional comments to make PORTFW configs more obvious | |# 0.82s - Added a special ICMP filter to work around a Netfilter security | |# issue | |# - renamed the drop-and-log-it rule to reject-and-log-it | |# 0.81s - Added an additional comment in the INPUT section for NOT | |# allowing all traffic in, but only select traffic | |# 0.80s - Added a DISABLED ip_nat_irc kernel module section, changed the | |# default of the ip_conntrack_irc to NOT load by default, and | |# added additional kernel module comments | |# 0.79s - ruleset now uses modprobe instead of insmod | |# 0.78s - REJECT is not a legal policy yet; back to DROP | |# 0.77s - Changed the default block behavior to REJECT not DROP | |# 0.76s - Added a comment about the OPTIONAL WWW ruleset and a comment | |# where to put optional PORTFW commands | |# 0.75s - Added clarification that PPPoE users need to use | |# "ppp0" instead of "eth0" for their external interface | |# 0.74s - Changed the EXTIP command to work on NON-English distros | |# 0.73s - Added comments in the output section that DHCPd is optional | |# and changed the default settings to disabled | |# 0.72s - Changed the filter from the INTNET to the INTIP to be | |# stateful; moved the command VARs to the top and made the | |# rest of the script to use them | |# 0.70s - Added a disabled examples for allowing internal DHCP | |# and external WWW access to the server | |# 0.63s - Added support for the IRC module | |# 0.62s - Initial version based upon the basic 2.4.x rc.firewall | | | | | |echo -e "\nLoading rc.firewall-iptables-STRONGER - version $FWVER..\n" | | | | | |# The location of various iptables and other shell programs | |# | |# If your Linux distribution came with a copy of iptables, most | |# likely it is located in /sbin. If you manually compiled | |# iptables, the default location is in /usr/local/sbin | |# | |# ** Please use the "whereis iptables" command to figure out | |# ** where your copy is and change the path below to reflect | |# ** your setup | |# | |#IPTABLES=/sbin/iptables | |IPTABLES=/usr/local/sbin/iptables | |# | |LSMOD=/sbin/lsmod | |DEPMOD=/sbin/depmod | |MODPROBE=/sbin/modprobe | |GREP=/bin/grep | |AWK=/bin/awk | |IFCONFIG=/sbin/ifconfig | | | | | |#Setting the EXTERNAL and INTERNAL interfaces for the network | |# | |# Each IP Masquerade network needs to have at least one | |# external and one internal network. The external network | |# is where the natting will occur and the internal network | |# should preferably be addressed with a RFC1918 private address | |# scheme. | |# | |# For this example, "eth0" is external and "eth1" is internal" | |# | |# NOTE: If this doesnt EXACTLY fit your configuration, you must | |# change the EXTIF or INTIF variables above. For example: | |# | |# If you are a PPPoE or analog modem user: | |# | |# EXTIF="ppp0" | |# | |EXTIF="eth0" | |INTIF="eth1" | |echo " External Interface: $EXTIF" | |echo " Internal Interface: $INTIF" | |echo " ---" | | | |# Specify your Static IP address here or let the script take care of it | |# for you. | |# | |# If you prefer to use STATIC addresses in your firewalls, un-# out the | |# static example below and # out the dynamic line. If you don't care, | |# just leave this section alone. | |# | |# If you have a DYNAMIC IP address, the ruleset already takes care of | |# this for you. Please note that the different single and double quote | |# characters and the script MATTER. | |# | |# | |# PPP and DHCP (Cablemodem and DSL ) users: | |# ----------------------------------------- | |# PPP: If you get your TCP/IP address via DHCP, **you will need ** to | |# enable the # #ed out command below underneath the PPP section AND | |# replace the word "eth0" with the name of your EXTERNAL Internet | |# connection (ppp0, ippp0, etc) on the lines for "ppp-ip" and "extip". | |# | |# DHCP and PPP users: The remote DHCP or PPP server can and will change | |# IP addresses on you over time. To deal with this, users should configure | |# their DHCP or PPP client to re-run the rc.firewall-* ruleset everytime | |# the IP address is changed. Please see the "masq-and-dyn-addr" FAQ entry | |# in the IPMASQ howto for full details on how to do this. | |# | |# | |# Determine the external IP automatically: | |# ---------------------------------------- | |# | |# The following line will determine your external IP address. This | |# line is somewhat complex and confusing but it will also work for | |# all NON-English Linux distributions: | |# | |EXTIP="`$IFCONFIG $EXTIF | $AWK \ | | /$EXTIF/'{next}//{split($0,a,":");split(a[2],a," ");print a[1];exit}'`" | | | | | |# For users who wish to use STATIC IP addresses: | |# | |# # out the EXTIP line above and un-# out the EXTIP line below | |# | |#EXTIP="your.static.PPP.address" | |echo " External IP: $EXTIP" | |echo " ---" | | | | | |# Assign the internal TCP/IP network and IP address | |INTNET="192.168.0.0/24" | |INTIP="192.168.0.1/32" | |echo " Internal Network: $INTNET" | |echo " Internal IP: $INTIP" | |echo " ---" | | | | | | | | | |# Setting a few other local variables | |# | |UNIVERSE="0.0.0.0/0" | | | |#====================================================================== | |#== No editing beyond this line is required for initial MASQ testing == | | | |# Need to verify that all modules have all required dependencies | |# | |echo " - Verifying that all kernel modules are ok" | |$DEPMOD -a | | | |echo -en " Loading kernel modules: " | | | |# With the new IPTABLES code, the core MASQ functionality is now either | |# modular or compiled into the kernel. This HOWTO shows ALL IPTABLES | |# options as MODULES. If your kernel is compiled correctly, there is | |# NO need to load the kernel modules manually. | |# | |# NOTE: The following items are listed ONLY for informational reasons. | |# There is no reason to manual load these modules unless your | |# kernel is either mis-configured or you intentionally disabled | |# the kernel module autoloader. | |# | | | |# Upon the commands of starting up IP Masq on the server, the | |# following kernel modules will be automatically loaded: | |# | |# NOTE: Only load the IP MASQ modules you need. All current IP MASQ | |# modules are shown below but are commented out from loading. | |# =============================================================== | | | |#Load the main body of the IPTABLES module - "ip_tables" | |# - Loaded automatically when the "iptables" command is invoked | |# | |# - Loaded manually to clean up kernel auto-loading timing issues | |# | |echo -en "ip_tables, " | |# | |#Verify the module isn't loaded. If it is, skip it | |# | |if [ -z "` $LSMOD | $GREP ip_tables | $AWK {'print $1'} `" ]; then | | $MODPROBE ip_tables | |fi | | | | | |#Load the IPTABLES filtering module - "iptable_filter" | |# | |# - Loaded automatically when filter policies are activated | | | | | |#Load the stateful connection tracking framework - "ip_conntrack" | |# | |# The conntrack module in itself does nothing without other specific | |# conntrack modules being loaded afterwards such as the "ip_conntrack_ftp" | |# module | |# | |# - This module is loaded automatically when MASQ functionality is | |# enabled | |# | |# - Loaded manually to clean up kernel auto-loading timing issues | |# | |echo -en "ip_conntrack, " | |# | |#Verify the module isn't loaded. If it is, skip it | |# | |if [ -z "` $LSMOD | $GREP ip_conntrack | $AWK {'print $1'} `" ]; then | | $MODPROBE ip_conntrack | |fi | | | | | |#Load the FTP tracking mechanism for full FTP tracking | |# | |# Enabled by default -- insert a "#" on the next line to deactivate | |# | |echo -e "ip_conntrack_ftp, " | |# | |#Verify the module isn't loaded. If it is, skip it | |# | |if [ -z "` $LSMOD | $GREP ip_conntrack_ftp | $AWK {'print $1'} `" ]; then | | $MODPROBE ip_conntrack_ftp | |fi | | | | | |#Load the IRC tracking mechanism for full IRC tracking | |# | |# Disabled by default -- insert a "#" on the next few lines to activate | |# | |# echo -en " ip_conntrack_irc, " | |# | |#Verify the module isn't loaded. If it is, skip it | |# | |# if [ -z "` $LSMOD | $GREP ip_conntrack_irc | $AWK {'print $1'} `" ]; then | |# $MODPROBE ip_conntrack_irc | |# fi | | | | | |#Load the general IPTABLES NAT code - "iptable_nat" | |# - Loaded automatically when MASQ functionality is turned on | |# | |# - Loaded manually to clean up kernel auto-loading timing issues | |# | |echo -en "iptable_nat, " | |# | |#Verify the module isn't loaded. If it is, skip it | |# | |if [ -z "` $LSMOD | $GREP iptable_nat | $AWK {'print $1'} `" ]; then | | $MODPROBE iptable_nat | |fi | | | | | |#Loads the FTP NAT functionality into the core IPTABLES code | |# Required to support non-PASV FTP. | |# | |# Enabled by default -- insert a "#" on the next line to deactivate | |# | |echo -e "ip_nat_ftp" | |# | |#Verify the module isn't loaded. If it is, skip it | |# | |if [ -z "` $LSMOD | $GREP ip_nat_ftp | $AWK {'print $1'} `" ]; then | | $MODPROBE ip_nat_ftp | |fi | | | | | |#Loads the IRC NAT functionality (for DCC) into the core IPTABLES code | |# | |# DISABLED by default -- delete the "#" on the next few lines to activate | |# | |# echo -e "ip_nat_irc" | |# | |#Verify the module isn't loaded. If it is, skip it | |# | |# if [ -z "` $LSMOD | $GREP ip_nat_irc | $AWK {'print $1'} `" ]; then | |# $MODPROBE ip_nat_irc | |# fi | | | | | |echo " ---" | | | |# Just to be complete, here is a partial list of some of the other | |# IPTABLES kernel modules and their function. Please note that most | |# of these modules (the ipt ones) are automatically loaded by the | |# master kernel module for proper operation and don't need to be | |# manually loaded. | |# -------------------------------------------------------------------- | |# | |# ip_nat_snmp_basic - this module allows for proper NATing of some | |# SNMP traffic | |# | |# iptable_mangle - this target allows for packets to be | |# manipulated for things like the TCPMSS | |# option, etc. | |# | |# -- | |# | |# ipt_mark - this target marks a given packet for future action. | |# This automatically loads the ipt_MARK module | |# | |# ipt_tcpmss - this target allows to manipulate the TCP MSS | |# option for braindead remote firewalls. | |# This automatically loads the ipt_TCPMSS module | |# | |# ipt_limit - this target allows for packets to be limited to | |# to many hits per sec/min/hr | |# | |# ipt_multiport - this match allows for targets within a range | |# of port numbers vs. listing each port individually | |# | |# ipt_state - this match allows to catch packets with various | |# IP and TCP flags set/unset | |# | |# ipt_unclean - this match allows to catch packets that have invalid | |# IP/TCP flags set | |# | |# iptable_filter - this module allows for packets to be DROPped, | |# REJECTed, or LOGged. This module automatically | |# loads the following modules: | |# | |# ipt_LOG - this target allows for packets to be | |# logged | |# | |# ipt_REJECT - this target DROPs the packet and returns | |# a configurable ICMP packet back to the | |# sender. | | | | | |#CRITICAL: Enable IP forwarding since it is disabled by default since | |# | |# Redhat Users: you may try changing the options in | |# /etc/sysconfig/network from: | |# | |# FORWARD_IPV4=false | |# to | |# FORWARD_IPV4=true | |# | |echo " Enabling forwarding.." | |echo "1" > /proc/sys/net/ipv4/ip_forward | | | | | |# Dynamic IP users: | |# | |# If you get your IP address dynamically from SLIP, PPP, or DHCP, | |# enable the following option. This enables dynamic-address hacking | |# which makes the life with Diald and similar programs much easier. | |# | |echo " Enabling DynamicAddr.." | |echo "1" > /proc/sys/net/ipv4/ip_dynaddr | | | |echo " ---" | | | |############################################################################# | |# | |# Enable Stronger IP forwarding and Masquerading | |# | |# NOTE: In IPTABLES speak, IP Masquerading is a form of SourceNAT or SNAT. | |# | |# NOTE #2: The following is an example for an internal LAN address in the | |# 192.168.0.x network with a 255.255.255.0 or a "24" bit subnet | |# mask connecting to the Internet on external interface "eth0". | |# This example will MASQ internal traffic out to the Internet | |# but not allow non-initiated traffic into your internal network. | |# | |# | |# ** Please change the above network numbers, subnet mask, and your | |# | | | |#Clearing any previous configuration | |# | |# Unless specified, the defaults for INPUT, OUTPUT, and FORWARD to DROP | |# | |# You CANNOT change this to REJECT as it isn't a vaild policy setting. | |# If you want REJECT, you must explictly REJECT at the end of a giving | |# INPUT, OUTPUT, or FORWARD chain | |# | |echo " Clearing any existing rules and setting default policy to DROP.." | |$IPTABLES -P INPUT DROP | |$IPTABLES -F INPUT | |$IPTABLES -P OUTPUT DROP | |$IPTABLES -F OUTPUT | |$IPTABLES -P FORWARD DROP | |$IPTABLES -F FORWARD | |$IPTABLES -F -t nat | | | |#Not needed and it will only load the unneeded kernel module | |# | |#$IPTABLES -F -t mangle | | | | | |# Delete all User-specified chains | |$IPTABLES -X | | | | | |# Reset all IPTABLES counters | |$IPTABLES -Z | | | | | |#Configuring specific CHAINS for later use in the ruleset | |# | |# NOTE: Some users prefer to have their firewall silently | |# "DROP" packets while others prefer to use "REJECT" | |# to send ICMP error messages back to the remote | |# machine. The default is "REJECT" but feel free to | |# change this below. | |# | |# NOTE: Without the --log-level set to "info", every single | |# firewall hit will goto ALL vtys. This is a very big | |# pain. | |# | |echo " Creating a DROP chain.." | |$IPTABLES -N reject-and-log-it | |$IPTABLES -A reject-and-log-it -j LOG --log-level info | |$IPTABLES -A reject-and-log-it -j REJECT | | | |echo -e "\n - Loading INPUT rulesets" | | | | | |####################################################################### | |# INPUT: Incoming traffic from various interfaces. All rulesets are | |# already flushed and set to a default policy of DROP. | |# | | | |# loopback interfaces are valid. | |# | |$IPTABLES -A INPUT -i lo -s $UNIVERSE -d $UNIVERSE -j ACCEPT | | | | | |# local interface, local machines, going anywhere is valid | |# | |$IPTABLES -A INPUT -i $INTIF -s $INTNET -d $UNIVERSE -j ACCEPT | | | | | |# remote interface, claiming to be local machines, IP spoofing, get lost | |# | |$IPTABLES -A INPUT -i $EXTIF -s $INTNET -d $UNIVERSE -j reject-and-log-it | | | | | |# external interface, from any source, for ICMP traffic is valid | |# | |# If you would like your machine to "ping" from the Internet, | |# enable this next line | |# | |#$IPTABLES -A INPUT -i $EXTIF -p ICMP -s $UNIVERSE -d $EXTIP -j ACCEPT | | | | | |# remote interface, any source, going to the MASQ servers IP address is valid | |# | |# ENABLE this line if you want ALL Internet traffic to connect to your | |# the various servers running on the MASQ server. This includes | |# web servers, ssh servers, dns servers, etc. | |# | |# I DON'T recommend you enable this rule. Instead, only enable specific | |# access to select server ports under the "OPTIONAL INPUT Section". | |# An example of enabling HTTP (WWW) has been given below: | |# | |# | |#$IPTABLES -A INPUT -i $EXTIF -s $UNIVERSE -d $EXTIP -j ACCEPT | | | | | |# Allow any related traffic coming back to the MASQ server in. | |# | |# STATEFULLY TRACKED | |# | |$IPTABLES -A INPUT -i $EXTIF -s $UNIVERSE -d $EXTIP -m state --state \ | | ESTABLISHED,RELATED -j ACCEPT | | | | | |# ----- Begin OPTIONAL INPUT Section ----- | |# | | | |# DHCPd - Enable the following lines if you run an INTERNAL DHCPd server | |# | |#$IPTABLES -A INPUT -i $INTIF -p tcp --sport 68 --dport 67 -j ACCEPT | |#$IPTABLES -A INPUT -i $INTIF -p udp --sport 68 --dport 67 -j ACCEPT | | | |# HTTPd - Enable the following lines if you run an EXTERNAL WWW server | |# | |# NOTE: This is NOT needed for simply enabling PORTFW. This is ONLY | |# for users that plan on running Apache on the MASQ server itself | |# | |#echo -e " - Allowing EXTERNAL access to the WWW server" | |#$IPTABLES -A INPUT -i $EXTIF -m state --state NEW,ESTABLISHED,RELATED \ | |# -p tcp -s $UNIVERSE -d $EXTIP --dport 80 -j ACCEPT | | | |# | |# ----- End OPTIONAL INPUT Section ----- | | | | | |# Catch all rule, all other incoming is denied and logged. | |# | |$IPTABLES -A INPUT -s $UNIVERSE -d $UNIVERSE -j reject-and-log-it | | | | | |# --------------------------------------------------------------------- | | | |echo -e " - Loading OUTPUT rulesets" | | | |####################################################################### | |# OUTPUT: Outgoing traffic from various interfaces. All rulesets are | |# already flushed and set to a default policy of DROP. | |# | | | |# Workaround bug in netfilter | |# See http://www.netfilter.org/security/2002-04-02-icmp-dnat.html | |# | |$IPTABLES -A OUTPUT -m state -p icmp --state INVALID -j DROP | | | |# loopback interface is valid. | |# | |$IPTABLES -A OUTPUT -o lo -s $UNIVERSE -d $UNIVERSE -j ACCEPT | | | | | |# local interfaces, any source going to local net is valid | |# | |$IPTABLES -A OUTPUT -o $INTIF -s $EXTIP -d $INTNET -j ACCEPT | | | | | |# local interface, MASQ server source going to the local net is valid | |# | |$IPTABLES -A OUTPUT -o $INTIF -s $INTIP -d $INTNET -j ACCEPT | | | | | |# outgoing to local net on remote interface, stuffed routing, deny | |# | |$IPTABLES -A OUTPUT -o $EXTIF -s $UNIVERSE -d $INTNET -j reject-and-log-it | | | | | |# anything else outgoing on remote interface is valid | |# | |$IPTABLES -A OUTPUT -o $EXTIF -s $EXTIP -d $UNIVERSE -j ACCEPT | | | | | |# ----- Begin OPTIONAL OUTPUT Section ----- | |# | | | |# DHCPd - Enable the following lines if you run an INTERNAL DHCPd server | |# - Remove BOTH #s all the #s if you need this functionality. | |# | |#$IPTABLES -A OUTPUT -o $INTIF -p tcp -s $INTIP --sport 67 \ | |# -d 255.255.255.255 --dport 68 -j ACCEPT | |#$IPTABLES -A OUTPUT -o $INTIF -p udp -s $INTIP --sport 67 \ | |# -d 255.255.255.255 --dport 68 -j ACCEPT | | | |# | |# ----- End OPTIONAL OUTPUT Section ----- | | | | | |# Catch all rule, all other outgoing is denied and logged. | |# | |$IPTABLES -A OUTPUT -s $UNIVERSE -d $UNIVERSE -j reject-and-log-it | | | | | |echo -e " - Loading FORWARD rulesets" | | | |####################################################################### | |# FORWARD: Enable Forwarding and thus IPMASQ | |# | | | |# ----- Begin OPTIONAL FORWARD Section ----- | |# | |# Put PORTFW commands here | |# | |# ----- End OPTIONAL FORWARD Section ----- | | | | | |echo " - FWD: Allow all connections OUT and only existing/related IN" | |$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED \ | | -j ACCEPT | |$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT | | | |# Catch all rule, all other forwarding is denied and logged. | |# | |$IPTABLES -A FORWARD -j reject-and-log-it | | | | | |echo " - NAT: Enabling SNAT (MASQUERADE) functionality on $EXTIF" | |# | |#More liberal form | |#$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE | |# | |#Stricter form | |$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j SNAT --to $EXTIP | | | | | |####################################################################### | |echo -e "\nrc.firewall-iptables-stronger $FWVER done.\n" | +--------------------------------------------------------------------------------+ To automatically start this stronger firewall ruleset at the proper time, please see the end of the Section 3.4.2 section for full details. Please make sure you make the correct "rc.firewall-iptables" to "rc.firewall-iptables-stronger" substitutions!! ----------------------------------------------------------------------------- 6.4.2. Stronger IP Firewall (IPCHAINS) rulesets This section provides a more in-depth guide to using the 2.2.x firewall tool, IPCHAINS. See above sections for IPFWADM rulesets. This example is for a firewall/masquerade system behind a PPP link with a static PPP address (dynamic PPP instructions are included but disabled). The trusted interface is 192.168.0.1 and the PPP interface IP address has been changed to protect the guilty :-). I have listed each incoming and outgoing interface individually to catch IP spoofing as well as stuffed routing and/or masquerading. A nything not explicitly allowed is FORBIDDEN (well.. rejected actually). If your IP MASQ box breaks after implementing this rc.firewall-ipchains-stronger script, be sure that you edit it for your configuration and check your /var/log/messages or /var/adm/messages SYSLOG file for any firewall errors. For more comprehensive examples of a strong IP Masqueraded IPFWADM rulesets for PPP, Cablemodem users, etc., please see [http://www.ecst.csuchico.edu/ ~dranch/LINUX/index-linux.html#TrinityOS] TrinityOS - Section 10 and [http:// www.greatcircle.com/] GreatCircle's Firewall WWW page NOTE #1: --- UPDATE YOUR KERNEL --- Linux 2.2.x kernels less than version 2.2.20 contain several different security vulnerabilities (some were MASQ specific). Kernels less than 2.2.20 have a few local vulnerabilities. Kernel versions less than 2.2.16 have a TCP root exploit vulnerability and versions less than 2.2.11 have a IPCHAINS fragmentation bug. Because of these issues, users running a firewall with strong IPCHAINS rulesets are open to possible instrusion. Please upgrade your kernel to a fixed version. NOTE #2: If you get a dynamically assigned TCP/IP address from your ISP (PPP, DSL, Cablemodems, etc.), you CANNOT load this strong ruleset upon booting. You will either need to reload this firewall ruleset EVERY TIME you get a new IP address or make your /etc/rc.d/rc.firewall-ipchains-stronger ruleset more intelligent. To do this for various types of connections such as PPP or DHCP users, please see the Section 7.8 FAQ entry for all the details. Please also be aware that there are several GUI Firewall creation tools available as well. Please see Chapter 7for full details. Lastly, if you are using a STATIC PPP IP address, change the "EXTIF= "your.static.PPP.address"" line to reflect your address. ---------------------------------------------------------------- +-----------------------------------------------------------------------------------+ |#!/bin/sh | |# | |# /etc/rc.d/rc.firewall-ipchains-stronger: An example of a Stronger IPCHAINS | |# firewall ruleset for 2.2 kernels | |# | |FWVER=0.75s | |# | |# Log: | |# 0.75s - Updated the commands for dynamically addresses machines and | |# to point to an expanded FAQ section for more information | |# | |# 0.74s - renamed from rc.firewall-2.2-stronger to | |# rc.firewall-ipchains-stronger to better reflect that this ruleset can | |# can run on different major kernel versions | |# - removed unused SED variable | |# 0.73s - Added additional comments to make PORTFW configs more obvious | |# 0.72s - #ed out the rule that would allow all traffic destined for the | |# MASQ server itself to be accepted. Use the OPTIONAL INPUT | |# section to only allow explicit services. | |# - Fixed an INTLAN rule that was allowing traffic from ANY IP address | |# instead of the proper INTIP IP address only. This aligns the | |# IPCHAINS ruleset with the IPTABLES and IPFWADM ruleset examples | |# 0.71s - ruleset now uses modprobe instead of insmod | |# 0.70s - Added missing execution variables | |# - fixed a missing -p tcp for the commented HTTPd section | |# 0.65s - Added comments HTTPd rules to the INPUT and OUTPUT section | |# - Added a comment where to insert IPPORTFW commands | |# 0.60s - Changed the EXTIP command to work on NON-English distros | |# - Updated the CASE of some of the script variables | |# | | | |echo -e "\nLoading rc.firewall-ipchains-stronger : version $FWVER..\n" | | | | | |# The location of various iptables and other shell programs | |# | |# If your Linux distribution came with a copy of iptables, most | |# likely it is located in /sbin. If you manually compiled | |# iptables, the default location is in /usr/local/sbin | |# | |# ** Please use the "whereis iptables" command to figure out | |# ** where your copy is and change the path below to reflect | |# ** your setup | |# | |IPCHAINS=/sbin/ipchains | |LSMOD=/sbin/lsmod | |DEPMOD=/sbin/depmod | |MODPROBE=/sbin/modprobe | |GREP=/bin/grep | |AWK=/bin/awk | |IFCONFIG=/sbin/ifconfig | | | |PATH=/sbin:/bin:/usr/sbin:/usr/bin | | | | | |# Global variables | |# ---------------- | | | |# ALL PPP and DHCP users must set this for the correct EXTERNAL and | |# INTERNAL interfaces names. Examples: eth0, ppp0, ippp0, etc. | |# See more info about this below. | |# | |EXTIF="ppp0" | |INTIF="eth0" | | | |# The INTERNAL IP address | |# | |INTIP="192.168.0.1/32" | |INTNET="192.168.0.0/24" | |echo " Internal IP: $INTIP" | |echo " Internal Network: $INTNET" | | | | | | | |# Load all required IP MASQ modules | |# | |# NOTE: Only load the IP MASQ modules you need. All current IP MASQ modules | |# are shown below but are commented from loading. | | | |# Needed to initially load modules | |# | |$DEPMOD -a | | | |# Supports the proper masquerading of FTP file transfers using the PORT method | |# | |$MODPROBE ip_masq_ftp | | | |# Supports the masquerading of RealAudio over UDP. Without this module, | |# RealAudio WILL function but in TCP mode. This can cause a reduction | |# in sound quality | |# | |$MODPROBE ip_masq_raudio | | | |# Supports the masquerading of IRC DCC file transfers | |# | |#$MODPROBE ip_masq_irc | | | | | |# Supports the masquerading of Quake and QuakeWorld by default. These modules are | |# for multiple users behind the Linux MASQ server. If you are going to | |# play Quake I, II, and III, use the second example. | |# | |# NOTE: If you get ERRORs loading the QUAKE module, you are running an old | |# ----- kernel that has bugs in it. Please upgrade to the newest kernel. | |# | |#Quake I / QuakeWorld (ports 26000 and 27000) | |#$MODPROBE ip_masq_quake | |# | |#Quake I/II/III / QuakeWorld (ports 26000, 27000, 27910, 27960) | |#$MODPROBE ip_masq_quake 26000,27000,27910,27960 | | | | | |# Supports the masquerading of the CuSeeme video conferencing software | |# | |#$MODPROBE ip_masq_cuseeme | | | |#Supports the masquerading of the VDO-live video conferencing software | |# | |#$MODPROBE ip_masq_vdolive | | | | | |#CRITICAL: Enable IP forwarding since it is disabled by default | |# | |# Redhat Users: you may try changing the options in | |# /etc/sysconfig/network from: | |# | |# FORWARD_IPV4=false | |# to | |# FORWARD_IPV4=true | |# | |echo "1" > /proc/sys/net/ipv4/ip_forward | | | | | |#CRITICAL: Enable automatic IP defragmentation since it is disabled by default | |# in 2.2.x kernels | |# | |# This used as a compile-time option but the behavior was changed | |# in 2.2.12. It should also be noted that some distributions have | |# removed this option from the /proc table. If this entry isn't | |# present in your /proc, don't worry about it. | |# | |echo "1" > /proc/sys/net/ipv4/ip_always_defrag | | | | | |# Dynamic IP users: | |# | |# If you get your IP address dynamically from SLIP, PPP, or DHCP, enable this | |# following option. This enables dynamic-ip address hacking in IP MASQ, | |# making life with Diald and similar programs much easier. | |# | |#echo "1" > /proc/sys/net/ipv4/ip_dynaddr | | | | | |# Enable the LooseUDP patch which some Internet-based games require | |# | |# If you are trying to get an Internet game to work through your IP MASQ box, | |# and you configured it to the best of your ability without it working, try | |# enabling this option (delete the "#" character). This option is disabled | |# by default due to possible internal machine UDP port scanning | |# vulnerabilities. | |# | |#echo "1" > /proc/sys/net/ipv4/ip_masq_udp_dloose | | | | | |# Specify your Static IP address here. | |# | |# If you have a DYNAMIC IP address, you need to make this ruleset recognize | |# your IP address everytime you get a new IP. To do this, enable the | |# following one-line script. (Please note that the different single and | |# double quote characters MATTER). | |# | |# | |# DHCP users (Cablemodem and DSL ) users: | |# --------------------------------------- | |# If you get your TCP/IP address via DHCP, **you will need ** to enable the | |# #ed out command below underneath the PPP section AND replace the word | |# "ppp0" with the name of your EXTERNAL Internet connection (eth0, eth1, etc) | |# on the lines for "ppp-ip" and "EXTIP". | |# | |# DHCP and PPP users: The remote DHCP or PPP server can and will change | |# IP addresses on you over time. To deal with this, users should configure | |# their DHCP or PPP client to re-run the rc.firewall-* ruleset everytime | |# the IP address is changed. Please see the "masq-and-dyn-addr" FAQ entry | |# in the IPMASQ howto for full details on how to do this. | |# | |# | |# Determine the external IP automatically: | |# ---------------------------------------- | |# | |# The following line will determine your external IP address. This | |# line is somewhat complex and confusing but it will also work for | |# all NON-English Linux distributions. | |# | |# Make sure the EXTIF variable above is set to reflect the name | |# of your Internet connection | |# | |EXTIP="`$IFCONFIG $EXTIF | $AWK \ | | /$EXTIF/'{next}//{split($0,a,":");split(a[2],a," ");print a[1];exit}'`" | | | | | | | |# MASQ timeouts | |# | |# 2 hrs timeout for TCP session timeouts | |# 10 sec timeout for traffic after the TCP/IP "FIN" packet is received | |# 60 sec timeout for UDP traffic (MASQ'ed ICQ users must enable a 30sec | |# firewall timeout in ICQ itself) | |# | |$IPCHAINS -M -S 7200 10 60 | | | |############################################################################# | |# Incoming, flush and set default policy of reject. Actually the default policy | |# is irrelevant because there is a catch all rule with deny and log. | |# | |$IPCHAINS -F input | |$IPCHAINS -P input REJECT | | | |# local interface, local machines, going anywhere is valid | |# | |$IPCHAINS -A input -i $INTIF -s $INTNET -d 0.0.0.0/0 -j ACCEPT | | | |# remote interface, claiming to be local machines, IP spoofing, get lost | |# | |$IPCHAINS -A input -i $EXTIF -s $INTNET -d 0.0.0.0/0 -l -j REJECT | | | | | |# remote interface, any source, going to the MASQ servers IP address is valid | |# | |# ENABLE this line if you want ALL Internet traffic to connect to your | |# the various servers running on the MASQ server. This includes | |# web servers, ssh servers, dns servers, etc. | |# | |# I DON'T recommend you enable this rule. Instead, only enable specific | |# access to select server ports under the "OPTIONAL INPUT Section". | |# An example of enabling HTTP (WWW) has been given below: | |# | |# | |#$IPCHAINS -A input -i $EXTIF -s 0.0.0.0/0 -d $EXTIP/32 -j ACCEPT | | | | | |# loopback interface is valid. | |# | |$IPCHAINS -A input -i lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT | | | | | |# ----- Begin OPTIONAL INPUT Section ----- | |# | | | |# HTTPd - Enable the following lines if you either run a WWW server on | |# the IPMASQ server -OR- plan on PORTFW'ing HTTP traffic to | |# an internal WWW server | |# | |#$IPCHAINS -A input -i $EXTIF -p tcp -s 0.0.0.0/0 -d $EXTIP 80 -j ACCEPT | | | |# | |# ----- End OPTIONAL INPUT Section ----- | | | | | |# catch all rule, all other incoming is denied and logged. pity there is no | |# log option on the policy but this does the job instead. | |# | |$IPCHAINS -A input -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT | | | |############################################################################# | |# Outgoing, flush and set default policy of reject. Actually the default policy | |# is irrelevant because there is a catch all rule with deny and log. | |# | |$IPCHAINS -F output | |$IPCHAINS -P output REJECT | | | |# local interface, MASQ server source going to the local net is valid | |# | |$IPCHAINS -A output -i $INTIF -s $INTIP -d $INTNET -j ACCEPT | | | |# outgoing to local net on remote interface, stuffed routing, deny | |# | |$IPCHAINS -A output -i $EXTIF -s 0.0.0.0/0 -d $INTNET -l -j REJECT | | | |# outgoing from local net on remote interface, stuffed masquerading, deny | |# | |$IPCHAINS -A output -i $EXTIF -s $INTNET -d 0.0.0.0/0 -l -j REJECT | | | |# anything else outgoing on remote interface is valid | |# | |$IPCHAINS -A output -i $EXTIF -s $EXTIP/32 -d 0.0.0.0/0 -j ACCEPT | | | |# loopback interface is valid. | |# | |$IPCHAINS -A output -i lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT | | | | | |# ----- Begin OPTIONAL OUTPUT Section ----- | |# | | | |# HTTPd - Enable the following lines if you either run a WWW server on | |# the IPMASQ server -OR- plan on PORTFW'ing HTTP traffic to | |# an internal WWW server | |# | |#$IPCHAINS -A output -i $EXTIF -p tcp -s $EXTIP 80 -d 0.0.0.0/0 -j ACCEPT | | | |# | |# ----- End OPTIONAL OUTPUT Section ----- | | | |# catch all rule, all other outgoing is denied and logged. pity there is no | |# log option on the policy but this does the job instead. | |# | |$IPCHAINS -A output -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT | | | |############################################################################# | |# Forwarding, flush and set default policy of deny. Actually the default policy | |# is irrelevant because there is a catch all rule with deny and log. | |# | |$IPCHAINS -F forward | |$IPCHAINS -P forward DENY | | | | | |# ----- Begin OPTIONAL FORWARD Section ----- | |# | |# Put PORTFW commands here | |# | |# ----- End OPTIONAL FORWARD Section ----- | | | | | |# Masquerade from local net on local interface to anywhere. | |# | |$IPCHAINS -A forward -i $EXTIF -s $INTNET -d 0.0.0.0/0 -j MASQ | |# | |# catch all rule, all other forwarding is denied and logged. pity there is no | |# log option on the policy but this does the job instead. | |# | |$IPCHAINS -A forward -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT | | | |#End of file. | +-----------------------------------------------------------------------------------+ To automatically start this stronger firewall ruleset at the proper time, please see the end of the Section 3.4.2 section for full details. Please make sure you make the correct "rc.firewall-ipchains" to "rc.firewall-ipchains-stronger" substitutions!! With IPCHAINS, you can block traffic to a particular site using the "input", "output", and/or "forward" rules. Remember that the set of rules are scanned from top to bottom and "-A" tells IPCHIANS to "append" this new rule to the existing set of rules. So with this in mind, any specific restrictions need to come before any global rules. For example: Using "input" rules: Probably the fastest and most efficient method to block traffic, but this method only stops the MASQed machines and NOT the firewall machine itself. Of course, you might want to allow that combination. Anyway, to block 204.50.10.13: +---------------------------------------------------------------------------+ |In the /etc/rc.d/rc.firewall-ipchains-stronger ruleset: | |... start of "input" rules ... | | | |# reject and log local interface, local machines going to 204.50.10.13 | |# | |ipchains -A input -s 192.168.0.0/24 -d 204.50.10.13/32 -l -j REJECT | | | | | |# local interface, local machines, going anywhere is valid | |# | |ipchains -A input -s 192.168.0.0/24 -d 0.0.0.0/0 -l -j ACCEPT | | | | | |... end of "input" rules ... | +---------------------------------------------------------------------------+ Using "output" rules: This is the slower method to block traffic because the packets must go through masquerading before they are dropped. Yet, this rule even stops the firewall machine from accessing the forbidden site. ... start of "output" rules ... # reject and log outgoing to 204.50.10.13 # ipchains -A output -s $ppp_ip/32 -d 204.50.10.13/32 -l -j REJECT # anything else outgoing on remote interface is valid # ipchains -A output -s $ppp_ip/32 -d 0.0.0.0/0 -l -j ACCEPT ... end of "output" rules ... Using "forward" rules: Probably slower than "input" rules for blocking traffic, this only stops masqueraded machines (e.g. internal machines). The firewall machine can still reach forbidden site(s). ... start of "forward" rules ... # Reject and log from local net on PPP interface to 204.50.10.13. # ipchains -A forward -i ppp0 -s 192.168.0.0/24 -d 204.50.10.13/32 -l -j REJECT # Masquerade from local net on local interface to anywhere. # ipchains -A forward -i ppp0 -s 192.168.0.0/24 -d 0.0.0.0/0 -j MASQ ... end of "forward" rules ... No need for a special rule to allow machines on the 192.168.0.0/24 network to go to 204.50.11.0. Why? It is already covered by the global MASQ rule. NOTE: Unlike IPFWADM, IPCHIANS has only one way of coding the interfaces name. IPCHAINS uses the "-i eth0" option where as IPFWADM had both "-W" for the interface name and "-V" for the interface's IP address. ----------------------------------------------------------------------------- 6.4.3. Stronger IP Firewall (IPFWADM) Rulesets This section provides a more in-depth guide on using the 2.0.x firewall tool, IPFWADM. See below for IPCHAINS rulesets This example is for a firewall/masquerade system behind a PPP link with a static PPP address (dynamic PPP instructions are included but disabled). The trusted interface is 192.168.0.1 and the PPP interface IP address has been changed to protect the guilty :). I have listed each incoming and outgoing interface individually to catch IP spoofing as well as stuffed routing and/or masquerading. Anything not explicitly allowed is FORBIDDEN (well.. rejected, actually). If your IP MASQ box breaks after implementing this rc.firewall-ipfwadm-stronger script, be sure that you edit it for your configuration and check your /var/log/messages or /var/adm/messages SYSLOG file for any firewall errors. For more comprehensive examples of a strong IP Masqueraded IPFWADM rulesets for PPP, Cablemodem users, etc., please see [http://www.ecst.csuchico.edu/ ~dranch/LINUX/index-linux.html#TrinityOS] TrinityOS - Section 10 and [http:// www.greatcircle.com/] GreatCircle's Firewall WWW page NOTE #2: If you get a dynamically assigned TCP/IP address from your ISP (PPP, DSL, Cablemodems, etc.), you CANNOT load this strong ruleset upon booting. You will either need to reload this firewall ruleset EVERY TIME you get a new IP address or make your /etc/rc.d/rc.firewall-ipchains-stronger ruleset more intelligent. To do this for various types of connections such as PPP or DHCP users, please see the Section 7.8 FAQ entry for all the details. Please also be aware that there are several GUI Firewall creation tools available as well. Please see Chapter 7for full details. Lastly, if you are using a STATIC PPP IP address, change the "ppp_ip= "your.static.PPP.address"" line to reflect your address. ---------------------------------------------------------------- +-----------------------------------------------------------------------------------------+ |#!/bin/sh | |# | |# /etc/rc.d/rc.firewall-ipfwadm-stronger: An example of a semi-STRONG | |# IPFWADM firewall ruleset for 2.0 kernels | |# | |FWVER=0.74s | |# | |# Log: | |# 0.74s - Updated the commands for dynamically addresses machines and | |# to point to an expanded FAQ section for more information | |# | |# 0.73s - renamed from rc.firewall-2.0-stronger to | |# rc.firewall-ipfwadm-stronger | |# | |# 0.72s - #ed out the rule that would allow all traffic destined for the | |# MASQ server itself to be accepted. Use the OPTIONAL INPUT | |# section to only allow explicit services. | | | | | |PATH=/sbin:/bin:/usr/sbin:/usr/bin | | | |# testing, wait a bit then clear all firewall rules. | |# uncomment the following lines if you want the firewall to automatically | |# disable after 10 minutes. | |# | |# Disabled by default | |# | |# (sleep 600; \ | |# ipfwadm -I -f; \ | |# ipfwadm -I -p accept; \ | |# ipfwadm -O -f; \ | |# ipfwadm -O -p accept; \ | |# ipfwadm -F -f; \ | |# ipfwadm -F -p accept; \ | |# ) & | | | | | |# Load all required IP MASQ modules | |# | |# NOTE: Only load the IP MASQ modules you need. All current IP MASQ modules | |# are shown below but are commented from loading. | | | |# Needed to initially load modules | |# | |/sbin/depmod -a | | | |# Supports the proper masquerading of FTP file transfers using the PORT method | |# | |/sbin/modprobe ip_masq_ftp | | | |# Supports the masquerading of RealAudio over UDP. Without this module, | |# RealAudio WILL function but in TCP mode. This can cause a reduction | |# in sound quality | |# | |#/sbin/modprobe ip_masq_raudio | | | |# Supports the masquerading of IRC DCC file transfers | |# | |#/sbin/modprobe ip_masq_irc | | | | | |# Supports the masquerading of Quake and QuakeWorld by default. This modules is | |# for multiple users behind the Linux MASQ server. If you are going to | |# play Quake I, II, and III, use the second example. | |# | |# NOTE: If you get ERRORs loading the QUAKE module, you are running an old | |# ----- kernel that has bugs in it. Please upgrade to the newest kernel. | |# | |#Quake I / QuakeWorld (ports 26000 and 27000) | |#/sbin/modprobe ip_masq_quake | |# | |#Quake I/II/III / QuakeWorld (ports 26000, 27000, 27910, 27960) | |#/sbin/modprobe ip_masq_quake 26000,27000,27910,27960 | | | | | |# Supports the masquerading of the CuSeeme video conferencing software | |# | |#/sbin/modprobe ip_masq_cuseeme | | | |#Supports the masquerading of the VDO-live video conferencing software | |# | |#/sbin/modprobe ip_masq_vdolive | | | | | |#CRITICAL: Enable IP forwarding, since it is disabled by default | |# | |# Redhat Users: you may try changing the options in /etc/sysconfig/network | |# from: | |# | |# FORWARD_IPV4=false | |# to | |# FORWARD_IPV4=true | |# | |echo "1" > /proc/sys/net/ipv4/ip_forward | | | | | |#CRITICAL: Enable automatic IP defragmenting since it is disabled by default | |# in 2.2.x kernels | |# | |# This used to be a compile-time option but the behavior was changed | |# in 2.2.12 | |# | |echo "1" > /proc/sys/net/ipv4/ip_always_defrag | | | | | |# Dynamic IP users: | |# | |# If you get your IP address dynamically from SLIP, PPP, or DHCP, enable this | |# following option. This allows dynamic-ip address hacking in IP MASQ, | |# making the life with Diald and similar programs much easier. | |# | |#echo "1" > /proc/sys/net/ipv4/ip_dynaddr | | | | | |# Specify your Static IP address here. | |# | |# If you have a DYNAMIC IP address, you need to make this ruleset understand | |# your IP address everytime you get a new IP. To do this, enable the | |# following one-line script. (Please note that the different single and | |# double quote characters MATTER). | |# | |# | |# DHCP (Cablemodem and DSL) and PPP users: | |# ---------------------------------------- | |# If you get your TCP/IP address a dynamic IP address **you will need ** to | |# enable the #ed out command below underneath the PPP section AND replace the word | |# "ppp0" with the name of your EXTERNAL Internet connection (eth0, eth1, | |# etc). | |# | |# DHCP and PPP users: The remote DHCP or PPP server can and will change | |# IP addresses on you over time. To deal with this, users should configure | |# their DHCP or PPP client to re-run the rc.firewall-* ruleset everytime | |# the IP address is changed. Please see the "masq-and-dyn-addr" FAQ entry | |# in the IPMASQ howto for full details on how to do this. | |# | |# | |# PPP and DHCP Users: | |# ------------------- | |# Remove the # on the line below and place a # in front of the line after that. | |# | |#ppp_ip="`/sbin/ifconfig ppp0 | grep 'inet addr' | awk '{print $2}' | sed -e 's/.*://'`" | |# | |ppp_ip="your.static.PPP.address" | | | | | |# MASQ timeouts | |# | |# 2 hrs timeout for TCP session timeouts | |# 10 sec timeout for traffic after the TCP/IP "FIN" packet is received | |# 60 sec timeout for UDP traffic (MASQ'ed ICQ users must enable a 30sec | |# firewall timeout in ICQ itself) | |# | |/sbin/ipfwadm -M -s 7200 10 60 | | | | | |############################################################################# | |# Incoming, flush and set default policy of reject. Actually the default policy | |# is irrelevant because there is a catch all rule with deny and log. | |# | |/sbin/ipfwadm -I -f | |/sbin/ipfwadm -I -p reject | | | |# local interface, local machines, going anywhere is valid | |# | |/sbin/ipfwadm -I -a accept -V 192.168.0.1 -S 192.168.0.0/24 -D 0.0.0.0/0 | | | |# remote interface, claiming to be local machines, IP spoofing, get lost | |# | |/sbin/ipfwadm -I -a reject -V $ppp_ip -S 192.168.0.0/24 -D 0.0.0.0/0 -o | | | | | |# remote interface, any source, going to the MASQ servers IP address is valid | |# | |# ENABLE this line if you want ALL Internet traffic to connect to your | |# the various servers running on the MASQ server. This includes | |# web servers, ssh servers, dns servers, etc. | |# | |# I DON'T recommend you enable this rule. Instead, only enable specific | |# access to select server ports under the "OPTIONAL INPUT Section". | |# An example of enabling HTTP (WWW) has been given below: | |# | |# | |#/sbin/ipfwadm -I -a accept -V $ppp_ip -S 0.0.0.0/0 -D $ppp_ip/32 | | | | | |# loopback interface is valid. | |# | |/sbin/ipfwadm -I -a accept -V 127.0.0.1 -S 0.0.0.0/0 -D 0.0.0.0/0 | | | | | |# catch all rule, all other incoming is denied and logged. pity there is no | |# log option on the policy but this does the job instead. | |# | |/sbin/ipfwadm -I -a reject -S 0.0.0.0/0 -D 0.0.0.0/0 -o | | | | | |############################################################################# | |# Outgoing, flush and set default policy of reject. Actually the default policy | |# is irrelevant because there is a catch all rule with deny and log. | |# | |/sbin/ipfwadm -O -f | |/sbin/ipfwadm -O -p reject | | | |# local interface, MASQ server source going to the local net is valid | |# | |/sbin/ipfwadm -O -a accept -V 192.168.0.1 -S 0.0.0.0/0 -D 192.168.0.0/24 | | | |# outgoing to local net on remote interface, stuffed routing, deny | |# | |/sbin/ipfwadm -O -a reject -V $ppp_ip -S 0.0.0.0/0 -D 192.168.0.0/24 -o | | | |# outgoing from local net on remote interface, stuffed masquerading, deny | |# | |/sbin/ipfwadm -O -a reject -V $ppp_ip -S 192.168.0.0/24 -D 0.0.0.0/0 -o | | | |# outgoing from local net on remote interface, stuffed masquerading, deny | |# | |/sbin/ipfwadm -O -a reject -V $ppp_ip -S 0.0.0.0/0 -D 192.168.0.0/24 -o | | | |# anything else outgoing on remote interface is valid | |# | |/sbin/ipfwadm -O -a accept -V $ppp_ip -S $ppp_ip/32 -D 0.0.0.0/0 | | | |# loopback interface is valid. | |# | |/sbin/ipfwadm -O -a accept -V 127.0.0.1 -S 0.0.0.0/0 -D 0.0.0.0/0 | | | |# catch all rule, all other outgoing is denied and logged. pity there is no | |# log option on the policy but this does the job instead. | |# | |/sbin/ipfwadm -O -a reject -S 0.0.0.0/0 -D 0.0.0.0/0 -o | | | | | |############################################################################# | |# Forwarding, flush and set default policy of deny. Actually the default policy | |# is irrelevant because there is a catch all rule with deny and log. | |# | |/sbin/ipfwadm -F -f | |/sbin/ipfwadm -F -p reject | | | |# Masquerade from local net on local interface to anywhere. | |# | |/sbin/ipfwadm -F -a masquerade -W ppp0 -S 192.168.0.0/24 -D 0.0.0.0/0 | |# | |# catch all rule, all other forwarding is denied and logged. Pity there is no | |# log option on the policy but this does the job instead. | |# | |/sbin/ipfwadm -F -a reject -S 0.0.0.0/0 -D 0.0.0.0/0 -o | | | |#End of file. | +-----------------------------------------------------------------------------------------+ To automatically start this stronger firewall ruleset at the proper time, please see the end of the Section 3.4.3 section for full details. Please make sure you make the correct "rc.firewall-ipfwadm" to "rc.firewall-ipfwadm-stronger" substitutions!! With IPFWADM, you can block traffic to a particular site using the -I, -O or -F rules. Remember that the set of rules are scanned top to bottom and "-a" tells IPFWADM to "append" this new rule to the existing set of rules. So with this in mind, any specific restrictions need to come before global rules. For example: Using -I (input ) rules: Probably the fastest and most efficient method to block traffic but it only stops the MASQed machines, and NOT the the firewall machine itself. Of course, you might want to allow that combination. Anyway, to block 204.50.10.13: In the /etc/rc.d/rc.firewall-ipfwadm-stronger ruleset: ... start of -I rules ... # reject and log local interface, local machines going to 204.50.10.13 # /sbin/ipfwadm -I -a reject -V 192.168.0.1 -S 192.168.0.0/24 -D 204.50.10.13/ 32 -o # local interface, local machines, going anywhere is valid # /sbin/ ipfwadm -I -a accept -V 192.168.0.1 -S 192.168.0.0/24 -D 0.0.0.0/0 ... end of -I rules ... Using -O (output) rules: This is the slower method to block traffic because the packets go through masquerading first before they are dropped. Yet, this rule even stops the firewall machine from accessing the forbidden site. ... start of -O rules ... # reject and log outgoing to 204.50.10.13 # /sbin/ ipfwadm -O -a reject -V $ppp_ip -S $ppp_ip/32 -D 204.50.10.13/32 -o # anything else outgoing on remote interface is valid # /sbin/ipfwadm -O -a accept -V $ppp_ip -S $ppp_ip/32 -D 0.0.0.0/0 ... end of -O rules ... Using -F (forward) rules: Probably slower than -I (input) rules for blocking traffic, this still only stops masqueraded machines (e.g. internal machines). The firewall machine can still reach forbidden site(s). ... start of -F rules ... # Reject and log from local net on PPP interface to 204.50.10.13. # /sbin/ipfwadm -F -a reject -W ppp0 -S 192.168.0.0/24 -D 204.50.10.13/32 -o # Masquerade from local net on local interface to anywhere. # /sbin/ipfwadm -F -a masquerade -W ppp0 -S 192.168.0.0/24 -D 0.0.0.0/0 ... end of -F rules ... There is no need for a special rule to allow machines on the 192.168.0.0/24 network to go to 204.50.11.0. Why? It is already covered by the global MASQ rule. NOTE: There is more than one way of coding the interfaces in the above rules. For example instead of "-V 192.168.255.1" you can code "-W eth0", instead of "-V $ppp_ip" , you can use "-W ppp0". The "-V" method was phased out with the imgration to IPCHAINS, but for IPFWADM users, its more of a personal choice and documentation. ----------------------------------------------------------------------------- 6.5. IP Masquerading multiple internal networks Masquerading more than one internal network is fairly simple. You need to first make sure that all of your networks are running correctly (both internal and external). You then need to enable traffic to pass to both the other internal interfaces and to be MASQed to the Internet. Next, you need to enable Masquerading on the INTERNAL interfaces. This example uses a total of THREE interfaces: EXTIF stands for the eth0 interface which is the EXTERNAL connection to the Internet. INTIF stands for the eth1 interface and is the 192.168.0.0 network. Finally, INTIF2 stands for the eth2 interface and is the 192.168.1.0 network. Both INTIF and INTIF2 will be MASQed out of interface eth0 or EXTIF. In your rc.firewall-* ruleset next to the existing MASQ at the very end of the ruleset, add the following: ----------------------------------------------------------------------------- 6.5.1. iptables support for multiple internal lans   * +-----------------------------------------------------------------------------------+ |# 2.6.x and 2.4.x kernels with IPTABLES | |# | |# The following rules build upon the rc.firewall-iptables-stronger ruleset. | |# Please see that ruleset in Section 6 for how all variables get set, etc. | | | | | | #Enable internal interfaces to communication between each other | | # | | $IPTABLES -A FORWARD -i $EXTIF -o $INTIF2 -m state --state ESTABLISHED,RELATED \ | | -j ACCEPT | | $IPTABLES -A FORWARD -i $INTIF -o $INTIF2 -m state --state ESTABLISHED,RELATED \ | | -j ACCEPT | | $IPTABLES -A FORWARD -i $INTIF2 -o $INTIF -m state --state ESTABLISHED,RELATED \ | | -j ACCEPT | | | | $IPTABLES -t nat -A POSTROUTING -o $EXTIF -j SNAT --to $EXTIP | | | +-----------------------------------------------------------------------------------+ ----------------------------------------------------------------------------- 6.5.2. ipchains support for multiple internal lans   * +----------------------------------------------------------------------------+ |# 2.2.x kernels with IPCHAINS | |# | |# The following rules build upon the rc.firewall-ipchains-stronger ruleset. | |# Please see that ruleset in Section 6 for how all variables get set, etc. | | | | #Enable internal interfaces to communication between each other | | $IPCHAINS -A forward -i eth1 -d 192.168.0.0/24 -j ACCEPT | | $IPCHAINS -A forward -i eth2 -d 192.168.1.0/24 -j ACCEPT | | | | #Enable internal interfaces to MASQ out to the Internet | | $IPCHAINS -A forward -j MASQ -i eth0 -s 192.168.0.0/24 -d 0.0.0.0/0 | | $IPCHAINS -A forward -j MASQ -i eth0 -s 192.168.1.0/24 -d 0.0.0.0/0 | | | +----------------------------------------------------------------------------+ ----------------------------------------------------------------------------- 6.5.3. ipfwadm support for multiple internal lans   * +---------------------------------------------------------------------------+ |# 2.0.x kernels with IPFWADM | |# | |# The following rules build upon the rc.firewall-ipfwadm-stronger ruleset. | |# Please see that ruleset in Section 6 for how all variables get set, etc. | | | | #Enable internal interfaces to communication between each other | | /sbin/ipfwadm -F -a accept -V 192.168.0.1 -D 192.168.1.0/24 | | /sbin/ipfwadm -F -a accept -V 192.168.1.1 -D 192.168.0.0/24 | | | | #Enable internal interfaces to MASQ out to the Internet | | /sbin/ipfwadm -F -a masq -W eth0 -S 192.168.0.0/24 -D 0.0.0.0/0 | | /sbin/ipfwadm -F -a masq -W eth0 -S 192.168.1.0/24 -D 0.0.0.0/0 | | | +---------------------------------------------------------------------------+ Please note that it is CORRECT to have "eth0" specified multiple times for the exmples shown above. The reason for this is the Linux kernel needs to know which interface is used for OUTGOING traffic. Since eth0 in the above examples is the Internet connection, it is listed for each internal interface. ----------------------------------------------------------------------------- 6.6. IP Masquerade and Dial-on-Demand Connections 1. If you would like to setup your network to automatically dial up the Internet, either the Diald demand dial-up or new versions of the PPPd packages will be of great utility. Both Diald and PPPd are very powerful in their configuration flexibility. 2. To setup PPPd for Dial-on-Demand, pease check out the [http:// www.samba.org/ppp/index.html] PPPd Homepage 3. To setup Diald, please check out the [http://diald.sourceforge.net/] Diald Homepage or [http://www.ecst.csuchico.edu/~dranch/LINUX/ index-linux.html#TrinityOS] TrinityOS - Section 23 4. Once Dial on Demand and IP Masq have been setup properly, any MASQed client machines that initiate a web, telnet or ftp session will make the Linux box dynamically bring up its Internet link. 5. There is a timeout that will occur with the first connection. This is inevitable if you are using analog modems. The time taken to establish the modem link and the PPP connections may cause your client program (WWW browser, etc.) to stop. This isn't common though. If this does happen, just retry that Internet traffic request (say a WWW page) again and it should come up fine. You can also try setting echo "1" > /proc/sys/net/ ipv4/ip_dynaddr kernel option to help with this initial setup. ----------------------------------------------------------------------------- 6.7. Port Forwarding with IPTABLES or external tools like IPPORTFW, IPMASQADM, IPAUTOFW, REDIR, UDPRED, and other Port Forwarding tools IPTABLES as well as IPPORTFW, IPAUTOFW, REDIR, UDPRED, and other programs offer generic TCP and/or UDP port forwarding for Linux IP Masquerade. These tools are typically used with or as a replacement for specific IP MASQ modules to get a specific network traffic through the MASQ server. With port forwarders, you can redirect data connections from the Internet to an internal, privately addressed machine behind your IP MASQ server. This forwarding ability includes network protocols such as TELNET, WWW, and SMTP. Protocols such as FTP, legacy ICQ, and others require special handling via kernel modules (see below). NOTE: If you are just looking to do simple port forwarding but you don't need Masquerading support, you don't have any choice. You will STILL NEED to enable IP Masquerading support in the kernel AND either run a IPTABLES, IPCHAINS, or IPFWADM ruleset to be able to use Linux's port forwarding tools. So why all the different choices? IPTABLES, IPPORTFW, MARK (MFW), IPMASQADM (PORTFW or AUTOFW), IPAUTOFW, REDIR, and UDPRED (all URLs are in Section 3.2.3) are the various tools available to IP MASQ users to allow this type of functionality depending on their kernel version. Later, as the Linux IP Masquerade feature matured, many of these tools were eventually replaced by the IPTABLES or PORTFW and MARK systems which are far more intelligent solutions. For the later 2.2.x kernels, the IPMASQADM tool combined the legacy IPAUTOFW and IPPORTFW 2.0.x kernel tools into one binary. Both the IPMASQADM tool for 2.2.x kernels as well as IPTABLES for the 2.6.x and 2.4.x kernels also supports a new mechanism called "MARK" or MFW for PORTFW functionality. The MARK system works where a specific IPTABLES or IPCHAINS ruleset would match a given packet sequence. Once matched, the tool would "mark" these packets. Later, the IPMASQADM tool or a specific IPTABLE "table" could be instructed to change these packets as needed and forward them off to their desired internal destination. Currently, this HOWTO doesn't cover the MARK solution but it will in the future. Anyway, because of the availablity of the newer tools, it is *HIGHLY DISCOURAGED* to use the old tools such as IPAUTOFW (even AUTOFW in IPMASQADM) and REDIR because they don't properly notify the Linux kernel of their presence and can ultimately CRASH your Linux server with extreme use. NOTE #2: With enabling PORTFW functionality in ANY 2.2/2.0 Linux kernel (2.6.x. and 2.4.x users won't use these specific tools anyway), internal machines typically CANNOT use the same "external" PORTFWed IP address to access a given internal" machine. To put it another way, PORTFW was only intended to be used with "external" computers on the Internet. If this is an issue for you, you can also use the REDIR tool for older 2.2.x and 2.0.x kernels to let internal machines get redirected to the internal servers too. 2.6.x and 2.4.x kernels users running IPTABLES solves this issue once and for all and is fully covered in a FAQ entry in Section 7.19 below. If you would like a technical explination on why this internal/external forwarding doesn't work, please page down towards the bottom of the 2.2.x PORTFW section for a note from Juan Jose Ciarlante. NOTE #3: The forwarding of non-NAT friendly traffic such as FTP server traffic to an internal MASQed FTP server, known as PORTFW FTP, is now fully supported in the 2.6.x and 2.4.x kernels as well as in the 2.2.x kernels via a BETA version FTP kernel module (does NOT come with the stock Linus kernels). It should also be noted that you can also PORTFW FTP traffic using an external FTP proxy program (not covered in this HOWTO). It should be noted that the Beta 2.2.x FTP kernel module code is still experimental and some people get better results simply using ACTIVE FTP sessions compared to PASSIVE connections. Interestingly enough, other people have seen the exact opposite behavior. Please let us know what your results are like. More about this is covered below in both the 2.2.x and 2.0.x sections as the solutions require the use of different patches. WARNING! Before jumping right into installing ANY of these tools, it needs to be mentioned that network security can be an issue with ANY PORT FORWARD tool. The reason for this is because these tools basically create a hole in strong packet firewalls for the required TCP/UDP ports. Though this doesn't pose any threat to your Linux machine, it might be an issue to the PORTFW'ed internal machine(s). No worries though, this is what Steven Clarke (the author of IPPORTFW) had to say about that: +---------------------------------------------------------------------------------+ | "Port Forwarding is only called within masquerading functions so it | | fits inside the same IPFWADM/IPCHAINS rules. Masquerading is an extension to | | IP forwarding. Therefore, ipportfw only sees a packet if it fits | | both the input and masquerading ipfwadm rule sets." | +---------------------------------------------------------------------------------+ What that means in English is that if you have a strong packet firewall running, PORTFW doesn't directly bypass any of that security. You will still be able to allow or deny specific IPs and/or domains to this new PORTFW'ed resource if you so wish. With this said, it's important to have a strong firewall ruleset. Please see Section 6.4.1, Section 6.4.2, and Section 6.4.3 for more details on getting strong rulesets.   * 2.6.x and 2.4.x kernels have PORTFW functional already built in using the IPTABLES tool. 2.2.x and 2.0.x kernel kernel users will need to re-compile the Linux kernel to support PORTFW. It should be noted that some Linux distribution kernels might have this already done for you.   * The latest 2.2.x kernel users will already have the PORTFW kernel option available to them though you might still need to recompile the kernel via the normal kernel "make" procedures.   * 2.0.x users will need to apply a simple kernel option patch to have access to then enable this via the normal kernel "make" procedures. ----------------------------------------------------------------------------- 6.7.1. IPTABLES-based PORTFWD'ing: Using IPTABLES's PREROUTING option for 2.6.x and 2.4.x kernels As mentioned before, a port forward or "PORTFW" allows a single or range of TCP/IP ports from the external side of the network to be forwarded into the inside network. Unlike ALL previous Linux kernels, the 2.6.x and 2.4.x series kernels now allows for full PORTFW, PORTFW FTP, and PORTFW REDIR functionality within the "iptables" tool itself. NOTE: Once you enable a port forwarder on say port 80 (forward WWW traffic through the MASQ server to an internal WWW server), that port will no longer be used by the Linux IP Masquerade server itself. To be more specific, if you have a WWW server already running on the MASQ server, enabling PORTFW will now give all Internet users acces to the WWW pages from the -INTERNAL- WWW server and not the pages on your IP MASQ server. To enable port forwarding on an IPTABLES (2.6.x or 2.4.x kernel):   * Edit the /etc/rc.d/rc.firewall-iptables ruleset and place the lines shown below just ABOVE the "FWD: Allow all connections OUT and only existing and related ones IN" line (in the "Optional FORWARD section"). Please be sure to replace the word "$EXTIP" with your specific Internet IP address.   * NOTE: Unlike the 2.2.x and 2.0.x kernels, PORTFWed traffic does *not* traverse the INPUT or OUTPUT rules. It only traverses the FORWARD rule.   * NOTE: If you get a dynamically assigned TCP/IP address from your ISP (PPP, DSL, Cablemodems, etc.), you CANNOT load this strong ruleset upon booting. You will either need to reload this firewall ruleset EVERY TIME you get a new IP address or make your /etc/rc.d/ rc.firewall-ipchains-stronger ruleset more intelligent. To do this for various types of connections such as PPP or DHCP users, please see the Section 7.8 FAQ entry for all the details. /etc/rc.d/rc.firewall-* +-----------------------------------------------------------------------------+ |#echo "Enabling PORTFW Redirection on the external LAN.." | |# | |# This will forward ALL port 80 traffic from the external IP address | |# to port 80 on the 192.168.0.10 machine | |# | |# Be SURE that when you add these new rules to your rc.firewall-*, you | |# add them before a direct or implict DROP or REJECT. | |# | |PORTFWIP="192.168.0.10" | | | | | |# NOTE: If you are using the basic rc.firewall-iptables ruleset, you | |# will need to enable the following EXTIP option. Users of the | |# rc.firewall-iptables-stronger ruleset already have this defined. | |# | |# *PLEASE* look over the rc.firewall-iptables-stronger ruleset for more | |# specific issues regarding dynamic vs. static IP addresses | |# | |# | |# Determine the external IP automatically: | |# ---------------------------------------- | |# | |# The following line will determine your external IP address. This | |# line is somewhat complex and confusing but it will also work for | |# all NON-English Linux distributions: | |# | |# DISABLED by default -- to enable, REMOVE both the "#" characters below | |# | |#EXTIP="`$IFCONFIG $EXTIF | $AWK \ | |#/$EXTIF/'{next}//{split($0,a,":");split(a[2],a," ");print a[1];exit}'`" | | | | | |# Allow forwarding of new and existing port 80 connections from the external | |# interface. This rule is required as our default FORWARD policy is DENY. | |# | |$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -p tcp --dport 80 -m state \ | | --state NEW,ESTABLISHED,RELATED -j ACCEPT | | | | | |#Enable PORTFW of this port 80 traffic from the external interface | |# | |$IPTABLES -A PREROUTING -t nat -p tcp -d $EXTIP --dport 80 -m state \ | | --state NEW,ESTABLISHED,RELATED -j DNAT --to $PORTFWIP:80 | +-----------------------------------------------------------------------------+ That's it! Just re-run your /etc/rc.d/rc.firewall-iptables ruleset and test it out! If you would like to learn more about this, please see the Section 7.19 -------------------------------------------------------------------------- Running the rc.firewall-iptables-stronger ruleset? Good for you! To get PORTFW running with this ruleset, it's very easy. The following example is for HTTP (WWW) traffic to be PORTFWed to the IP address indicated by the $PORTFWIP variable:   * Take the ruleset lines shown above (for the generic rc.firewall-* ruleset) and place them just *after* the "#FORWARD Enable Forwarding and thus IPMASQ" comment lines. It should also be noted that you DO NOT have to enable the "HTTPD" rules under the "Optional 'INPUT' section" for 2.4-based kernels. With 2.4 kernels, those lines are ONLY used if you want to allow HTTP traffic to terminate on the MASQ server's own local httpd process (usually Apache). PORTFW FTP: If you have the "ip_conntrack_ftp" and "ip_nat_ftp" kernel modules loaded into kernel space (as already done in the rc.firewall-iptables script), the simple PREROUTING command like the one shown above changed for for port "21" should do the trick. This is much easier than the configuration for the older IPCHAINS / IPFWADM tools for the 2.2.x / 2.0.x kernels! Please note, if you setup PORTFW to redirect traffic to an internal FTP server that is running on a NON-standard FTP port, say port 8021 instead of the usual port 21, you MUST tell the "ip_conntrack_ftp" module to be aware of the new FTP port. The reason for this configuration change is that FTP is not a NAT-friendly protocol. By telling the FTP NAT module about this non-standard FTP port, the NAT module and do it's job again. To enable this, edit your rc.firewall-* file and change the loading of the FTP module to look something like this: +---------------------------------------------------------------------------+ |/sbin/insmod ip_conntrack_ftp ports=21,8021 | +---------------------------------------------------------------------------+ PORTFW Redirection of Internal requests: In the past, if users PORTFWed port 80 on their EXTERNAL IP address to some internal machine, only the machines out on the Internet would be able to properly reach this internal WWW server. If you tried to contact this internal WWW server via the MASQ server's EXTERNAL address, it would fail. Fortunately, there are workarounds for all Linux kernels. IPTABLES for the 2.6.x and 2.4.x kernels supports this functionality natively. IPCHAINS support for the 2.2.x kernels and IPFWADM support for the 2.0.x kernels need to use the external REDIR tool (not currently covered in the HOWTO). For those of you who understand IPTABLES fairly well, the rule of thumb is a PREROUTING/DNAT rule is for enabling PORTFW from *external* machines and a POSTROUTING/SNAT rule is for enabling PORTFW from *internal* machines. To support redirection like this from an internal host, add a rule like the one shown below ABOVE the "Catch all" FORWARDing rule in the rc.firewall-* file. The following example will REDIRECT all external as well as internal WWW traffic to the internal machine noted as PORTFWIP (192.168.0.10). This traffic will have the source IP address of the IP Masq server's internal IP address. Please change the IP address of the PORTFWIP variable to reflect your specific configuration: +---------------------------------------------------------------------------+ |#The following rule should be configured in *addition* to the above rule | |# for enabling external to internal PORTFWing | | | |$IPTABLES -t nat -A POSTROUTING -d $PORTFWIP -s $INTLAN -p tcp \ | |--dport 80 -m state --state NEW,ESTABLISHED,RELATED -j SNAT \ | |--to $INTIP | +---------------------------------------------------------------------------+ ----------------------------------------------------------------------------- 6.7.2. IPMASQADM-based PORTFWD'ing: Using IPMASQADM with 2.2.x kernels First, make sure you have the newest 2.2.x kernel uncompressed into /usr/src/ kernel/linux. If you haven't already done this, please see Section 3.2.2 section for full details. Next, download the "ipmasqadm.c" program from Section 2.7 into the /usr/src/kernel directory. Next, you'll need to compile the 2.2.x kernel as shown in Section 3.2.2 section. Be sure to say "YES" to the IPPORTFW option when you configure the kernel. Once the kernel compile is complete and you have rebooted, return to this section. Now, compile and install the IPMASQADM tool: +---------------------------------------------------------------------------+ | cd /usr/src | | tar xzvf ipmasqadm-x.tgz | | cd ipmasqadm-x | | make | | make install | +---------------------------------------------------------------------------+ Now, for this example, we are going to allow ALL WWW Internet traffic (port 80) hitting your Internet TCP/IP address to be forwarded to the internal Masqueraded machine at IP address 192.168.0.10. PORTFW FTP: As mentioned above, there are two solutions for forwarding FTP server traffic to an internal MASQed PC. The first solution *IS* a BETA level IP_MASQ_FTP module for 2.2.x kernels to PORT Forward FTP connections to an internal MASQed FTP server. The other method is using a FTP proxy program (the URL is in Section 2.7. It should also be noted that the FTP kernel module also supports the adding of additional PORTFW FTP ports on the fly without the requirement of unloading and reloading the IP_MASQ_FTP module and thus breaking any existing FTP transfers. You can find more about this new code at the IPMASQ WWW site at [http://ipmasq.webhop.net] http:// ipmasq.webhop.net;. There are also examples and some additional information about PORTFWed FTP connection below in the 2.0.x. kernel section. NOTE: Once you enable a port forwarder on port 80, that port can no longer be used by the Linux IP Masquerade server. To be more specific, if you have a WWW server already running on the MASQ server, a port forward will now give all Internet users the WWW pages from the -INTERNAL- WWW server and not the pages on your IP MASQ server. Anyway, to enable port forwarding for HTTPd:   * Edit the /etc/rc.d/rc.firewall-* ruleset and ENABLE the "Optional" "HTTP" sections in both the INPUT and OUTPUT subsections.   * Add the following lines shown below JUST BELOW the "ipchains -P forward DENY" rule (in the "Optional FORWARD section"). Be sure to replace the "$EXTIP" variable's contents with your EXTERNAL Internet IP address on the IPMASQ server. NOTE #2: If you get a dynamically assigned TCP/IP address from your ISP (PPP, DSL, Cablemodems, etc.), you CANNOT load this strong ruleset upon booting. You will either need to reload this firewall ruleset EVERY TIME you get a new IP address or make your /etc/rc.d/rc.firewall-ipchains-stronger ruleset more intelligent. To do this for various types of connections such as PPP or DHCP users, please see the Section 7.8 FAQ entry for all the details. /etc/rc.d/rc.firewall-* +---------------------------------------------------------------------------+ |#echo "Enabling IPPORTFW Redirection on the external LAN.." | |# | |# This will forward ALL port 80 traffic from the external IP address | |# to port 80 on the 192.168.0.10 machine | |# | |PORTFWIP="192.168.0.10" | | | |/usr/sbin/ipmasqadm portfw -f | |/usr/sbin/ipmasqadm portfw -a -P tcp -L $EXTIP 80 -R $PORTFWIP 80 | +---------------------------------------------------------------------------+ That's it! Just re-run your /etc/rc.d/rc.firewall-* ruleset and test it out! If you get the error message "ipchains: setsockopt failed: Protocol not available", you AREN'T running your new IPPORTFW enabled kernel. Make sure that you moved the new kernel over, re-run LILO, and then reboot again. If you are sure you are running your new kernel, run the command "ls /proc/net/ ip_masq" and make sure the "portfw" file exists. If it doesn't, you must have made an error when configuring your kernel. Try again. PORTFW Redirection of Internal requests: It should be mention that this IPMASQ HOWTO currently does *NOT* provide any explination or examples on how to use the REDIR tool. If you need help setting it up for 2.2.x kernels, send me an email. For those who want to understand why PORTFW cannot redirect traffic for both external and internal interfaces (what the REDIR tool fixes), here is an email from Juanjo that better explains it. From Juanjo Ciarlante -- >If I use: > > ipmasqadm portfw -a -P tcp -L 1.2.3.4 80 -R 192.168.2.3 80 > >Everything works great from the outside but internal requests for the same >1.2.3.4 address fail. Are there chains that will allow a machine on localnet >192.168.2.0 to accesss www.periapt.com without using a proxy? Actually not. I usually setup a ipmasqadm rule for outside, *AND* a port redirector for inside. This works because ipmasqadm hooks before redir will get the eventual outside connection, _but_ leaves things ok if not (stated by APPROPIATE rules). The actual "conceptual" problem comes from the TRUE client (peer) IP goal (thanks to masq) being in the same net as target server. The failing scenario for "local masq" is : client: 192.168.2.100 masq: 192.168.2.1 serv: 192.168.2.10 1)client->server packet a) client: 192.168.2.100:1025 -> 192.168.2.1:80 [SYN] b) (masq): 192.168.2.100:1025 -> 192.168.2.10:80 [SYN] (and keep 192.168.2.1:61000 192.168.2.100:1025 related) c) serv: gets masqed packet (1b) 2)server->client packet a) serv: 192.168.2.10:80 -> 192.168.2.100:1025 [SYN,ACK] b) client: 192.168.2.100:1025 -> 192.168.2.10:80 [RST] Now take a moment to compare (1a) with (2a). You see, the server replied DIRECTLY to client bypassing masq (not letting masq to UNDO the packet hacking) because it is in SAME net, so the client resets the connection. hope I helped. Warm regards Juanjo ----------------------------------------------------------------------------- 6.7.3. IPPORTFW-based PORTFWD'ing: Using IPPORTFW on 2.0.x kernels First, make sure you have the newest 2.0.x kernel uncompressed into /usr/src/ kernel. If you haven't already done this, please see Section 3.2.3 for full details. Next, download the "ipportfw.c" program and the "subs-patch-x.gz" kernel patch from Section 3.2.3 into the /usr/src/ directory. NOTE: Please replace the "x" in the "subs-patch-x.gz" file name with the most current version available on the site. Next, if you plan on port forwarding FTP traffic to an internal server, you will have to apply an additional NEW IP_MASQ_FTP module patch found in Section 3.2.3. More details regarding this are later in this section. Please note that this is NOT the same patch as for the 2.2.x kernels so some functionality such as the dynamic FTP PORT functionality is not present. Now, copy the IPPORTFW patch (subs-patch-x.gz) into the Linux directory +---------------------------------------------------------------------------+ | cp /usr/src/subs-patch-1.37.gz /usr/src/linux | +---------------------------------------------------------------------------+ Next, apply the kernel patch to create the IPPORTFW kernel option: +---------------------------------------------------------------------------+ | cd /usr/src/linux | | zcat subs-patch-1.3x.gz | patch -p1 | +---------------------------------------------------------------------------+ Ok, time to compile the kernel as shown in Section 3.2.3. Be sure to say YES to the IPPORTFW option now available when you configure the kernel. Once the compile is complete and you have rebooted, return to this section. Now with a newly compiled kernel, please compile and install the actual "IPPORTFW" program +---------------------------------------------------------------------------+ | cd /usr/src | | gcc ipportfw.c -o ipportfw | | mv ipportfw /usr/local/sbin | +---------------------------------------------------------------------------+ Now, for this example, we are going to allow ALL WWW Internet traffic (port 80) hitting your Internet TCP/IP address to then be forwarded to the internal Masqueraded machine at IP address 192.168.0.10. NOTE: Once you enable a port forwarder on port 80, that port can no longer be used by the Linux IP Masquerade server. To be more specific, if you have a WWW server already running on the MASQ server and then you port forward port 80 to an internal MASQed computer, ALL internet users will see the WWW pages pages from the -INTERNAL- WWW server and not the pages on your IP MASQ server. This only performs a port forward to some other port, say 8080, to your internal MASQ machine. Though this will work, all Internet users will have to append :8080 to the URL to then contact the internal MASQed WWW server. Anyway, to enable port forwarding, edit the /etc/rc.d/rc.firewall-* ruleset. Add the follow lines but be sure to replace the word "$extip" with your Internet IP address. NOTE #2: If you get a dynamically assigned TCP/IP address from your ISP (PPP, DSL, Cablemodems, etc.), you CANNOT load this strong ruleset upon booting. You will either need to reload this firewall ruleset EVERY TIME you get a new IP address or make your /etc/rc.d/rc.firewall-ipchains-stronger ruleset more intelligent. To do this for various types of connections such as PPP or DHCP users, please see the Section 7.8 FAQ entry for all the details. /etc/rc.d/rc.firewall-* +---------------------------------------------------------------------------+ |#echo "Enabling IPPORTFW Redirection on the external LAN.." | |# | |# This will forward ALL port 80 traffic from the external IP address | |# to port 80 on the 192.168.0.10 machine | |# | |/usr/local/sbin/ipportfw -C | |/usr/local/sbin/ipportfw -A -t$extip/80 -R 192.168.0.10/80 | +---------------------------------------------------------------------------+ That's it! Just re-run your /etc/rc.d/rc.firewall-* ruleset and test it out! If you get the error message "ipfwadm: setsockopt failed: Protocol not available", you AREN'T running your new kernel. Make sure that you moved the new kernel over, re-run LILO, and then reboot again. Port Forwarding FTP servers: If you plan on port forwarding FTP to an internal machine, things get more complicated. The reason for this is because the standard IP_MASQ_FTP kernel module wasn't written for this though some users report that it works without any problems. Personally, without the patch, I've heard that extended file transfers in excess of 30 minutes will fail without the patch while other users swear that it works flawlessly. Anyway, I recommend that you try the following PORTFW instruction with the STOCK ip_masq_ftp module and see if it works for you. If it doesn't, try using the modified ip_masq_ftp module. For those who need the module, Fred Viles wrote a modified IP_MASQ_FTP module to make things work. If you are curious what EXACTLY are the issues, download the following archive since Fred documents it quite well. Also understand that this patch is somewhat experimental and should be treated as such. It should be noted that this patch is ONLY available for the 2.0.x kernels though there is a different patch available for 2.2.x kernels. So, to get the 2.0.x patch working, you need to:   * FIRST, apply the IPPORTFW kernel patch as shown earlier in this section.   * Download the "msqsrv-patch-36" from Fred Viles's FTP server in Section 3.2.3and put it into /usr/src/linux.   * Patch the kernel with this new code by running "cat msqsrv-patch-36 | patch -p1"   * Next, replace the original "ip_masq_ftp.c" kernel module with the new one mv /usr/src/linux/net/ipv4/ip_masq_ftp.c /usr/src/linux/net/ipv4/ ip_masq_ftp.c.orig mv /usr/src/linux/ip_masq_ftp.c /usr/src/linux/net/ipv4/ip_masq_ftp.c   * Lastly, build and install the kernel with this new code in place. Once this is complete, edit the /etc/rc.d/rc.firewall-* ruleset and add the following lines, but be sure to replace the word "$extip" with your Internet IP address. This example, like the one above, will allow ALL FTP Internet traffic (port 21) hitting your Internet TCP/IP address to then be forwarded to the internal Masqueraded machine at IP address 192.168.0.10. NOTE: Once you enable a port forwarder on port 21, that port can no longer be used by the Linux IP Masquerade server. To be more specific, if you have an FTP server already running on the MASQ server, a port forward will now give all Internet users the FTP files from the -INTERNAL- FTP server and not the files on your IP MASQ server. /etc/rc.d/rc.firewall-* +---------------------------------------------------------------------------+ |#echo "Enabling IPPORTFW Redirection on the external LAN.." | |# | |/usr/local/sbin/ipportfw -C | |/usr/local/sbin/ipportfw -A -t$extip/21 -R 192.168.0.10/21 | | | |#NOTE: If you are using multiple local port numbers to PORTFW | |# to multuple internal FTP servers (say, 21, 2121, 2112, | |# etc, you need to configure the ip_masq_ftp nodule to | |# listen to these ports. To do this, edit the | |# /etc/rc.d/rc.firewall-* script as shown in this HOWTO | |# to look like: | |# | |# /sbin/modprobe ip_masq_ftp ports=21,2121,2112 | |# | |# Re-run the /etc/rc.d/rc.firewall-* script for these changes to | |# take effect. | | | | | |#Please note that PORTFWing port 20 is probably NOT required | |# for ACTIVE connections as the internal FTP server will | |# initiate this port 20 connection and it will be properly | |# handled by the classic MASQ mechanisms. | +---------------------------------------------------------------------------+ That's it! Just re-run your /etc/rc.d/rc.firewall-* ruleset and test it out! PORTFW Redirection of Internal requests: It's not clear if the REDIR tool will compile or work against legacy 2.0.x kernels. It should also be mentioned that this IPMASQ HOWTO currently does * NOT* provide any explination or examples on how to use the REDIR tool. If you need help setting it up, send me an email. If you would like to learn more about REDIR, please see the above section for the 2.2.x kernels. ----------------------------------------------------------------------------- 6.8. CU-SeeMe and Linux IP-Masquerade Linux IP Masquerade supports CuSeeme via the "ip_masq_cuseeme" kernel module. This kernel modules should be loaded in the /etc/rc.d/rc.firewall-* script. Once the "ip_masq_cuseeme" module is installed, you should be able to both initiate and receive CuSeeme connections to remote reflectors and/or users. NOTE: It is recommended to use the IPPORTFW tool instead of the old IPAUTOFW tool for running CuSeeme. If you need more explicit information on configuring CuSeeme, see Michael Owings's CuSeeMe page for a Mini-HOWTO or The IP Masquerade Resources for a mirror of the Mini-HOWTO. ----------------------------------------------------------------------------- 6.9. Mirabilis ICQ ICQ, the instant messaging client now owned by AOL, has changed over the years. All modern ICQ clients are NAT friendly and thus DON'T require any special NAT modules, PORTFW tricks, etc. IF, for some reason, you want to run an OLD ICQ client, you can read this section. If not, just IGNORE all this info. I am leaving this in the HOWTO demonstrate large a LARGE PORTFW example. There are three methods of getting ICQ to work behind a Linux MASQ server. These solutions include the use the ICQ Masq module (for 2.2.x and 2.0.x kernels), using IPPORTFW for basic ICQ functionality, or setting up a SOCKS proxy server. MODULE: The ICQ module was written for the older generation of ICQ clients for both the 2.2.x and 2.0.x kernels. This module allows for the simple setup of multiple ICQ users behind a MASQ server. It also doesn't require any special changes to the ICQ client(s). Recently, AOL changed the protocol and ports used for ICQ. Because of this, many users might find that the ip_masq_icq module will no longer help them. For users of the older ICQ clients, the 2.2.x version of the module supports file transfer and read-time chat. The 2.0.x kernel module doesn't support file transfers and there is no module available for the 2.4.x kernels. PORTFW: Your next option is to use port forwarding. With port forwarding, basic ICQ chat will work but file transfers might not be very reliable. Please see below for an example of how to configure ICQ PORTFW. SOCKS: Finally, your last and possibly best option is to setup a SOCKS proxy server on your Linux machine. This service can happily co-exist with the MASQ service and ICQ should be fully functional regardless of what Linux kernel version you are running. The use of a SOCKS server will require ALL ICQ clients to be reconfigured to use it and the installation and configuration of a SOCKS server has nothing to do with IP Masquerade. Because of this, SOCKS is not covered in this HOWTO. If you are interested in Andrew Deryabin's [mailto:djsf@usa.net] djsf@usa.net ICQ IP Masq module for the 2.2.x and 2.0.x kernels, please see Section 2.7 for details. To use port forwarding (PORFW)for ICQ, you will have to make some changes on both Linux and ICQ clients but all ICQ messaging, URLs, chat, and some file transfers should work.   * First, you need to be running a Linux kernel with IPPPORTFW enabled. Please see Section 6.7for more details.   * Next, you need to add the following lines to your /etc/rc.d/rc.firewall-* file. This example assumes that 10.1.2.3 is your external Internet IP address and your internal MASQed ICQ machine is 192.168.0.10:   * The following example is for a 2.2.x kernel with IPCHAINS: I have included two examples here for the user: Either one would work fine: Example #1 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2000 -R 192.168.0.10 2000 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2001 -R 192.168.0.10 2001 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2002 -R 192.168.0.10 2002 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2003 -R 192.168.0.10 2003 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2004 -R 192.168.0.10 2004 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2005 -R 192.168.0.10 2005 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2006 -R 192.168.0.10 2006 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2007 -R 192.168.0.10 2007 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2008 -R 192.168.0.10 2008 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2009 -R 192.168.0.10 2009 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2010 -R 192.168.0.10 2010 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2011 -R 192.168.0.10 2011 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2012 -R 192.168.0.10 2012 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2013 -R 192.168.0.10 2013 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2014 -R 192.168.0.10 2014 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2015 -R 192.168.0.10 2015 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2016 -R 192.168.0.10 2016 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2017 -R 192.168.0.10 2017 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2018 -R 192.168.0.10 2018 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2019 -R 192.168.0.10 2019 /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2020 -R 192.168.0.10 2020 Example #2 port=2000 while [ $port -le 2020 ] do /usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 $port -R 192.168.0.10 $port port=$((port+1)) done   * The following example is for a 2.0.x kernel with IPFWADM: I have included two examples here for the user: Either one would work fine: Example #1 /usr/local/sbin/ipportfw -A -t10.1.2.3/2000 -R 192.168.0.10/2000 /usr/local/sbin/ipportfw -A -t10.1.2.3/2001 -R 192.168.0.10/2001 /usr/local/sbin/ipportfw -A -t10.1.2.3/2002 -R 192.168.0.10/2002 /usr/local/sbin/ipportfw -A -t10.1.2.3/2003 -R 192.168.0.10/2003 /usr/local/sbin/ipportfw -A -t10.1.2.3/2004 -R 192.168.0.10/2004 /usr/local/sbin/ipportfw -A -t10.1.2.3/2005 -R 192.168.0.10/2005 /usr/local/sbin/ipportfw -A -t10.1.2.3/2006 -R 192.168.0.10/2006 /usr/local/sbin/ipportfw -A -t10.1.2.3/2007 -R 192.168.0.10/2007 /usr/local/sbin/ipportfw -A -t10.1.2.3/2008 -R 192.168.0.10/2008 /usr/local/sbin/ipportfw -A -t10.1.2.3/2009 -R 192.168.0.10/2009 /usr/local/sbin/ipportfw -A -t10.1.2.3/2010 -R 192.168.0.10/2010 /usr/local/sbin/ipportfw -A -t10.1.2.3/2011 -R 192.168.0.10/2011 /usr/local/sbin/ipportfw -A -t10.1.2.3/2012 -R 192.168.0.10/2012 /usr/local/sbin/ipportfw -A -t10.1.2.3/2013 -R 192.168.0.10/2013 /usr/local/sbin/ipportfw -A -t10.1.2.3/2014 -R 192.168.0.10/2014 /usr/local/sbin/ipportfw -A -t10.1.2.3/2015 -R 192.168.0.10/2015 /usr/local/sbin/ipportfw -A -t10.1.2.3/2016 -R 192.168.0.10/2016 /usr/local/sbin/ipportfw -A -t10.1.2.3/2017 -R 192.168.0.10/2017 /usr/local/sbin/ipportfw -A -t10.1.2.3/2018 -R 192.168.0.10/2018 /usr/local/sbin/ipportfw -A -t10.1.2.3/2019 -R 192.168.0.10/2019 /usr/local/sbin/ipportfw -A -t10.1.2.3/2020 -R 192.168.0.10/2020 Example #2 port=2000 while [ $port -le 2020 ] do /usr/local/sbin/ipportfw -A t10.1.2.3/$port -R 192.168.0.10/$port port=$((port+1)) done   * Once your new rc.firewall-* is ready, reload the ruleset to make sure things are OK by simply typing in "/etc/rc.d/rc.firewall-*". If you get any errors, you either don't have IPPORTFW support in the kernel or you made a typo in the rc.firewall file.   * Now, in ICQ's Preferences-->Connection, configure it to be "Behind a LAN" and "Behind a firewall or Proxy". Now, click on "Firewall Settings" and configure it to be "I don't use a SOCK5 proxy". Also note that it was previously recommended to change ICQ's "Firewall session timeouts" to "30" seconds BUT many users have found that ICQ becomes unreliable. It has been found that ICQ is more reliable with its stock timeout setting (don't enable that ICQ option) and simply change MASQ's timeout to 160 seconds. You can see how to change this timeout in Section 3.4.3 and Section 3.4.2 rulesets. Finally, click on Next and configure ICQ to "Use the following TCP listen ports.." from "2000" to "2020". Now click done. Now ICQ will tell you that you will have to restart ICQ for the changes to take effect. To be honest, I had to REBOOT the Windows9x machine in order for things to work right but some users might say otherwise. So.. try it both ways.   * A user once told me that by simply portforwarding port 4000 to his ICQ machine, it worked perfectly. He reported that EVERYTHING worked fine (even chat, file transfers, etc) WITHOUT re-configuring ICQ from its default settings. Your mileage might vary on this topic but I thought you might like to hear about this alternative configuration. ----------------------------------------------------------------------------- 6.10. Gamers: The LooseUDP patch The LooseUDP patch allows semi-NAT-friendly games that usually use UDP connections to both WORK behind a Linux IP Masquerade server. What the LooseUDP patch does is allow ALL UDP packets to be NATed through the MASQ box without any checks or expiration. This liberal forwarding method is considered insecure by many and is disabled in modern 2.2.x kernels. The 2.4.x kernels with it's IPTABLES stateful UDP inspection only allows incoming UDP packets into the machine (and thus MASQ) if there was already an outbound UDP packet to that same host in it's stateful table. If the MASQ host hasn't sent a UDP packet to the remote host within ~30 seconds, the return UDP table entry is deleted. Because of this, IPTABLES removes most of the need for the LooseUDP patch as it does it in a more secure fashion. Currently, LooseUDP is available as a patch for 2.0.36+ kernels and it is already built into 2.2.3+ kernels though it is now DISABLED by DEFAULT in 2.2.16+ (please see the example rc.firewal ruleset comments for details). To get LooseUDP running on a 2.0.x kernel, follow the following steps:   * Have the newest 2.0.x kernel sources uncompressed in the /usr/src/linux directory   * ABSOLUTELY REQUIRED for v2.0.x: Download and install the IPPORTFW patch from Section 3.2.3and as described in Section 6.7of the HOWTO.   * Download the LooseUDP patch from Section 3.2.3 Now, put the LooseUDP patch in the /usr/src/linux directory. Once this is done, type in: +------------------------------------------------------------------------+ |For a compressed patch file: zcat loose-udp-2.0.36.patch.gz | patch -p1| +------------------------------------------------------------------------+ +------------------------------------------------------------------------+ |For a NON-compressed patch file: cat loose-udp-2.0.36.patch | patch -p1| +------------------------------------------------------------------------+ Now, depending on the version of your "patch", You will then see the following text: +---------------------------------------------------------------+ |patching file `CREDITS' | |patching file `Documentation/Configure.help' | |patching file `include/net/ip_masq.h' | |patching file `net/ipv4/Config.in' | |patching file `net/ipv4/ip_masq.c' | +---------------------------------------------------------------+   * If you see the text "Hunk FAILED" only ONCE and ONLY ONCE at the very beginning of the patching, don't be alarmed. You probably have an old patch file (this has been fixed) but it still works. If it fails completely, make sure you have applied the IPPORTFW kernel patch FIRST. Once the patch is installed, re-configure the kernel as shown in Section 3.2.3 and be sure to say "Y" to the "IP: loose UDP port managing (EXPERIMENTAL) (CONFIG_IP_MASQ_LOOSE_UDP) [Y/n/?]" option. To get LooseUDP running on a 2.2.x kernel, follow the following steps:   * In the /etc/rc.d/rc.firewall-* script, goto the BOTTOM of the file and find the LooseUDP section. Change the "0" in the line: echo "0" > /proc/ sys/net/ipv4/ip_masq_udp_dloose to a "1" and re-run the rc.firewall-* ruleset. An example of this is given in both Section 3.4.2 example and Section 6.4.3 example. NOTE: The LooseUDP code is /not/ available (?required?) for the 2.4.x kernels   * See the begining of this section for all the details. Basically, the old 2.0.x / 2.2.x LooseUDP code was considered a security issue. Because of this, it was removed from the kernel. Fortunately, some games that used to require the LooseUDP code on the 2.2.x IPCHAINS system might work just final under the 2.4.x IPTABLES kernels. If the games don't work, I'm not aware of a solution for you. Sorry. Once you are running the new LooseUDP enabled kernel, you should be good to go for most NAT-friendly games. Some URLs have been given for patches to make games like BattleZone and others NAT friendly. Please see Section 6.3.1 for more details. ----------------------------------------------------------------------------- Chapter 7. Frequently Asked Questions If you can think of any useful FAQ suggestions, please send it to [mailto: dranch@trinnet.net] dranch@trinnet.net. Please clearly state the question and an appropriate answer (if you have it). Thank you! ----------------------------------------------------------------------------- 7.1. ( Distro ) - What Linux Distributions support IP Masquerading? If your Linux distribution doesn't support IP MASQ out of the box, don't worry. All you have to do is to re-compile the kernel as shown above in this HOWTO. NOTE: If you can help us fill out this table, please email [mailto: dranch@trinnet.net] dranch@trinnet.net.   * Caldera < v1.2 : NO - ?   * Caldera v1.3 : YES - 2.0.35 based   * Caldera v2.2 : YES - 2.2.5 based   * Caldera eServer v2.3 : YES - ? based   * Debian v1.3 : NO - ?   * Debian v2.0 : NO - ?   * Debian v2.1 : YES - 2.2.1 based   * Debian v2.2 : YES - 2.2.15 based   * Debian v3.0 : YES - 2.4.18 based   * DLX Linux v? : ? - ?   * DOS Linux v? : ? - ?   * FloppyFW v1.0.2 : ? - ?   * Gentoo v1.4 : YES - ? Based   * Hal91 Linux v? : ? - ?   * Linux PPC vR4 : NO - ?   * Linux Pro v? : ? - ?   * LinuxWare v? : ? - ?   * Mandrake v5.3 : YES - ?   * Mandrake v6.0 : YES - 2.2.5   * Mandrake v6.1 : YES - ?   * Mandrake v7.0 : YES - 2.2.14   * Mandrake v7.1 : YES - 2.2.15   * Mandrake v7.2 : YES - 2.2.17   * Mandrake v8.0 : YES - ?   * Mandrake v8.1 : YES - 2.4.8   * Mandrake v8.2 : YES - ?   * Mandrake v9.0 : YES - ?   * Mandrake v9.1 : YES - 2.4.21-pre   * MkLinux v? : ? - ?   * MuLinux v3rl : YES - ?   * Redhat < v4.x : NO - ?   * Redhat v5.0 : YES - ?   * Redhat v5.1 : YES - 2.0.34 based   * Redhat v5.2 : YES - 2.0.36 based   * Redhat v6.0 : YES - 2.2.5 based   * Redhat v6.1 : YES - 2.2.12 based   * Redhat v6.2 : YES - 2.2.14 based   * Redhat v7.0 : YES - 2.2.16 based   * Redhat v7.2 : YES - 2.4.7 based   * Redhat v7.3 : YES - 2.4.? based   * Redhat v8.0 : YES - 2.4.18? based   * Redhat v9.0 : YES - 2.4.20 based   * Slackware v3.0 : ? - ?   * Slackware v3.1 : ? - ?   * Slackware v3.2 : ? - ?   * Slackware v3.3 : ? - 2.0.34 based   * Slackware v3.4 : ? - ?   * Slackware v3.5 : ? - ?   * Slackware v3.6 : ? - ?   * Slackware v3.9 : ? - 2.0.37pre10 based   * Slackware v4.0 : YES - 2.2.6 based   * Slackware v7.0 : YES - 2.2.13 based   * Slackware v7.1 : YES - 2.2.16 based   * Slackware v8.0 : YES - 2.4.17 based   * Slackware v8.1 : YES - ? based   * Stampede Linux v? : ? - ?   * SuSE v5.2 : YES - 2.0.32 base   * SuSE v5.3 : YES - ?   * SuSE v6.0 : YES - 2.0.36 based   * SuSE v6.1 : YES - 2.2.5 based   * SuSE v6.3 : YES - 2.2.13 based   * Tomsrbt Linux v? : ? - ?   * TurboLinux Lite v4.0 : YES - ?   * TurboLinux v6.0 : YES - 2.2.12 based   * TriLinux v? : ? - ?   * Yggdrasil Linux v? : ? - ? ----------------------------------------------------------------------------- 7.2. ( Requirements ) - What are the minimum hardware requirements and any limitations for IP Masquerade? How well does it perform? A 486/66 box with 16MB of RAM was more than sufficient to fill a 1.54Mb/s T1 100%! MASQ has also been known to run quite well on 386SX-16s with 8MB of RAM. Yet, it should be noted that Linux IP Masquerade starts thrashing the system with more than 500 MASQ entries. The only application that I know which can temporarily break Linux IP Masquerade, is GameSpy. Why? When it refreshes its lists, it creates 10,000s of quick connections in a VERY short period of time. Until these sessions timeout, the MASQ tables become "FULL". See Section 7.23 of the FAQ for more details. While we are at it: There is a hard limit of 4096 concurrent connections each for TCP & UDP. This limit can be changed by fiddling the values in /usr/src/linux/net/ipv4/ ip_masq.h - a maximum limit of 32000 should by OK. If you want to change the limit - you need