forwarding, masquerading, firewalling??????

forwarding, masquerading, firewalling??????

Post by Michael Schwage » Mon, 18 Jan 1999 04:00:00



I just finished re-setting up my rh 5.1 system so that eth0 is on my
internal network and eth1 is dhcp-connected through my dsl modem to the
rest of the universe.  I want for the machines on my internal network
(10.10.10.0) to be able to see the internet, obviously.  So far, they
can ping all the way up to both eth0 and eth1 on the linux machine, but
not past that.  I have ip_forwarding turned on in the netcfg dialog and
I have masquerading turned on in the kernel.

Now I don't know what to do.  I think it's something with ipfwadm, but
none of the documentation seems to help.  I just want a fish for now,
not a fishing pole.

thanks
ms

 
 
 

forwarding, masquerading, firewalling??????

Post by Eugen » Mon, 18 Jan 1999 04:00:00


there's a very comprehensive info at www.linux.org/help

>I just finished re-setting up my rh 5.1 system so that eth0 is on my
>internal network and eth1 is dhcp-connected through my dsl modem to the
>rest of the universe.  I want for the machines on my internal network
>(10.10.10.0) to be able to see the internet, obviously.  So far, they
>can ping all the way up to both eth0 and eth1 on the linux machine, but
>not past that.  I have ip_forwarding turned on in the netcfg dialog and
>I have masquerading turned on in the kernel.

>Now I don't know what to do.  I think it's something with ipfwadm, but
>none of the documentation seems to help.  I just want a fish for now,
>not a fishing pole.

>thanks
>ms


 
 
 

forwarding, masquerading, firewalling??????

Post by Luca Filipoz » Mon, 18 Jan 1999 04:00:00




> there's a very comprehensive info at www.linux.org/help


> >I just finished re-setting up my rh 5.1 system so that eth0 is on my
> >internal network and eth1 is dhcp-connected through my dsl modem to the
> >rest of the universe.  I want for the machines on my internal network
> >(10.10.10.0) to be able to see the internet, obviously.  So far, they
> >can ping all the way up to both eth0 and eth1 on the linux machine, but
> >not past that.  I have ip_forwarding turned on in the netcfg dialog and
> >I have masquerading turned on in the kernel.

> >Now I don't know what to do.  I think it's something with ipfwadm, but
> >none of the documentation seems to help.  I just want a fish for now,
> >not a fishing pole.

> >thanks
> >ms

You've set up the kernel to be capable of masquerading but now you have
to tell it exactly what to masquerade. That's where ipfwadm comes in...

ipfwadm -F -a masq -S 10.10.10.0/24 -D 0.0.0.0/0 -W eth1
 -F : forwarding
 -a : action (in this case, masquerade)
 -S : source IP host/network (in this case 10.10.10.0 mask 255.255.255.0)
 -D : destination IP host/network (the world, 0.0.0.0 mask 0.0.0.0)
 -W : the interface that masquerading should be applied to

You should also use ipfwadm to set up your linux box to be a firewall for
your LAN. The act of masquerading means that your internal machines are
hidden from the Internet but it doesn't mean that your linux box is safe.
If someone hacks your linux box, then they can access your internal
network. You should check out the Firewall and Proxy HOWTO at
http://www.linux.org/help/howto.html.

Hope this helps.
--

 
 
 

forwarding, masquerading, firewalling??????

Post by Michael Schwage » Mon, 18 Jan 1999 04:00:00





> > there's a very comprehensive info at www.linux.org/help


> > >I just finished re-setting up my rh 5.1 system so that eth0 is on my
> > >internal network and eth1 is dhcp-connected through my dsl modem to the
> > >rest of the universe.  I want for the machines on my internal network
> > >(10.10.10.0) to be able to see the internet, obviously.  So far, they
> > >can ping all the way up to both eth0 and eth1 on the linux machine, but
> > >not past that.  I have ip_forwarding turned on in the netcfg dialog and
> > >I have masquerading turned on in the kernel.

> > >Now I don't know what to do.  I think it's something with ipfwadm, but
> > >none of the documentation seems to help.  I just want a fish for now,
> > >not a fishing pole.

> > >thanks
> > >ms

> You've set up the kernel to be capable of masquerading but now you have
> to tell it exactly what to masquerade. That's where ipfwadm comes in...

> ipfwadm -F -a masq -S 10.10.10.0/24 -D 0.0.0.0/0 -W eth1
>  -F : forwarding
>  -a : action (in this case, masquerade)
>  -S : source IP host/network (in this case 10.10.10.0 mask 255.255.255.0)
>  -D : destination IP host/network (the world, 0.0.0.0 mask 0.0.0.0)
>  -W : the interface that masquerading should be applied to

> You should also use ipfwadm to set up your linux box to be a firewall for
> your LAN. The act of masquerading means that your internal machines are
> hidden from the Internet but it doesn't mean that your linux box is safe.
> If someone hacks your linux box, then they can access your internal
> network. You should check out the Firewall and Proxy HOWTO at
> http://www.linux.org/help/howto.html.

> Hope this helps.
> --


