Iptables initialization

Dagmar d'Surreal dagmar.wants at nospam.com
Mon Feb 16 11:42:55 PST 2004


On Sat, 2004-02-14 at 16:45, Ian Molton wrote:
> On Sat, 14 Feb 2004 11:12:36 -0600
> Dagmar d'Surreal <dagmar.wants at nospam.com> wrote:
> 
> > If you're not going to research this further then just take my word on
> > the ARP thing.  I'm very familiar with ARP trickery and one of my more
> > favorite stunts to do is show people how to make their firewall use no
> > public IPs whatsoever (which also has the nice side-effect of making
> > the firewall utterly untouchable outside of it's two local networks).
> 
> Thats a nice trick. I think I know how its done but my knowledge of ARP
> is limited so perhaps you might like to comment ?

Okay, it's not particularly difficult to do, and it's possible to do
with just a single assigned IP (like on a cablemodem) but not very
useful and precludes masquerading.  (This is also done on a lot of
people's routers, which is why you'll occasionally see RFC-1918
addresses come back in a traceroute.)

Let's say for example you have been assigned 8 internet-routable IP
addresses by your DSL provider.  On your bastion/router, you need to
assign an RFC-1918 address (say, 192.168.1.1) to the eth1 external
interface with a netmask as if it were a /32 network (i.e,
255.255.255.255, which means the broadcast address would be
192.168.1.1).  On the eth0 internal interface, you'd do the same thing
with a different IP address (192.168.1.2, for example).  The machine's
default route should of course, point to the gateway IP for the netblock
you've been given.  Then add a route for the little netblock you've
gotten that points to the internal network.  You now have the two
necessary routes and should turn on packet forwarding...

At this point, still nothing is going to work, and here's why (as well
as why ARP trickery comes into play).  Traffic from the internet is
going to reach the ISP's router for say, 64.64.64.64 (one of your
internet-routable IPs) and it's going to poll the segment your external
interface is connected to with an "ARP WHO-HAS 64.64.64.64" query, and
whatever machine is currently configured for that IP address is supposed
to send an ARP reply similar to "ARP-REPLY 01:20:34:56:45 HAS
64.64.64.64".  In it's current state, your router has only been assigned
192.168.1.1 on that interface, so it's not going to respond.  This we
fix by telling the router that it should _also_ ARP reply for
64.64.64.64 (and the other IP addresses you have inside) by saying...

arp -i eth1 -Ds 64.64.64.64 eth1 pub

This sticks an entry into the arp cache for the eth1 interface that will
cause the firewall to respond saying "I'm 64.64.64.64" every time
something on that segment makes an ARP query.  This gets our incoming
traffic from the internet into the firewall/router, where normal routing
should make the machine examine the packet and say "Oh, it doesn't
belong to me, and the routing table says I should forward this on to the
internal segment" (after it applies normal filtering policies).  This
will need to be done for each IP address you want to have behind the
firewall (although on Linux, there is now a way to wildcard it so you
only have to enter one command.  Check the man page and don't let the
word "hostname" fool you)

We must also get traffic from the internal segement to come back out,
and this means that (as may be obvious by now) the internal machines
will need to be configured more or less as if the firewall didn't
exist.  They'll need to have a default route that points to the ISP's
gateway for that netblock, and so that when *they* ARP query to find the
MAC of the gateway, your firewall's internal interface will respond... 
If the ISP's gateway were 64.64.1.1, it would be...

arp -i eth0 -Ds 64.64.1.1 eth0 pub

Normal routing will get packets moving in the right direction in this
case as well.  

The mention of the interface name twice in each arp invocaton is not
redundancy.  The -i argument sets which interface's ARP tables get the
entry, and the second mention of the interface is due to the -D flag,
which lets the arp binary fill in the hardware address of the interface
so you don't have to do any gymnastics with ifconfig and grep to set it
properly.  If you don't specify the -i interface, on some platforms the
entry will wind up applying to all interfaces (which you don't really
want because it will mangle your external segment for you to be racing
the router to respond to ARP queries meant to find it--this is one of
those things that can make an ISP very mad).
-- 
The email address above is phony because my penis is already large enough, kthx. 
              AIM: evilDagmar  Jabber: evilDagmar at jabber.org




More information about the hlfs-dev mailing list