mzito
asked on
IP Masquerade/TCP-IP Problem
Okay, here's the scoop. I have a redhat 5.0 box (2.0.32) with the Following Vital stats-
-Pentium 90
-16 Megs of RAM
-290 Meg Hard Drive
-Two NE2000 cards
-2meg Cirrus PCI graphics card
I had Masquerade working with Slackware 96, but then my hard drive died and I figured I'd reinstall everything from scratch with Redhat 5. Using the exact same network configuration, ip masquerading does not work.
I have a cable modem, with ip address 24.2.80.* (last digit obscured to protect the innocent).
My private network is on the 192.168.2.* subnet, with my linux box having 192.168.2.1.
The command "cat /proc/sys/net/ipv4/ip_masq
My ipfwadm commands are as follows (I'm using the default kernel, but that comes with masq support built-in)-
ipfwadm -If
ipfwadm -Of
ipfwadm -Ff
ipfwadm -Ip accept
ipfwadm -Op accept
ipfwadm -Fp deny
ipfwadn -F -a m -S 192.168.2.0/24 -D 0.0.0.0/0
I've also tried ipfwadm -F -a masquerade -S 192.168.2.0/24 -D 0.0.0.0/0, but that doesn't work either. My win95 box has a proper IP address, has 192.168.2.1 set as the gateway, and can ping the Linux box with no problem. My routing tables are as follows.
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0 * 255.255.255.0 U 0 0 0 eth1
loopback * 255.0.0.0 U 0 0 1 lo
default 24.2.80.1 255.255.255.0 UG 0 0 0 eth0
24.2.80.0 * 255.255.255.0 U 0 0 0 eth0
(it's right after a reboot)
From the Linux box, I can ping any box on either side of the network, but I can't ping my router (24.2.80.1) from the internal network. I don't know if ICMP masquerading is enabled, so I tried to also do name server lookups and http requests from my internal machine to home.netscape.com and my school's web server. Nothing.
I went and got tcpdump and installed it, then watched some sessions between my Linux box and the win95 machine (i.e. tcpdump -i eth1). When it tried to ping the router, I just got a whole string of "ICMP Echo Request"s to the router from the win95. But on the other side (tcpdump -i eth0), there was no masqueraded Echo Requests being sent.
Then I tried telnetting to my Linux box from my win95 box. IT just simply didn't work. So, I tcpdumped the output of an attempted telnet session, and saw that my win95 box sent out four packets with a destination ip address of my Linux box, and my Linux box never sent a single packet. My tcp_wrappers script allows telnet requests in, and my ipfwadm policies allow incoming packets.
Then I wasn't sure if tcpdump would show my outgoing packets from the Linux box. So I tried telnetting from the Linux box to the win95 (I know the win95 machine doesn't have a telnet server. I just wanted to see what would happen) and tcpdumped the output. It showed my Linux box sending a packet, the win95 box responding, etc., etc. but my Linux box never came back with "Connection Refused". It just timed out. Hoping it was a win95 problem, I reinstalled the win95 networking drivers, but that didn't work either. Then I tried setting my Linux box's Window and MSS sizes to the same as those sent by the win95 box when it tried to telnet to my machine (Window 8192 MSS 1500). No luck. Does anyone have any clue what it is? I thinki I've tried everything. If it's a win95 problem, can anyone tell me how to fix it? Ditto for Linux. Thank you all very much in advance.
Best Wishes,
Matthew Zito
-Pentium 90
-16 Megs of RAM
-290 Meg Hard Drive
-Two NE2000 cards
-2meg Cirrus PCI graphics card
I had Masquerade working with Slackware 96, but then my hard drive died and I figured I'd reinstall everything from scratch with Redhat 5. Using the exact same network configuration, ip masquerading does not work.
I have a cable modem, with ip address 24.2.80.* (last digit obscured to protect the innocent).
My private network is on the 192.168.2.* subnet, with my linux box having 192.168.2.1.
The command "cat /proc/sys/net/ipv4/ip_masq
My ipfwadm commands are as follows (I'm using the default kernel, but that comes with masq support built-in)-
ipfwadm -If
ipfwadm -Of
ipfwadm -Ff
ipfwadm -Ip accept
ipfwadm -Op accept
ipfwadm -Fp deny
ipfwadn -F -a m -S 192.168.2.0/24 -D 0.0.0.0/0
I've also tried ipfwadm -F -a masquerade -S 192.168.2.0/24 -D 0.0.0.0/0, but that doesn't work either. My win95 box has a proper IP address, has 192.168.2.1 set as the gateway, and can ping the Linux box with no problem. My routing tables are as follows.
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0 * 255.255.255.0 U 0 0 0 eth1
loopback * 255.0.0.0 U 0 0 1 lo
default 24.2.80.1 255.255.255.0 UG 0 0 0 eth0
24.2.80.0 * 255.255.255.0 U 0 0 0 eth0
(it's right after a reboot)
From the Linux box, I can ping any box on either side of the network, but I can't ping my router (24.2.80.1) from the internal network. I don't know if ICMP masquerading is enabled, so I tried to also do name server lookups and http requests from my internal machine to home.netscape.com and my school's web server. Nothing.
I went and got tcpdump and installed it, then watched some sessions between my Linux box and the win95 machine (i.e. tcpdump -i eth1). When it tried to ping the router, I just got a whole string of "ICMP Echo Request"s to the router from the win95. But on the other side (tcpdump -i eth0), there was no masqueraded Echo Requests being sent.
Then I tried telnetting to my Linux box from my win95 box. IT just simply didn't work. So, I tcpdumped the output of an attempted telnet session, and saw that my win95 box sent out four packets with a destination ip address of my Linux box, and my Linux box never sent a single packet. My tcp_wrappers script allows telnet requests in, and my ipfwadm policies allow incoming packets.
Then I wasn't sure if tcpdump would show my outgoing packets from the Linux box. So I tried telnetting from the Linux box to the win95 (I know the win95 machine doesn't have a telnet server. I just wanted to see what would happen) and tcpdumped the output. It showed my Linux box sending a packet, the win95 box responding, etc., etc. but my Linux box never came back with "Connection Refused". It just timed out. Hoping it was a win95 problem, I reinstalled the win95 networking drivers, but that didn't work either. Then I tried setting my Linux box's Window and MSS sizes to the same as those sent by the win95 box when it tried to telnet to my machine (Window 8192 MSS 1500). No luck. Does anyone have any clue what it is? I thinki I've tried everything. If it's a win95 problem, can anyone tell me how to fix it? Ditto for Linux. Thank you all very much in advance.
Best Wishes,
Matthew Zito
ASKER
Sorry, that didn't help. I appreciate the response, though. Oh, I mistyped something above. I meant to put: "cat /proc/sys/net/ipv4/ip_forw
ASKER
Adjusted points to 220
Try this, download program called dotfile-2.1b1
that program is graphical (X11) interface to ipfwadm (generates firewall scripts)
Much easier and faster to create all kind of masq/firewall scripts.
Download it, it is great!!!
1 -rw-r--r-- 882.1K 1997 Sep 18 ftp.imada.ou.dk /pub/dotfile/dotfile-2.1b1
2 -r--r--r-- 882.1K 1997 Dec 1 ftp.ula.ve /pub/unix/utilities/dotfil
3 -r--r--r-- 899.3K 1997 Nov 9 ftp.jyu.fi /.2/redhat/pub/contrib/SRP
4 -rw-r--r-- 899.3K 1997 Nov 10 ftp.pht.com /.3/redhat/contrib/SRPMS/d
5 -rw-r--r-- 899.3K 1997 Nov 10 ftp.chg.ru /.5/Linux/RedHat/contrib/S
6 -rw-r--r-- 899.3K 1997 Nov 10 ftp.eecs.umich.edu /.7/linux/redhat_contrib/S
7 -rw-rw-r-- 899.3K 1997 Nov 10 ftp.pacificorp.com /.mirrors/ftp.redhat.com/pub/contrib/SRPMS/dotfile-2.1b1-1.src.rpm
8 -rw-r--r-- 899.3K 1997 Nov 10 ftp.ms.mff.cuni.cz /MIRRORS/ftp.redhat.com/pub/contrib/SRPMS/dotfile-2.1b1-1.src.rpm
9 -rw-r--r-- 899.3K 1997 Nov 9 ftp.doc.ic.ac.uk /Mirrors/ftp.redhat.com/pub/contrib/SRPMS/dotfile-2.1b1-1.src.rpm
10 -rw-r--r-- 899.3K 1997 Nov 10 ftp.ms.mff.cuni.cz /OS/Linux/Distributions/Re
11 -r--r--r-- 899.3K 1997 Nov 9 ftp.sinica.edu.tw /_Operating_System/linux/r
12 -rw-r--r-- 899.3K 1997 Nov 9 ftp.cc.gatech.edu /ac121/linux/distributions
13 -rw-r--r-- 899.3K 1997 Nov 9 ftp.in-chemnitz.de /afs/pub/linux/redhat-mirr
14 -rw-r--r-- 899.3K 1997 Nov 9 ftp.inp.nsk.su /archives_src/linux/RedHat
15 -rw-r--r-- 899.3K 1997 Nov 10 ftp.sunsite.auc.dk /disk1/ftp.redhat.com/pub/contrib/SRPMS/dotfile-2.1b1-1.src.rpm
16 -rw-r--r-- 899.3K 1997 Nov 10 ftp.ua.pt /disk4/Linux/distributions
17 -rw-r--r-- 899.3K 1997 Nov 10 ftp.dcc.uchile.cl /dsk/d6/redhatcontrib/SRPM
18 -rw-r--r-- 899.3K 1997 Nov 10 sunsite.dcc.uchile.cl /dsk/d6/redhatcontrib/SRPM
19 -r--r--r-- 899.3K 1997 Nov 9 ftp.rydnet.lysator.liu.se /export2/linux/distributio
20 -r--r--r-- 899.3K 1997 Nov 9 ftp.sun.ac.za /linux/contrib/redhat/SRPM
21 -rw-r--r-- 899.3K 1997 Nov 9 ftp.mpi-sb.mpg.de /linux/mirror/ftp.redhat.com/contrib/SRPMS/dotfile-2.1b1-1.src.rpm
22 -rw-r--r-- 899.3K 1997 Nov 10 ftp.uwsg.indiana.edu /linux/redhat/contrib/SRPM
23 -rw-r--r-- 899.3K 1997 Nov 10 ftp.iut-bm.univ-fcomte.fr /mail/redhat-contrib/SRPMS
24 -rw-r--r-- 899.3K 1997 Nov 9 ftp.uni-hohenheim.de /mirror/ftp.redhat.com/pub/contrib/SRPMS/dotfile-2.1b1-1.src.rpm
25 -rw-rw-r-- 899.3K 1997 Nov 9 sunsite.cnlab-switch.ch /mirror/linux/distribution
26 -rw-r--r-- 899.3K 1997 Nov 9 ftp.man.poznan.pl /mirror/redhat-contrib/SRP
27 -rw-r--r-- 899.3K 1997 Nov 9 ftp.man.poznan.pl /mirror1/coast/redhat-cont
28 -rw-r--r-- 899.3K 1997 Nov 10 ftp.flashnet.it /mirror5/sunsite.unc.edu/d
29 -rw-r--r-- 899.3K 1997 Nov 10 ftp.uoknor.edu /mirrors/linux/redhat-cont
30 -rw-r--r-- 899.3K 1997 Nov 10 ftp.lame.org /mirrors/redhat-contrib/SR
31 -r--r--r-- 899.3K 1997 Nov 9 unix.hensa.ac.uk /mirrors/sunsite/pub/Linux
32 -r--r--r-- 899.3K 1997 Nov 9 ftp.informatik.uni-rostock.de /mnt/ftp/ftp02/linux/contr
33 -rw-r--r-- 899.3K 1997 Nov 10 ftp.muni.cz /mount/redhat/contrib/SRPM
34 -r--r--r-- 899.3K 1997 Nov 10 ftp.eu.net /os/Linux/distributions/re
35 -rw-r--r-T 899.3K 1997 Nov 9 ftp.uni-jena.de /pub/.mounts/disk02/linux/
36 -rw-r--r-- 899.3K 1997 Nov 9 ftp.saix.net /pub/Linux/distributions/r
37 -rw-r--r-- 899.3K 1997 Nov 10 ftp.cs.buffalo.edu /pub/Linux/redhat-contrib/
38 -rw-r--r-- 899.3K 1997 Nov 9 ftp.pg.gda.pl /pub/Linux/redhat-contrib/
39 -rwxr-xr-x 899.3K 1997 Nov 10 ftp.ege.edu.tr /pub/Linux/redhat/contrib/
40 -rw-r--r-- 899.3K 1997 Nov 9 ftp.pg.gda.pl /pub/OS/Linux/redhat-contr
41 -rw-r--r-- 899.3K 1997 Nov 9 ftp.pg.gda.pl /pub/OS/linux/redhat-contr
42 -r--r--r-- 899.3K 1997 Nov 9 sunsite.sut.ac.jp /pub/archives/linux/distri
43 -rw-r--r-- 899.3K 1997 Nov 9 ftp.netcraft.com.au /pub/contrib/SRPMS/dotfile
44 -rw-r--r-- 899.3K 1997 Nov 9 ftp.redhat.com /pub/contrib/SRPMS/dotfile
45 -rw-r--r-- 899.3K 1997 Nov 9 ftp.xyz.lublin.pl /pub/helios/distributions/
46 -r--r--r-- 899.3K 1997 Nov 9 ftp.sun.ac.za /pub/linux/contrib/redhat/
47 -rw-r--r-- 899.3K 1997 Nov 9 ftp.med.univ-tours.fr /pub/linux/distributions/r
48 -r--r--r-- 899.3K 1997 Nov 9 boomer.anu.edu.au /pub/linux/distributions/r
49 -r--r--r-- 899.3K 1997 Nov 9 ftp.fri.uni-lj.si /pub/linux/distributions/r
50 -rw-r--r-- 899.3K 1997 Nov 9 ftp.mathematik.tu-darmstadt.de /pub/linux/distributions/r
that program is graphical (X11) interface to ipfwadm (generates firewall scripts)
Much easier and faster to create all kind of masq/firewall scripts.
Download it, it is great!!!
1 -rw-r--r-- 882.1K 1997 Sep 18 ftp.imada.ou.dk /pub/dotfile/dotfile-2.1b1
2 -r--r--r-- 882.1K 1997 Dec 1 ftp.ula.ve /pub/unix/utilities/dotfil
3 -r--r--r-- 899.3K 1997 Nov 9 ftp.jyu.fi /.2/redhat/pub/contrib/SRP
4 -rw-r--r-- 899.3K 1997 Nov 10 ftp.pht.com /.3/redhat/contrib/SRPMS/d
5 -rw-r--r-- 899.3K 1997 Nov 10 ftp.chg.ru /.5/Linux/RedHat/contrib/S
6 -rw-r--r-- 899.3K 1997 Nov 10 ftp.eecs.umich.edu /.7/linux/redhat_contrib/S
7 -rw-rw-r-- 899.3K 1997 Nov 10 ftp.pacificorp.com /.mirrors/ftp.redhat.com/pub/contrib/SRPMS/dotfile-2.1b1-1.src.rpm
8 -rw-r--r-- 899.3K 1997 Nov 10 ftp.ms.mff.cuni.cz /MIRRORS/ftp.redhat.com/pub/contrib/SRPMS/dotfile-2.1b1-1.src.rpm
9 -rw-r--r-- 899.3K 1997 Nov 9 ftp.doc.ic.ac.uk /Mirrors/ftp.redhat.com/pub/contrib/SRPMS/dotfile-2.1b1-1.src.rpm
10 -rw-r--r-- 899.3K 1997 Nov 10 ftp.ms.mff.cuni.cz /OS/Linux/Distributions/Re
11 -r--r--r-- 899.3K 1997 Nov 9 ftp.sinica.edu.tw /_Operating_System/linux/r
12 -rw-r--r-- 899.3K 1997 Nov 9 ftp.cc.gatech.edu /ac121/linux/distributions
13 -rw-r--r-- 899.3K 1997 Nov 9 ftp.in-chemnitz.de /afs/pub/linux/redhat-mirr
14 -rw-r--r-- 899.3K 1997 Nov 9 ftp.inp.nsk.su /archives_src/linux/RedHat
15 -rw-r--r-- 899.3K 1997 Nov 10 ftp.sunsite.auc.dk /disk1/ftp.redhat.com/pub/contrib/SRPMS/dotfile-2.1b1-1.src.rpm
16 -rw-r--r-- 899.3K 1997 Nov 10 ftp.ua.pt /disk4/Linux/distributions
17 -rw-r--r-- 899.3K 1997 Nov 10 ftp.dcc.uchile.cl /dsk/d6/redhatcontrib/SRPM
18 -rw-r--r-- 899.3K 1997 Nov 10 sunsite.dcc.uchile.cl /dsk/d6/redhatcontrib/SRPM
19 -r--r--r-- 899.3K 1997 Nov 9 ftp.rydnet.lysator.liu.se /export2/linux/distributio
20 -r--r--r-- 899.3K 1997 Nov 9 ftp.sun.ac.za /linux/contrib/redhat/SRPM
21 -rw-r--r-- 899.3K 1997 Nov 9 ftp.mpi-sb.mpg.de /linux/mirror/ftp.redhat.com/contrib/SRPMS/dotfile-2.1b1-1.src.rpm
22 -rw-r--r-- 899.3K 1997 Nov 10 ftp.uwsg.indiana.edu /linux/redhat/contrib/SRPM
23 -rw-r--r-- 899.3K 1997 Nov 10 ftp.iut-bm.univ-fcomte.fr /mail/redhat-contrib/SRPMS
24 -rw-r--r-- 899.3K 1997 Nov 9 ftp.uni-hohenheim.de /mirror/ftp.redhat.com/pub/contrib/SRPMS/dotfile-2.1b1-1.src.rpm
25 -rw-rw-r-- 899.3K 1997 Nov 9 sunsite.cnlab-switch.ch /mirror/linux/distribution
26 -rw-r--r-- 899.3K 1997 Nov 9 ftp.man.poznan.pl /mirror/redhat-contrib/SRP
27 -rw-r--r-- 899.3K 1997 Nov 9 ftp.man.poznan.pl /mirror1/coast/redhat-cont
28 -rw-r--r-- 899.3K 1997 Nov 10 ftp.flashnet.it /mirror5/sunsite.unc.edu/d
29 -rw-r--r-- 899.3K 1997 Nov 10 ftp.uoknor.edu /mirrors/linux/redhat-cont
30 -rw-r--r-- 899.3K 1997 Nov 10 ftp.lame.org /mirrors/redhat-contrib/SR
31 -r--r--r-- 899.3K 1997 Nov 9 unix.hensa.ac.uk /mirrors/sunsite/pub/Linux
32 -r--r--r-- 899.3K 1997 Nov 9 ftp.informatik.uni-rostock.de /mnt/ftp/ftp02/linux/contr
33 -rw-r--r-- 899.3K 1997 Nov 10 ftp.muni.cz /mount/redhat/contrib/SRPM
34 -r--r--r-- 899.3K 1997 Nov 10 ftp.eu.net /os/Linux/distributions/re
35 -rw-r--r-T 899.3K 1997 Nov 9 ftp.uni-jena.de /pub/.mounts/disk02/linux/
36 -rw-r--r-- 899.3K 1997 Nov 9 ftp.saix.net /pub/Linux/distributions/r
37 -rw-r--r-- 899.3K 1997 Nov 10 ftp.cs.buffalo.edu /pub/Linux/redhat-contrib/
38 -rw-r--r-- 899.3K 1997 Nov 9 ftp.pg.gda.pl /pub/Linux/redhat-contrib/
39 -rwxr-xr-x 899.3K 1997 Nov 10 ftp.ege.edu.tr /pub/Linux/redhat/contrib/
40 -rw-r--r-- 899.3K 1997 Nov 9 ftp.pg.gda.pl /pub/OS/Linux/redhat-contr
41 -rw-r--r-- 899.3K 1997 Nov 9 ftp.pg.gda.pl /pub/OS/linux/redhat-contr
42 -r--r--r-- 899.3K 1997 Nov 9 sunsite.sut.ac.jp /pub/archives/linux/distri
43 -rw-r--r-- 899.3K 1997 Nov 9 ftp.netcraft.com.au /pub/contrib/SRPMS/dotfile
44 -rw-r--r-- 899.3K 1997 Nov 9 ftp.redhat.com /pub/contrib/SRPMS/dotfile
45 -rw-r--r-- 899.3K 1997 Nov 9 ftp.xyz.lublin.pl /pub/helios/distributions/
46 -r--r--r-- 899.3K 1997 Nov 9 ftp.sun.ac.za /pub/linux/contrib/redhat/
47 -rw-r--r-- 899.3K 1997 Nov 9 ftp.med.univ-tours.fr /pub/linux/distributions/r
48 -r--r--r-- 899.3K 1997 Nov 9 boomer.anu.edu.au /pub/linux/distributions/r
49 -r--r--r-- 899.3K 1997 Nov 9 ftp.fri.uni-lj.si /pub/linux/distributions/r
50 -rw-r--r-- 899.3K 1997 Nov 9 ftp.mathematik.tu-darmstadt.de /pub/linux/distributions/r
I have to assume that your Win95 is on the 24.2.80.0 network.
The problem as I see it is that any packets from network
24.2.80.0 have to be forwarded to network 192.168.2.0
before they can reach gateway 192.168.2.1.
However, your firewall rules do not allow that.
There are two solutions/options:
==> Add a new firewall rule just before the masquerade rule:
accept forwarding of packets from 24.2.80.* destined for 192.168.0.*. (This is what I recommend).
or
==> Enable Bridging which is experimental in 2.0.x. Bridging
will make 24.2.80.* and 192.168.2.* networks appear
like one network, and thus (hopefully) forwarding will not
be required.
Other issues: To the best of my knowledge, 2.0.32 kernel has to be patched for ICMP masquerade,and the patch is available in the redhat distribution. Also, I am not sure if you need the -I and
-O rules; -F should be enough, but of course, you know more about your security requirements. Please remember that firewall rules are applied in the order you enter them, and the first rule which can be completely applied pre-empts evaluation of subsequent rules. Finally, I can not explain why the same configuration worked under Slackware96 -- which I believe comes with kernel 2.0.0 -- perhaps the current kernel is more restrictive (aka more secured); I doubt if the difference in behaviour is due to wrappers or TCP/IP kit.
tks -an.
The problem as I see it is that any packets from network
24.2.80.0 have to be forwarded to network 192.168.2.0
before they can reach gateway 192.168.2.1.
However, your firewall rules do not allow that.
There are two solutions/options:
==> Add a new firewall rule just before the masquerade rule:
accept forwarding of packets from 24.2.80.* destined for 192.168.0.*. (This is what I recommend).
or
==> Enable Bridging which is experimental in 2.0.x. Bridging
will make 24.2.80.* and 192.168.2.* networks appear
like one network, and thus (hopefully) forwarding will not
be required.
Other issues: To the best of my knowledge, 2.0.32 kernel has to be patched for ICMP masquerade,and the patch is available in the redhat distribution. Also, I am not sure if you need the -I and
-O rules; -F should be enough, but of course, you know more about your security requirements. Please remember that firewall rules are applied in the order you enter them, and the first rule which can be completely applied pre-empts evaluation of subsequent rules. Finally, I can not explain why the same configuration worked under Slackware96 -- which I believe comes with kernel 2.0.0 -- perhaps the current kernel is more restrictive (aka more secured); I doubt if the difference in behaviour is due to wrappers or TCP/IP kit.
tks -an.
I have to assume that your Win95 is on the 24.2.80.0 network.
The problem as I see it is that any packets from network
24.2.80.0 have to be forwarded to network 192.168.2.0
before they can reach gateway 192.168.2.1.
However, your firewall rules do not allow that.
There are two solutions/options:
==> Add a new firewall rule just before the masquerade rule:
accept forwarding of packets from 24.2.80.* destined for 192.168.0.*. (This is what I recommend).
or
==> Enable Bridging which is experimental in 2.0.x. Bridging
will make 24.2.80.* and 192.168.2.* networks appear
like one network, and thus (hopefully) forwarding will not
be required.
Other issues: To the best of my knowledge, 2.0.32 kernel has to be patched for ICMP masquerade,and the patch is available in the redhat distribution. Also, I am not sure if you need the -I and
-O rules; -F should be enough, but of course, you know more about your security requirements. Please remember that firewall rules are applied in the order you enter them, and the first rule which can be completely applied pre-empts evaluation of subsequent rules. Finally, I can not explain why the same configuration worked under Slackware96 -- which I believe comes with kernel 2.0.0 -- perhaps the current kernel is more restrictive (aka more secured); I doubt if the difference in behaviour is due to wrappers or TCP/IP kit.
tks -an.
The problem as I see it is that any packets from network
24.2.80.0 have to be forwarded to network 192.168.2.0
before they can reach gateway 192.168.2.1.
However, your firewall rules do not allow that.
There are two solutions/options:
==> Add a new firewall rule just before the masquerade rule:
accept forwarding of packets from 24.2.80.* destined for 192.168.0.*. (This is what I recommend).
or
==> Enable Bridging which is experimental in 2.0.x. Bridging
will make 24.2.80.* and 192.168.2.* networks appear
like one network, and thus (hopefully) forwarding will not
be required.
Other issues: To the best of my knowledge, 2.0.32 kernel has to be patched for ICMP masquerade,and the patch is available in the redhat distribution. Also, I am not sure if you need the -I and
-O rules; -F should be enough, but of course, you know more about your security requirements. Please remember that firewall rules are applied in the order you enter them, and the first rule which can be completely applied pre-empts evaluation of subsequent rules. Finally, I can not explain why the same configuration worked under Slackware96 -- which I believe comes with kernel 2.0.0 -- perhaps the current kernel is more restrictive (aka more secured); I doubt if the difference in behaviour is due to wrappers or TCP/IP kit.
tks -an.
ASKER
Sorry, but again, that does not work. In related information, though, I have the output of two tcpdump sessions, one where my win95 box attempted to telnet to my linux box, and another when my linux box attempted to telnet to my win95 box's email server. As a stopgap measure, I moved the second nic card over to my win95 box and set up a proxy server. I found that my other win95 box could SOCKS proxy out through my win95 proxy, but my Linux box could not. So, I have decided that there must be some problem in the TCP/IP subsystem, and thus I am providing tcpdump output. Anyone tell me what this means?
192.168.1.168= Win95 Machine
192.168.1.1= Linux
(I changed my ip addresses because some kind soul sent me example configuration files using 192.168.1.* ip addresses, so I just made the changes to all the files. Routing, etc., it's all correct,as far as I can tell. Everything can ping everything else, etc.)
Win95 tries to telnet to Linux:
15:47:48.657870 arp who-has 192.168.1.1 tell 192.168.1.168
15:47:48.657870 arp reply 192.168.1.1 is-at 33:40:33:40:c2:ca
15:47:48.657870 192.168.1.168.1091 > 192.168.1.1.telnet: S 1909259:1909259(0) win 8192 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>
15:47:51.947870 192.168.1.168.1091 > 192.168.1.1.telnet: S 1909259:1909259(0) win 8192 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>
15:47:58.537870 192.168.1.168.1091 > 192.168.1.1.telnet: S 1909259:1909259(0) win 8192 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>
15:48:04.527870 0:40:33:3a:b7:da > 3:0:0:0:0:1 sap f0 ui/C len=160
2c00 ffef 0800 0000 0000 0000 5a5a 4449
5354 2020 2020 2020 2020 2000 4d44 5043
2020 2020 2020 2020 2020 2000 ff53 4d42
2500 00
15:48:11.497870 192.168.1.168.1091 > 192.168.1.1.telnet: S 1909259:1909259(0) win 8192 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>
15:48:38.547870 192.168.1.168.netbios-dgm > 192.168.1.255.netbios-dgm:
Linux tries to telnet to win95 SMTP port:
16:09:23.377870 arp who-has 192.168.1.168 tell 192.168.1.1
16:09:23.377870 arp reply 192.168.1.168 is-at 0:80:ad:6:87:c8
16:09:23.377870 192.168.1.1.1028 > 192.168.1.168.smtp: S 3934160335:3934160335(0) win 512 <mss 1460> [tos 0x10]
16:09:23.377870 192.168.1.168.smtp > 192.168.1.1.1028: S 3204041:3204041(0) ack 3934160336 win 8760 <mss 1460> (DF)
16:09:26.377870 192.168.1.1.1028 > 192.168.1.168.smtp: S 3934160335:3934160335(0) win 32120 <mss 1460> [tos 0x10]
16:09:26.377870 192.168.1.168.smtp > 192.168.1.1.1028: . ack 1 win 8760 (DF)
16:09:26.617870 192.168.1.168.smtp > 192.168.1.1.1028: S 3204041:3204041(0) ack 3934160336 win 8760 <mss 1460> (DF)
16:09:32.377870 192.168.1.1.1028 > 192.168.1.168.smtp: S 3934160335:3934160335(0) win 32120 <mss 1460> [tos 0x10]
16:09:32.377870 192.168.1.168.smtp > 192.168.1.1.1028: . ack 1 win 8760(DF)
16:09:33.157870 192.168.1.168.smtp > 192.168.1.1.1028: S 3204041:3204041(0) ack 3934160336 win 8760 <mss 1460> (DF)
16:09:44.377870 192.168.1.1.1028 > 192.168.1.168.smtp: S 3934160335:3934160335(0) win 32120 <mss 1460> [tos 0x10]
16:09:44.377870 192.168.1.168.smtp > 192.168.1.1.1028: . ack 1 win 8760(DF)
16:09:46.217870 192.168.1.168.smtp > 192.168.1.1.1028: S 3204041:3204041(0) ack 3934160336 win 8760 <mss 1460> (DF)
16:10:08.377870 192.168.1.1.1028 > 192.168.1.168.smtp: S 3934160335:3934160335(0) win 32120 <mss 1460> [tos0x10]
16:10:08.377870 192.168.1.168.smtp > 192.168.1.1.1028: . ack 1 win 8760(DF)
16:10:56.377870 192.168.1.1.1028 > 192.168.1.168.smtp: S 3934160335:3934160335(0) win 32120 <mss 1460> [tos 0x10]
16:10:56.377870 192.168.1.168.smtp > 192.168.1.1.1028: S 3297041:3297041(0) ack 3934160336 win 8760 <mss 1460> (DF)
16:10:59.627870 192.168.1.168.smtp > 192.168.1.1.1028: S 3297041:3297041(0) ack 3934160336 win 8760 <mss 1460> (DF)
16:11:06.167870 192.168.1.168.smtp > 192.168.1.1.1028: S 3297041:3297041(0) ack 3934160336 win 8760 <mss 1460> (DF)
16:11:19.227870 192.168.1.168.smtp > 192.168.1.1.1028: S 3297041:3297041(0) ack 3934160336 win 8760 <mss 1460> (DF)
I understand the basics of this (I know what ARP is, etc.) but I don't understand the nitty-gritty. Can anyone tell me what the problem is by looking at this? Thanks in advance, as always.
Matt Zito
192.168.1.168= Win95 Machine
192.168.1.1= Linux
(I changed my ip addresses because some kind soul sent me example configuration files using 192.168.1.* ip addresses, so I just made the changes to all the files. Routing, etc., it's all correct,as far as I can tell. Everything can ping everything else, etc.)
Win95 tries to telnet to Linux:
15:47:48.657870 arp who-has 192.168.1.1 tell 192.168.1.168
15:47:48.657870 arp reply 192.168.1.1 is-at 33:40:33:40:c2:ca
15:47:48.657870 192.168.1.168.1091 > 192.168.1.1.telnet: S 1909259:1909259(0) win 8192 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>
15:47:51.947870 192.168.1.168.1091 > 192.168.1.1.telnet: S 1909259:1909259(0) win 8192 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>
15:47:58.537870 192.168.1.168.1091 > 192.168.1.1.telnet: S 1909259:1909259(0) win 8192 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>
15:48:04.527870 0:40:33:3a:b7:da > 3:0:0:0:0:1 sap f0 ui/C len=160
2c00 ffef 0800 0000 0000 0000 5a5a 4449
5354 2020 2020 2020 2020 2000 4d44 5043
2020 2020 2020 2020 2020 2000 ff53 4d42
2500 00
15:48:11.497870 192.168.1.168.1091 > 192.168.1.1.telnet: S 1909259:1909259(0) win 8192 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]>
15:48:38.547870 192.168.1.168.netbios-dgm > 192.168.1.255.netbios-dgm:
Linux tries to telnet to win95 SMTP port:
16:09:23.377870 arp who-has 192.168.1.168 tell 192.168.1.1
16:09:23.377870 arp reply 192.168.1.168 is-at 0:80:ad:6:87:c8
16:09:23.377870 192.168.1.1.1028 > 192.168.1.168.smtp: S 3934160335:3934160335(0) win 512 <mss 1460> [tos 0x10]
16:09:23.377870 192.168.1.168.smtp > 192.168.1.1.1028: S 3204041:3204041(0) ack 3934160336 win 8760 <mss 1460> (DF)
16:09:26.377870 192.168.1.1.1028 > 192.168.1.168.smtp: S 3934160335:3934160335(0) win 32120 <mss 1460> [tos 0x10]
16:09:26.377870 192.168.1.168.smtp > 192.168.1.1.1028: . ack 1 win 8760 (DF)
16:09:26.617870 192.168.1.168.smtp > 192.168.1.1.1028: S 3204041:3204041(0) ack 3934160336 win 8760 <mss 1460> (DF)
16:09:32.377870 192.168.1.1.1028 > 192.168.1.168.smtp: S 3934160335:3934160335(0) win 32120 <mss 1460> [tos 0x10]
16:09:32.377870 192.168.1.168.smtp > 192.168.1.1.1028: . ack 1 win 8760(DF)
16:09:33.157870 192.168.1.168.smtp > 192.168.1.1.1028: S 3204041:3204041(0) ack 3934160336 win 8760 <mss 1460> (DF)
16:09:44.377870 192.168.1.1.1028 > 192.168.1.168.smtp: S 3934160335:3934160335(0) win 32120 <mss 1460> [tos 0x10]
16:09:44.377870 192.168.1.168.smtp > 192.168.1.1.1028: . ack 1 win 8760(DF)
16:09:46.217870 192.168.1.168.smtp > 192.168.1.1.1028: S 3204041:3204041(0) ack 3934160336 win 8760 <mss 1460> (DF)
16:10:08.377870 192.168.1.1.1028 > 192.168.1.168.smtp: S 3934160335:3934160335(0) win 32120 <mss 1460> [tos0x10]
16:10:08.377870 192.168.1.168.smtp > 192.168.1.1.1028: . ack 1 win 8760(DF)
16:10:56.377870 192.168.1.1.1028 > 192.168.1.168.smtp: S 3934160335:3934160335(0) win 32120 <mss 1460> [tos 0x10]
16:10:56.377870 192.168.1.168.smtp > 192.168.1.1.1028: S 3297041:3297041(0) ack 3934160336 win 8760 <mss 1460> (DF)
16:10:59.627870 192.168.1.168.smtp > 192.168.1.1.1028: S 3297041:3297041(0) ack 3934160336 win 8760 <mss 1460> (DF)
16:11:06.167870 192.168.1.168.smtp > 192.168.1.1.1028: S 3297041:3297041(0) ack 3934160336 win 8760 <mss 1460> (DF)
16:11:19.227870 192.168.1.168.smtp > 192.168.1.1.1028: S 3297041:3297041(0) ack 3934160336 win 8760 <mss 1460> (DF)
I understand the basics of this (I know what ARP is, etc.) but I don't understand the nitty-gritty. Can anyone tell me what the problem is by looking at this? Thanks in advance, as always.
Matt Zito
Are the two network cards on the same subnet or different subnets?
ASKER
Yes, the two network cards are indeed on the same subnet.
Ok, then what I would suggest is to verify that ip forwarding is indeed turned on (/etc/sysconfig/network has the line FORWARD_IPV4=yes) and then try the following lines:
ipfwadm -I -f
ipfwadm -O -f
ipfwadm -F -p deny
ipfwadm -F -a masquerade -W (cable-modem-device ppp0?) -S 192.168.1.0/24 -D 0.0.0.0/0
ipfwadm -F -a deny -S 0.0.0.0/0 -D 0.0.0.0/0 -o
(That last line will log any failed attempts into /var/log/messages) Let me know what happens.
ipfwadm -I -f
ipfwadm -O -f
ipfwadm -F -p deny
ipfwadm -F -a masquerade -W (cable-modem-device ppp0?) -S 192.168.1.0/24 -D 0.0.0.0/0
ipfwadm -F -a deny -S 0.0.0.0/0 -D 0.0.0.0/0 -o
(That last line will log any failed attempts into /var/log/messages) Let me know what happens.
ASKER
If you look above, you can see that I tried those exact lines (barring the -W flag, which is not required anyway) and they did not work. I tried that variation on more than one occasion, though, and it did not help. I'm pretty convinced that its a hardware problem or a TCP/IP problem, not a configuration problem, since I've had at least seven separate people check my configuration and report that there are no problems with it. What I'm looking for now is someone to tell me what that tcpdump output shows. If someone can explain to my satisfaction what it means and what it indicates the problem is, I'll award the points.
Best Wishes,
Matthew Zito
Best Wishes,
Matthew Zito
ASKER
Adjusted points to 260
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I think your genmask in your routing table is wrong. Fwiw, I use /sbin/ipfwadm -F -p deny ; /sbin/ipfwadm -F -a m -S 10.0.0.0/8 -D 0.0.0.0/0
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
potsgw1.tudelft * 255.255.255.255 UH 0 0 0 ppp0
localnet * 255.0.0.0 U 0 0 32 eth0
127.0.0.0 * 255.0.0.0 U 0 0 4 lo
default potsgw1.tudelft 0.0.0.0 UG 0 0 20 ppp0