Thanks for the input on the ipfwadm.  I tried the command you gave, but
it didn't seem to work....  I've checked out the howto, but it doesn't
give anything (that I saw) on masquerading, which is all I'm interested
in now.  How can I check that it's set up correctly? namely,
1. How to verify the kernel is ok with forwarding and masquerading?
2. How to check the forward and masq rules
3. How to test the system.

I tried testing it by pinging to an internet address from my LAN, to no
avail.  I have NT on the LAN set up so my linux box is the default
gateway.  Any suggestions?

thanks
ms

 
 
 

forwarding, masquerading, firewalling??????

Post by Luca Filipoz » Mon, 18 Jan 1999 04:00:00



Quote:> 1. How to verify the kernel is ok with forwarding and masquerading?

Take a look at what's in /proc/net. If you see ip_masquerade, then you
have masquerading built into the kernel. Same for ip_forward. I use
debian linux and these files may be in a different directory under RH.

Quote:> 2. How to check the forward and masq rules

You can see what rules are in effect as follows:
ipfwadm -I -l  # for input rules
ipfwadm -O -l  # for output rules
ipfwadm -F -l  # for forwarding (and masquerading) rules
ipfwadm -A -l  # for accounting rules

Quote:> 3. How to test the system.

> I tried testing it by pinging to an internet address from my LAN, to no
> avail.  I have NT on the LAN set up so my linux box is the default
> gateway.  Any suggestions?

I don't know your level of knowledge so I'm sorry if this is a little
pedantic.

This is what I have and maybe you can see how your setup differs.

#eth0 is on cable modem (24.xxx.yyy.zzz)
#eth1 is on LAN (192.168.1.1)
# deny everything
ipfwadm -I -p deny
ipfwadm -I -f
ipfwadm -O -p deny
ipfwadm -O -f
ipfwadm -F -p deny
ipfwadm -F -f

# permit dhcp traffic so that I can get an IP address allocated by ISP
# permit bootps (dhcp server) traffic into eth0
ipfwadm -I -a accept -S 0.0.0.0/0 bootps -D 0.0.0.0/0 -W eth0 -P udp
# permit bootpc (dhcp client) traffic out of eth0
ipfwadm -O -a accept -S 0.0.0.0/0 bootpc -D 0.0.0.0/0 -W eth0 -P udp

# permit localhost traffic (so ping localhost works)
ipfwadm -I -a accept -S 127.0.0.1/32 -D 127.0.0.1/32
ipfwadm -O -a accept -S 127.0.0.1/32 -D 127.0.0.1/32

# permit LAN traffic into and out of the firewall
ipfwadm -I -a accept -S 192.168.1.0/24 -D 0.0.0.0/0 -W eth1
ipfwadm -O -a accept -S 0.0.0.0/0 -D 192.168.1.0/24 -W eth1

# permit cable modem traffic into and out of the firewall
ipfwadm -I -a accept -S 0.0.0.0/0 -D 24.xxx.yyy.zzz/32 -W eth0
ipfwadm -O -a accept -S 24.xxx.yyy.zzz/32 -D 0.0.0.0/0 -W eth0

# masquerade the LAN
ipfwadm -F -a masquerade -S 192.168.1.0/24 -D 0.0.0.0/0 -W eth0

I don't make use of the -b option, which would simplify my rules. I don't
really have to use -I or -O rules but I may in the future lock things
down more and want placeholders in my firewall script.

Procedure to debug:
From the firewall:
1 - you should be able to ping the localhost
2 - you should be able to ping a host on the internet
3 - you should be able to ping a host on your LAN

From a host on your LAN:
4 - you should be able to ping the firewall
5 - you should be able to ping a host on the internet

If you can't get one of the steps to work, then you need to see where the
packets are getting blocked. To figure this out, you can use tcpdump as
follows:

Let's say that step 5 doesn't work and that the "host on your LAN" has IP
address 192.l68.1.2. On the firewall, run this command:

tcpdump -i eth1 ip proto icmp
or
tcpdump -i eth1 ip proto 1

This will show you all packets received by the firewall on interface eth1
(the LAN-side of the firewall) whose ip protocol type is ICMP (what ping
uses). If you see echo-request packets from 192.168.1.2 then you know
that your internal machine's packets are getting to the firewall. If you
don't see echo-reply packets then you know the ping reply's aren't
coming out of the firewall and getting to your internal machine. What you
don't know is whether its the outgoing echo-request packets that aren't
getting out of the firewall and onto the internet in the first place or
its the returning echo-reply packets that aren't getting back through the
firewall to your internal machine. To find the answer, you need to see
what's happening on eth0 (the internet-side of the firewall). On the
firewall, run this command:

tcpdump -i eth0 ip proto icmp
or
tcpdump -i eth0 ip proto 1

tcpdump has a *LOT* of options that you can specify to allow you to focus
on only those packets which interest you. Check out its manpage.

If you see no echo-request packets, then the firewall isn't allowing them
out of your internal network.

If you see echo-request packets (you will also so echo-reply packets),
then the firewall isn't allowing the replies back into the internal LAN.

There's another wrinkle to this that I haven't mentioned.

