"The Linux Gazette...making Linux just a little more fun!"

ICMP Masquerading

From Abraham S. Lin on Thu, 27 May 1999

Hi, jim, This is your e-mail address on Linuxgazette, so I tried. Hope this is not your personal mailbox.

So far it all goes to the same mailbox eventually.

After reading all the docs, howtos, and the docs from www.xos.nl (supposedly original ipfwadm site), there are little mention of icmp forwarding, and no examples of it.

My setup is:

1. Redhat 5.2(full install), machine name ken. one interface to internet, the other to localnet.
2. localnet machines with 10.1.1.x private addresses. (kolya and brian)

I did deny on all in/out/forward rules of ipfwadm. And then enabling them one by one. It's a tuff job but seems like all is well.

Until I figured that ping and traceroute doesn't work from localnet. Not even from the linux gateway to internet.

You don't mention which version of the kernel you're using. That's important because most versions of the 2.0 kernel series didn't support ICMP masquerading. It's still listed as an experimental feature.

Thanks for this in advance. After this is fixed I think we'll have to make ipfirewalling HOWTO better than it is now. It didn't do on icmp forwarding.

Thanks again, abe

P.S. Here's the digest of my /etc/rc.d/rc.local on the icmp part:

Your problem has to do with MASQUERADING of ICMP. It has nothing to do with forwarding them.

You probably have to compile a later 2.0.36 kernel to add this support. You could also consider trying the 2.2.9 or later kernels and switching to the newer IP Chains model.

IP Masquerading through IPChains is not well explained in their HOWTO. I just had to figure that one out while teaching Linux classes at SGI (one of my Linuxcare roles).

I don't have my example handy but the key is to understand that the -j option to the ipchains command is used both for "jumping" to a chain (that you've created) and for declaring a disposition to a given packet. Thus ACCEPT, DENY, REJECT, REDIR, RETURN and MASQ are sorta treated like chains (you use tham as targets to the -j option) but they will not be listed with the -L and are not "flushed" with -F, etc.

When you want to masquerade for a network all you really need is:

ipchains -A forward -s $INTERNALNET -d 0.0.0.0/0 -j MASQ

... add a rule to the (pre-defined) forwarding chain so that any package with a source address (-s) matching our internal address and a destination (-d) of anywhere (else) is "just" MASQueraded.

I've successfully configured masquerading with just that rule (and the usual routes and ip_forwarding enabled). It doesn't seem to need any special rule to match addresses going from an internal address to another internal address. So we don't need to do something like:

ipchains -A forward -s $INTERNALNET  -d ! $INTERNALNET -j MASQ

... where the ! sign negates our address mask and comes to refer to any destination that is NOT in our internal network.

This second variation of the rule is more precise and probably more correct. However it doesn't seem to be necessary.

I have also been successful in setting up bidirectional masqeurading with just two fowarding rules:

ipchains -A forward -s $MYNET -d 0.0.0.0/0 -j MASQ
ipchains -A forward -s $HISNET -d 0.0.0.0/0 -j MASQ

... again this seems to work although:

ipchains -A forward -s $MYNET -d $HISNET -j MASQ
ipchains -A forward -s $HISNET -d $MYNET -j MASQ

... would seem to be more precise and probably better.

The examples in the HOWTOs seem to insist on creating a separate chain for our masquerading rules using something like:

ipchains -N mymasq

... and then using various rules to jump (-j) into that chain (which then just does a MASQ anyway, also using the -j option). This added level of indirection seems to be completely unnecessary for the simple case and is far too confusing from the examples. I suggest that people start with my simpler examples and only add the additional chains of rules as their needs demand it.

Your excerpts:

> extip=_EXTERNAL_INTERFACE_IP
> intip=_INTERNAL_INTERFACE_IP
> localnet=10.1.1.0/24
> any=0.0.0.0/0
> # A ping from kolya to 132.206.1.11 Not right still...........
> /sbin/ipfwadm -I -a accept -V $intip -P icmp -S $localnet 8 -D $any
> /sbin/ipfwadm -O -a accept -V $extip -P icmp -S $extip 8 -D $any
> /sbin/ipfwadm -I -a accept -V $extip -P icmp -S $any 0 -D $extip
> /sbin/ipfwadm -O -a accept -V $intip -P icmp -S $any 0 -D $localnet
>
> # A traceroute from kolya to 132.206.1.11 Not right still.......
> /sbin/ipfwadm -I -a accept -V $intip -P icmp -S $localnet 8 -D $any
> /sbin/ipfwadm -O -a accept -V $intip -P icmp -S $intip 11 -D $localnet
>
> /sbin/ipfwadm -I -a accept -V $intip -P icmp -S $localnet 8 -D $any
> /sbin/ipfwadm -O -a accept -V $extip -P icmp -S $extip 8 -D $any
> /sbin/ipfwadm -I -a accept -V $extip -P icmp -S $any 11 -D $extip
> /sbin/ipfwadm -O -a accept -V $intip -P icmp -S $any 11 -D $localnet
>
> # This line just produces error message. Don't know the syntax for icmp.
> /sbin/ipfwadm -F -a accept -P icmp -S $localnet 3:11 -D $any

I think you probably actually want something more like

/sbin/ipfwadm -F -a accept -m -P icmp -S $localnet 3 11 -D $any

... "port ranges" (the 3:11 syntax) aren't meaningful for ICMP. I presume you are trying to limit the packet filters to accepting/relaying "echo request" and "echo reply" packets in this example. I don't have a handy list of ICMP packet types but you definitely also want to allow some other packet types to get through (for MTU path discovery)!

Actually I'm not sure that you need it when masquerading since the ICMP message that informs a TCP stack that a "Don't Fragment" packet was dropped might only need to reach our router/gateway (the system performing the masquerading). I'm not sure if it needs to get all the way back to our host.

In any event I'd suggest that you adopt the opposite strategy with regards to ICMP packets. There are only a few of them that need to be filtered out (redirects mainly). So far it seems to be safe to let most other ICMP message types through. (Well, about as safe as letting any sort of IP traffic through, masqueraded or otherwise. Naturally you should consider proxying with SOCKS, Dante or DeleGate to tighten security even further).

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 42 June 1999

HTML transformation by Heather Stern of Starshine Techinical Services, http://www.starshine.org/

	1	2	3	4	5	6
	7	8	9	10	11	12
	13	14	15	16	17	18
	19	20	21	22	23	24