| |
Next
Previous
Contents
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:
- Step One: Testing local 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
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
- Step Two: Testing internal Linux connectivity
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
- Step Three: Testing External Linux connectivity
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
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
--- 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.
- Step Four: Testing local PC to Linux connectivity
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.
- Step Five: Testing internal MASQ ICMP forwarding
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:
- "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 THREE above.
- "netstat -rn" : Make sure your default gateway (the column one with the 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 that very LAST line that starts with 0.0.0.0? Notice that it has an IP
address in the "Gateway" field? You should an IP address for your specific
setup in that field.
- "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
.
.
- Step Six: Testing external MASQ ICMP forwarding
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.
- Step Seven: Testing MASQ functionality without DNS
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.
- Step Eight: Testing MASQ functionality with DNS
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.
- Step Nine: Testing more MASQ functionality with DNS
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).
- Step Ten: Any remaining functional, performance, etc. issues...
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.
Next
Previous
Contents
|