Are your routing tables set up correctly? Your internal machines should
have the firewall's eth1 IP address set as their default gateway. You
mention above that this is already the case.

The firewall should have your ISP's router set as its default gateway. If
it doesn't, then your firewall won't know what to do with the echo-
request packets it gets from the internal machine.

I hope this helps.
--

 
 
 

forwarding, masquerading, firewalling??????

Post by Michael Schwage » Mon, 18 Jan 1999 04:00:00




> > 1. How to verify the kernel is ok with forwarding and masquerading?
> Take a look at what's in /proc/net. If you see ip_masquerade, then you
> have masquerading built into the kernel. Same for ip_forward. I use
> debian linux and these files may be in a different directory under RH.

> > 2. How to check the forward and masq rules
> You can see what rules are in effect as follows:
> ipfwadm -I -l  # for input rules
> ipfwadm -O -l  # for output rules
> ipfwadm -F -l  # for forwarding (and masquerading) rules
> ipfwadm -A -l  # for accounting rules

> > 3. How to test the system.

> > I tried testing it by pinging to an internet address from my LAN, to no
> > avail.  I have NT on the LAN set up so my linux box is the default
> > gateway.  Any suggestions?
> I don't know your level of knowledge so I'm sorry if this is a little
> pedantic.

> This is what I have and maybe you can see how your setup differs.

> #eth0 is on cable modem (24.xxx.yyy.zzz)
> #eth1 is on LAN (192.168.1.1)
> # deny everything
> ipfwadm -I -p deny
> ipfwadm -I -f
> ipfwadm -O -p deny
> ipfwadm -O -f
> ipfwadm -F -p deny
> ipfwadm -F -f

> # permit dhcp traffic so that I can get an IP address allocated by ISP
> # permit bootps (dhcp server) traffic into eth0
> ipfwadm -I -a accept -S 0.0.0.0/0 bootps -D 0.0.0.0/0 -W eth0 -P udp
> # permit bootpc (dhcp client) traffic out of eth0
> ipfwadm -O -a accept -S 0.0.0.0/0 bootpc -D 0.0.0.0/0 -W eth0 -P udp

> # permit localhost traffic (so ping localhost works)
> ipfwadm -I -a accept -S 127.0.0.1/32 -D 127.0.0.1/32
> ipfwadm -O -a accept -S 127.0.0.1/32 -D 127.0.0.1/32

> # permit LAN traffic into and out of the firewall
> ipfwadm -I -a accept -S 192.168.1.0/24 -D 0.0.0.0/0 -W eth1
> ipfwadm -O -a accept -S 0.0.0.0/0 -D 192.168.1.0/24 -W eth1

> # permit cable modem traffic into and out of the firewall
> ipfwadm -I -a accept -S 0.0.0.0/0 -D 24.xxx.yyy.zzz/32 -W eth0
> ipfwadm -O -a accept -S 24.xxx.yyy.zzz/32 -D 0.0.0.0/0 -W eth0

> # masquerade the LAN
> ipfwadm -F -a masquerade -S 192.168.1.0/24 -D 0.0.0.0/0 -W eth0

> I don't make use of the -b option, which would simplify my rules. I don't
> really have to use -I or -O rules but I may in the future lock things
> down more and want placeholders in my firewall script.

> Procedure to debug:
> From the firewall:
> 1 - you should be able to ping the localhost
> 2 - you should be able to ping a host on the internet
> 3 - you should be able to ping a host on your LAN

> From a host on your LAN:
> 4 - you should be able to ping the firewall
> 5 - you should be able to ping a host on the internet

> If you can't get one of the steps to work, then you need to see where the
> packets are getting blocked. To figure this out, you can use tcpdump as
> follows:

> Let's say that step 5 doesn't work and that the "host on your LAN" has IP
> address 192.l68.1.2. On the firewall, run this command:

> tcpdump -i eth1 ip proto icmp
> or
> tcpdump -i eth1 ip proto 1

> This will show you all packets received by the firewall on interface eth1
> (the LAN-side of the firewall) whose ip protocol type is ICMP (what ping
> uses). If you see echo-request packets from 192.168.1.2 then you know
> that your internal machine's packets are getting to the firewall. If you
> don't see echo-reply packets then you know the ping reply's aren't
> coming out of the firewall and getting to your internal machine. What you
> don't know is whether its the outgoing echo-request packets that aren't
> getting out of the firewall and onto the internet in the first place or
> its the returning echo-reply packets that aren't getting back through the
> firewall to your internal machine. To find the answer, you need to see
> what's happening on eth0 (the internet-side of the firewall). On the
> firewall, run this command:

> tcpdump -i eth0 ip proto icmp
> or
> tcpdump -i eth0 ip proto 1

> tcpdump has a *LOT* of options that you can specify to allow you to focus
> on only those packets which interest you. Check out its manpage.

> If you see no echo-request packets, then the firewall isn't allowing them
> out of your internal network.

> If you see echo-request packets (you will also so echo-reply packets),
> then the firewall isn't allowing the replies back into the internal LAN.

> There's another wrinkle to this that I haven't mentioned.

