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 -10- tests to make sure all aspects of your MASQ setup is running properly:
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 Configuring-clients section 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 --- 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
On the MASQ server itself, ping then internal IP address of the MASQ server's network interface card (i.e. ping 192.168.0.1). 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 --- 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
Next ping the external IP address of the MASQ server's network interface card connected to the Internet. This address might be from a PPP, Ethernet, etc connection to your ISP. If you don't know what this 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:64.220.150.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
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 --- 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 NICs in 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, don't forget to verify the NIC configurations under the Linux distro is correct, etc. per the recommendations in the beginning of this HOWTO.
On a internal MASQed computer, try pinging the IP address of the Masquerading Linux box's internal Ethernet card, (i.e. ping 192.168.0.1). This will prove that your internal network and routing is ok. 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 --- 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 this fails, make sure Ethernet cards of the MASQ server and the MASQed computer have "link". This is usually a LED light on either the back of each Ethernet card and also on the Ethernet hub/switch (if you are using one). If this fails, make sure that the internal MASQ machine is correctly configured as shown in the Configuring-clients section. If the MASQ client is ok, double-check your network cabling, make sure you have a LINK light on both the internal MASQed computer's NIC -and- the internal NIC on the Linux box.
From an internal MASQed computer, ping the IP address of the MASQ server's EXTERNAL TCP/IP address obtained in Step THREE above. This address might be your PPP, Ethernet, etc. address connected to your ISP. This ping test will prove that masquerading is working (ICMP Masquerading specifically).
If it 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:
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
. . 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 . .
From an internal MASQed computer, now ping a static TCP/IP address out on the Internet (i.e. ping 152.19.254.81 (this is http://metalab.unc.edu - home of MetaLabs' Linux Archive). If this works, that means that ICMP Masquerading is working over the Internet. If it didn't work, again check your Internet connection. If this still doesn't work, make sure you are using the simple rc.firewall ruleset and that you have ICMP Masqurading compiled into the Linux kernel. Also, make sure that the ruleset that enable IP MASQ is pointing to the correct EXNTERNAL interface.
Now try TELNETing to a remote IP address (i.e. telnet 152.2.254.81 (metalab.unc.edu - Note that this might take a while to get a login prompt since this is a VERY busy server.) Did you get a login prompt after a while? If that worked, that 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 now. An example of this output might look like (hit Control-D to exit out of the TELNET):
masq-client# telnet 152.2.254.81
Trying 152.2.254.81...
Connected to 152.2.254.81.
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 allows no public telnet logins.
login: Connection closed by foreign host.
Now try TELNETing to a remote HOSTNAME (i.e. "telnet metalab.unc.edu" (152.2.254.81). If this works, this means that DNS is working fine as well. If this didn't work but step SIX did work, make sure that you have valid DNS servers configured on your MASQed computer as shown in the Configuring-clients section.
As a last test, try browsing some 'INTERNET' WWW sites on one of your MASQed machines, and see if you can reach them. For example, access the Linux Documentation Project site. If this works, you can be fairly certain that everything is working FINE! If some sites are having problems where others work just fine, see the next step for more ideas.
If you see The Linux Documentation Project homepage, then CONGRATULATIONS! It's working! If that WWW site comes up correctly, then all other standard network tolls 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! If FTP, IRC, RealAudio, Quake I/II/III, etc. aren't working or are performing poorly, make sure 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 give IP MASQ module).
If your system passes all of these tests above but things like WWW browsing, FTP, and other types of traffic aren't reliable, I recommend that you read the MTU-issues FAQ entry in Section 7. There might be other items in the FAQ section that will help you as they have helped many users in the past.