> Are your routing tables set up correctly? Your internal machines should
> have the firewall's eth1 IP address set as their default gateway. You
> mention above that this is already the case.

> The firewall should have your ISP's router set as its default gateway. If
> it doesn't, then your firewall won't know what to do with the echo-
> request packets it gets from the internal machine.

> I hope this helps.
> --


YESYESYESYES!!!!  IT worked!! THANK YOU so much!  I typed in exactly
what you have, except changing the numbers, and it worked --- for now.
That is, until dhcp assigns me a new ip address.  How do I get the dhcp
server to reassign the values in the ipfwadm tables when I get a new ip?

Honestly, I think this explanation should go into the firewall howto, or
into a mini-howto or something.

ms

 
 
 

forwarding, masquerading, firewalling??????

Post by Luca Filipoz » Mon, 18 Jan 1999 04:00:00





> > > 1. How to verify the kernel is ok with forwarding and masquerading?
> > Take a look at what's in /proc/net. If you see ip_masquerade, then you
> > have masquerading built into the kernel. Same for ip_forward. I use
> > debian linux and these files may be in a different directory under RH.

> > > 2. How to check the forward and masq rules
> > You can see what rules are in effect as follows:
> > ipfwadm -I -l  # for input rules
> > ipfwadm -O -l  # for output rules
> > ipfwadm -F -l  # for forwarding (and masquerading) rules
> > ipfwadm -A -l  # for accounting rules

> > > 3. How to test the system.

> > > I tried testing it by pinging to an internet address from my LAN, to no
> > > avail.  I have NT on the LAN set up so my linux box is the default
> > > gateway.  Any suggestions?
> > I don't know your level of knowledge so I'm sorry if this is a little
> > pedantic.

> > This is what I have and maybe you can see how your setup differs.

> > #eth0 is on cable modem (24.xxx.yyy.zzz)
> > #eth1 is on LAN (192.168.1.1)
> > # deny everything
> > ipfwadm -I -p deny
> > ipfwadm -I -f
> > ipfwadm -O -p deny
> > ipfwadm -O -f
> > ipfwadm -F -p deny
> > ipfwadm -F -f

> > # permit dhcp traffic so that I can get an IP address allocated by ISP
> > # permit bootps (dhcp server) traffic into eth0
> > ipfwadm -I -a accept -S 0.0.0.0/0 bootps -D 0.0.0.0/0 -W eth0 -P udp
> > # permit bootpc (dhcp client) traffic out of eth0
> > ipfwadm -O -a accept -S 0.0.0.0/0 bootpc -D 0.0.0.0/0 -W eth0 -P udp

> > # permit localhost traffic (so ping localhost works)
> > ipfwadm -I -a accept -S 127.0.0.1/32 -D 127.0.0.1/32
> > ipfwadm -O -a accept -S 127.0.0.1/32 -D 127.0.0.1/32

> > # permit LAN traffic into and out of the firewall
> > ipfwadm -I -a accept -S 192.168.1.0/24 -D 0.0.0.0/0 -W eth1
> > ipfwadm -O -a accept -S 0.0.0.0/0 -D 192.168.1.0/24 -W eth1

> > # permit cable modem traffic into and out of the firewall
> > ipfwadm -I -a accept -S 0.0.0.0/0 -D 24.xxx.yyy.zzz/32 -W eth0
> > ipfwadm -O -a accept -S 24.xxx.yyy.zzz/32 -D 0.0.0.0/0 -W eth0

> > # masquerade the LAN
> > ipfwadm -F -a masquerade -S 192.168.1.0/24 -D 0.0.0.0/0 -W eth0

> > I don't make use of the -b option, which would simplify my rules. I don't
> > really have to use -I or -O rules but I may in the future lock things
> > down more and want placeholders in my firewall script.

> > Procedure to debug:
> > From the firewall:
> > 1 - you should be able to ping the localhost
> > 2 - you should be able to ping a host on the internet
> > 3 - you should be able to ping a host on your LAN

> > From a host on your LAN:
> > 4 - you should be able to ping the firewall
> > 5 - you should be able to ping a host on the internet

> > If you can't get one of the steps to work, then you need to see where the
> > packets are getting blocked. To figure this out, you can use tcpdump as
> > follows:

> > Let's say that step 5 doesn't work and that the "host on your LAN" has IP
> > address 192.l68.1.2. On the firewall, run this command:

> > tcpdump -i eth1 ip proto icmp
> > or
> > tcpdump -i eth1 ip proto 1

> > This will show you all packets received by the firewall on interface eth1
> > (the LAN-side of the firewall) whose ip protocol type is ICMP (what ping
> > uses). If you see echo-request packets from 192.168.1.2 then you know
> > that your internal machine's packets are getting to the firewall. If you
> > don't see echo-reply packets then you know the ping reply's aren't
> > coming out of the firewall and getting to your internal machine. What you
> > don't know is whether its the outgoing echo-request packets that aren't
> > getting out of the firewall and onto the internet in the first place or
> > its the returning echo-reply packets that aren't getting back through the
> > firewall to your internal machine. To find the answer, you need to see
> > what's happening on eth0 (the internet-side of the firewall). On the
> > firewall, run this command:

> > tcpdump -i eth0 ip proto icmp
> > or
> > tcpdump -i eth0 ip proto 1

> > tcpdump has a *LOT* of options that you can specify to allow you to focus
> > on only those packets which interest you. Check out its manpage.

> > If you see no echo-request packets, then the firewall isn't allowing them
> > out of your internal network.

> > If you see echo-request packets (you will also so echo-reply packets),
> > then the firewall isn't allowing the replies back into the internal LAN.

> > There's another wrinkle to this that I haven't mentioned.

> > Are your routing tables set up correctly? Your internal machines should
> > have the firewall's eth1 IP address set as their default gateway. You
> > mention above that this is already the case.

> > The firewall should have your ISP's router set as its default gateway. If
> > it doesn't, then your firewall won't know what to do with the echo-
> > request packets it gets from the internal machine.

> > I hope this helps.
> > --

> YESYESYESYES!!!!  IT worked!! THANK YOU so much!  I typed in exactly
> what you have, except changing the numbers, and it worked --- for now.
> That is, until dhcp assigns me a new ip address.  How do I get the dhcp
> server to reassign the values in the ipfwadm tables when I get a new ip?

> Honestly, I think this explanation should go into the firewall howto, or
> into a mini-howto or something.

> ms

That's great that you got it working. Maybe I'll contact the LDP and see
if they want another mini-HOWTO. Thanks.

You can configure your DHCP client (dhcpcd) to to run a shell script when
it successfully gets an IP address (dhcpcd has a command line option for
this: "-c filename").

The following environment variables (amongst others) are set and passed
to the shell script: HOSTNAME, ROUTER, IPADDR, NETMASK and BROADCAST.

So, if you have all the stuff for ipfwadm in a shell script file called
/etc/init.d/rc.firewall, say, then you can start the DHCP client daemon
as follows:
dhcpcd -c /etc/init.d/rc.firewall

You'll want to make this change in whatever startup script starts up
dhcpcd. Since I don't use RedHat, I don't know where that might be. Under
Debian Linux, it's /etc/init.d/dhcpc.

This shell script, rc.firewall, will have to be modified a little bit
from what we have already. You need to use $IPADDR and $NETMASK in place
of the values you have specified statically.

So, instead of this...

# permit cable modem traffic into and out of the firewall
ipfwadm -I -a accept -S 0.0.0.0/0 -D 24.xxx.yyy.zzz/32 -W eth0
ipfwadm -O -a accept -S 24.xxx.yyy.zzz/32 -D 0.0.0.0/0 -W eth0

do this

# permit cable modem traffic into and out of the firewall
ipfwadm -I -a accept -S 0.0.0.0/0 -D $IPADDR/32 -W eth0
ipfwadm -O -a accept -S $IPADDR/32 -D 0.0.0.0/0 -W eth0

The daemon, dhcpcd, takes care of setting up the routing table. You just
have to take care of the firewall (as above) and port forwarding rules
(not described).

By the way, you could just use the subnet instead of the assigned ip
address. Since you will always be assigned a number from within the same
subnet, if you know the subnet network and netmask numbers you can just
do this

ipfwadm -I -a accept -S 0.0.0.0/0 -D 24.xxx.yyy.0/24 -W eth0
ipfwadm -O -a accept -S 24.xxx.yyy.0/25 -D 0.0.0.0/0 -W eth0

Note that the numbers I have used above assume a full class-C
subnet (i.e., with a netmask of 255.255.255.0) but that your subnet might
be have a different netmask (like 255.255.252.0 or something). This means
that you can't use /24 (8+8+8+0) but would need to use /22 (8+8+6+0).

That way, you wouldn't have to set up dhcpcd to run rc.firewall everytime
it got a new ip address. This is true for ipfwadm, at least. If you are
using port forwarding, like ipportfw or ipautofw, then you will have to
use the -c option of dhcpcd since you will want to use the IPADDR
environment variable to change the port forwarding commands.

Glad to have been of help.

--

 
 
 

forwarding, masquerading, firewalling??????

Post by Michael Schwage » Tue, 19 Jan 1999 04:00:00


Thanks a lot.  So far in one day I have not been assigned a new ip address.  I
will use the subnet method instead of having the dhcpc server calling the
script.

Two new problems:
1.  Last night, my LAN hosts were able to get on the net and web browse even
though I could not ping to an internet host by name (I had to use the ip
address).  Today, for some stupid reason, I can't even browse.  I can load up a
web page by typing in the ip of the site, but that's it.  Something to do with
nameservers I'm sure.  I didn't change anything on the windows-host (LAN) end,
I'm sure.  I used tcpdump and saw that when netscape loaded up on a host on the
LAN, NOTHING came through to either network card.  I just used tcpdump in
default mode so it was supposed to see everything coming.  So for some reason
netscape isn't even asking the linux machine to go look for things.  When I ping
from a LAN host to something, like scf.usc.edu, tcpdump reports this:
mindwalker.netbios-ns > 10.10.10.255.netbios-ns: udp 50
and the overall ping doesn't work.  I don't know if these two issues pinging and
web browsing) are related.

2.  Last night, when browsing was working, ICQ didn't work from the LAN hosts
either.  I'm not sure if that's because of the nameserving problem or because of
more involved proxy/firewall issues having to do with icq.

Any and all help is much appreciated :)
michael

 
 
 

forwarding, masquerading, firewalling??????

Post by Luca Filipoz » Tue, 19 Jan 1999 04:00:00



says...
Quote:> Thanks a lot.  So far in one day I have not been assigned a new ip address.  I
> will use the subnet method instead of having the dhcpc server calling the
> script.

> Two new problems:
> 1.  Last night, my LAN hosts were able to get on the net and web browse even
> though I could not ping to an internet host by name (I had to use the ip
> address).  Today, for some stupid reason, I can't even browse.  I can load up a
> web page by typing in the ip of the site, but that's it.  Something to do with
> nameservers I'm sure.  I didn't change anything on the windows-host (LAN) end,
> I'm sure.  I used tcpdump and saw that when netscape loaded up on a host on the
> LAN, NOTHING came through to either network card.  I just used tcpdump in
> default mode so it was supposed to see everything coming.  So for some reason
> netscape isn't even asking the linux machine to go look for things.  When I ping
> from a LAN host to something, like scf.usc.edu, tcpdump reports this:
> mindwalker.netbios-ns > 10.10.10.255.netbios-ns: udp 50
> and the overall ping doesn't work.  I don't know if these two issues pinging and
> web browsing) are related.

Are you running a nameserver? If so, this will turn into a whole other
discussion.

Or are you using your ISP's? Which will make life easier.

Step 1: Tell your Linux box and your LAN hosts to use your ISP's
nameserver. (You're paying the ISP for the right to use it!) On the linux
box, this is done with the /etc/resolv.conf file.

Step 2: Try to ping www.yahoo.com (or whatever) from the firewall. If it
resolves the name to an ip address, then the firewall's in business.

Step 3: Try to ping www.yahoo.com (or whatever) from one of the LAN
hosts. If it resolves the name to an ip address, then it's in business.
If it doesn't, use tcpdump on the firewall to see if the domain (name
resolution) packets are making it into and out of the firewall and back
again. If they aren't, then it isn't a name resolution problem but a
firewall problem. If they are, but ping doesn't work, do the same tcpdump
trick to see what's going on with the echo packets. Once you have all of
that working, trying surfing.

Quote:

> 2.  Last night, when browsing was working, ICQ didn't work from the LAN hosts
> either.  I'm not sure if that's because of the nameserving problem or because of
> more involved proxy/firewall issues having to do with icq.

OK. Now you're onto the advanced stuff ;). ICQ uses a whole mess of ports
and stuff and doesn't like to be masqueraded. This is where masquerade
"helper" modules come in. For example, ip_masq_ftp helps ftp sessions
through a masquerading firewall and ip_masq_radio helps RealAudio(tm)
sessions through a masquerading firewall. The reason these "helper"
modules are required are a result of how a masquerading firewall tracks
currently active outbound connections and how it rewrites the packets as
they go out or come back in. (I won't go into detail.)
Suffice it to say that you need a module for icq. I don't know if one
exists and suggest you do a search. If one doesn't exist and you know the
port numbers that icq uses and you only want to have icq run from LAN
host, then you can use port forwarding.

Let me know and I'll try to help out.

Quote:

> Any and all help is much appreciated :)
> michael

--

 
 
 

forwarding, masquerading, firewalling??????

Post by Michael Schwage » Tue, 19 Jan 1999 04:00:00


Thanks a lot.  So far in one day I have not been assigned a new ip address.  I
will use the subnet method instead of having the dhcpc server calling the
script.

Two new problems:
1.  Last night, my LAN hosts were able to get on the net and web browse even
though I could not ping to an internet host by name (I had to use the ip
address).  Today, for some stupid reason, I can't even browse.  I can load up a
web page by typing in the ip of the site, but that's it.  Something to do with
nameservers I'm sure.  I didn't change anything on the windows-host (LAN) end,
I'm sure.  I used tcpdump and saw that when netscape loaded up on a host on the
LAN, NOTHING came through to either network card.  I just used tcpdump in
default mode so it was supposed to see everything coming.  So for some reason
netscape isn't even asking the linux machine to go look for things.  When I ping
from a LAN host to something, like scf.usc.edu, tcpdump reports this:
mindwalker.netbios-ns > 10.10.10.255.netbios-ns: udp 50
and the overall ping doesn't work.  I don't know if these two issues pinging and
web browsing) are related.

2.  Last night, when browsing was working, ICQ didn't work from the LAN hosts
either.  I'm not sure if that's because of the nameserving problem or because of
more involved proxy/firewall issues having to do with icq.

Any and all help is much appreciated :)
michael

 
 
 

forwarding, masquerading, firewalling??????

Post by Luca Filipoz » Tue, 19 Jan 1999 04:00:00



says...
Quote:> Thanks a lot.  So far in one day I have not been assigned a new ip address.  I
> will use the subnet method instead of having the dhcpc server calling the
> script.

> Two new problems:
> 1.  Last night, my LAN hosts were able to get on the net and web browse even
> though I could not ping to an internet host by name (I had to use the ip
> address).  Today, for some stupid reason, I can't even browse.  I can load up a
> web page by typing in the ip of the site, but that's it.  Something to do with
> nameservers I'm sure.  I didn't change anything on the windows-host (LAN) end,
> I'm sure.  I used tcpdump and saw that when netscape loaded up on a host on the
> LAN, NOTHING came through to either network card.  I just used tcpdump in
> default mode so it was supposed to see everything coming.  So for some reason
> netscape isn't even asking the linux machine to go look for things.  When I ping
> from a LAN host to something, like scf.usc.edu, tcpdump reports this:
> mindwalker.netbios-ns > 10.10.10.255.netbios-ns: udp 50
> and the overall ping doesn't work.  I don't know if these two issues pinging and
> web browsing) are related.

Are you running a nameserver? If so, this will turn into a whole other
discussion.

Or are you using your ISP's? Which will make life easier.

Step 1: Tell your Linux box and your LAN hosts to use your ISP's
nameserver. (You're paying the ISP for the right to use it!) On the linux
box, this is done with the /etc/resolv.conf file.

Step 2: Try to ping www.yahoo.com (or whatever) from the firewall. If it
resolves the name to an ip address, then the firewall's in business.

Step 3: Try to ping www.yahoo.com (or whatever) from one of the LAN
hosts. If it resolves the name to an ip address, then it's in business.
If it doesn't, use tcpdump on the firewall to see if the domain (name
resolution) packets are making it into and out of the firewall and back
again. If they aren't, then it isn't a name resolution problem but a
firewall problem. If they are, but ping doesn't work, do the same tcpdump
trick to see what's going on with the echo packets. Once you have all of
that working, trying surfing.

Quote:

> 2.  Last night, when browsing was working, ICQ didn't work from the LAN hosts
> either.  I'm not sure if that's because of the nameserving problem or because of
> more involved proxy/firewall issues having to do with icq.

OK. Now you're onto the advanced stuff ;). ICQ uses a whole mess of ports
and stuff and doesn't like to be masqueraded. This is where masquerade
"helper" modules come in. For example, ip_masq_ftp helps ftp sessions
through a masquerading firewall and ip_masq_radio helps RealAudio(tm)
sessions through a masquerading firewall. The reason these "helper"
modules are required are a result of how a masquerading firewall tracks
currently active outbound connections and how it rewrites the packets as
they go out or come back in. (I won't go into detail.)
Suffice it to say that you need a module for icq. I don't know if one
exists and suggest you do a search. If one doesn't exist and you know the
port numbers that icq uses and you only want to have icq run from LAN
host, then you can use port forwarding.

Let me know and I'll try to help out.

Quote:

> Any and all help is much appreciated :)
> michael

--

 
 
 

forwarding, masquerading, firewalling??????

Post by Andrew Picki » Thu, 21 Jan 1999 04:00:00


.............

Quote:

> Procedure to debug:
> From the firewall:
> 1 - you should be able to ping the localhost
> 2 - you should be able to ping a host on the internet
> 3 - you should be able to ping a host on your LAN

> From a host on your LAN:
> 4 - you should be able to ping the firewall
> 5 - you should be able to ping a host on the internet

> If you can't get one of the steps to work, then you need to see where the
> packets are getting blocked. To figure this out, you can use tcpdump as
> follows:

> Let's say that step 5 doesn't work and that the "host on your LAN" has IP
> address 192.l68.1.2. On the firewall, run this command:

> tcpdump -i eth1 ip proto icmp
> or
> tcpdump -i eth1 ip proto 1

....on the other side........

Quote:> tcpdump -i eth0 ip proto icmp
> or
> tcpdump -i eth0 ip proto 1

Ok, my masquerade fails at step 5,

using my outgoing interface ppp0, on a tcpdump -i ppp0 ip proto 1

I see lost of requests for the ping, but nothing comes back
now what do I do? This is with all incoming accepted.
Is the ping's echo a function of the forwarding or the incoming?

TIA

Andy

PS. shouldn't the addresses given previously for the lan be
192.168.1.0/16 not 192.168.1.0/24 ?

--
-------------------------------------------------------------------
'Bother!', said Pooh, re-installing Windows yet again.

 
 
 

forwarding, masquerading, firewalling??????

Post by Luca Filipoz » Thu, 21 Jan 1999 04:00:00





> .............

> > Procedure to debug:
> > From the firewall:
> > 1 - you should be able to ping the localhost
> > 2 - you should be able to ping a host on the internet
> > 3 - you should be able to ping a host on your LAN

> > From a host on your LAN:
> > 4 - you should be able to ping the firewall
> > 5 - you should be able to ping a host on the internet

> > If you can't get one of the steps to work, then you need to see where the
> > packets are getting blocked. To figure this out, you can use tcpdump as
> > follows:

> > Let's say that step 5 doesn't work and that the "host on your LAN" has IP
> > address 192.l68.1.2. On the firewall, run this command:

> > tcpdump -i eth1 ip proto icmp
> > or
> > tcpdump -i eth1 ip proto 1

> ....on the other side........

> > tcpdump -i eth0 ip proto icmp
> > or
> > tcpdump -i eth0 ip proto 1

> Ok, my masquerade fails at step 5,

> using my outgoing interface ppp0, on a tcpdump -i ppp0 ip proto 1

> I see lost of requests for the ping, but nothing comes back
> now what do I do? This is with all incoming accepted.
> Is the ping's echo a function of the forwarding or the incoming?

This is the sequence.
The machine on LAN (inside the firewall) emits a ECHO_REQUEST packet
destined for some host on the Internet. The default route of the packet
is to the firewall's eth0 interface (I'm assuming it's your eth0). In
order to receive the packet, the firewall must allow incoming packets (of
this type) on eth0. The firewall looks at the packet, sees that it's
destined for the Internet and forwards the packet to your ISP via the
ppp0 interface (assuming the routing table is right). In the process of
forwarding the packet, the firewall masquerades it by rewriting the
packet's IP header, making it look like the packet originated from the
firewall.

(The firewall keeps track of how it has rewritten the packet's IP header
so that it knows how to rewrite the header of packets that come back from
internet. I won't go into this.)

You say that when you do a tcpdjmp -i ppp0 you see ECHO_REQUEST packets
but you don't seen any ECHO_REPLY packets. So you know two things (again,
assuming your routing tables are correct):

1) The firewall is forwarding packets.

2) The firewall may not be masquerading packets.

If the firewall is only forwarding, then the ECHO_REQUEST packet has the
same IP header as when it came out of the machine on the LAN. This means
that the packet looks like it came from 192.168.1.? (if you're using my
numbers) which is a Class C test network number allocated by IANA.
Packets whose source or destination IP address from the test network
numbers are not routed on the Internet. So the packet never gets to its
destination and an ECHO_REPLY is never generated!

Make sure that you are using masquerading

ipfwadm -F -a masq

and not only forwarding

ipfwadm -F -a allow

If this hasn't solved your problem, then post (or, better, email me, so
you don't tell the whole world how you're set up) the output from the
following:

From the firewall:
netstat -nr
ifconfig
ipfwadm -I -l
ipfwadm -O -l
ipfwadm -F -l
tracert www.yahoo.com

and, while your pinging from the workstation, the following:
tcpdump -i eth0 ip proto 1
tcpdump -i ppp0 ip proto 1

From the workstation (assuming 95/NT):
route print
ipconfig /all
tracert www.yahoo.com

That ought to do it.

Quote:

> TIA

> Andy

> PS. shouldn't the addresses given previously for the lan be
> 192.168.1.0/16 not 192.168.1.0/24 ?

No. IANA has allocated 256 class C test networks whose numbers are
192.168.0.0/24 through 192.168.255.0/24. RFC 1918, which talks about
these test network numbers, says:

   The Internet Assigned Numbers Authority (IANA) has reserved the
   following three blocks of the IP address space for private internets:
     10.0.0.0        -   10.255.255.255  (10/8 prefix)
     172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
     192.168.0.0     -   192.168.255.255 (192.168/16 prefix)
   We will refer to the first block as "24-bit block", the second as
   "20-bit block", and to the third as "16-bit" block. Note that (in
   pre-CIDR notation) the first block is nothing but a single class A
   network number, while the second block is a set of 16 contiguous
   class B network numbers, and third block is a set of 256 contiguous
   class C network numbers.

A class C network has a netmask of 255.255.255.0 or /24. When they write
"192.168/16 prefix", they are talking about anything that starts with
192.168, not the netmask.

--

 
 
 

1. IP forwarding in firewalls and masquerade boxes

The Firewall HOWTO and some other sources that I've looked at emphasize that
you should turn IP forwarding off in firewalls and (I believe) IP
masquerading boxes as well.  In principle I understand that you should turn
off all the services possible to secure a box.  My question is, what
vulnerabilities does IP forwarding expose?

For instance suppose you have an IP masquerading box with two nics -- one
talking to a 192.168.x.y private network, and one with a public IP address.
I can see how maybe a cracker could come send some packets to the public
side of the masq box that appeared to come from an 192.168.x.y address...
but I can't see how that would do a cracker any good.  And if I am guessing
right and this is how a cracker would exploit IP forwarding, then is there a
way to stipulate that packets from a 192.168.x.y address should be rejected
by the publicly accessible NIC?

Thanks in advance
Don

2. Fisakars UPS + Linux

3. Masquerading Trouble...firewall and forwarding work great. (help)

4. Blade 100/150, picld, can't open 'cpu' sensor

5. Masquerading, forwarding, firewalling Oh My.

6. Using a boot disk instead of MBR in RH 5.0

7. Newbie questions about firewalls, masquerading, and forwarding

8. executable size and speed

9. enabling port forwarding on a MASQUERADING firewall

10. Flame my Firewall - Masquerade Masquerade !

11. forwarding X clients to masqueraded machines

12. IP MASQUERADING/Forwarding/etc..

13. IP Forwarding/Masquerading FAQ --- WHERE??