Rule question

Rule question

[Patrick Petermair]

Hi!

I've read the following example script for a linux box with masquerading and 
some firewall rules:
http://www.ecst.csuchico.edu/~dranch/LINUX/ipmasq/examples/rc.firewall-2.4-stronger

So far I think I understand everything except this line:
$IPTABLES -A OUTPUT -o $INTIF -s $EXTIP -d $INTNET -j ACCEPT

How can an OUTPUT of the internal interface have the external IP address as 
source IP ?? And why would it be accepted?
As far as I understand it, the masquerading and stuff is all done in the 
FORWARD chain. I can't think of an example where a packet originating from 
the internal interface of my firewall can have the external IP as source.

Regards
Patrick

Re: Rule question

[Antony Stone]

On Saturday 22 June 2002 8:35 am, Patrick Petermair wrote:

> Hi!
>
> I've read the following example script for a linux box with masquerading
> and some firewall rules:
> http://www.ecst.csuchico.edu/~dranch/LINUX/ipmasq/examples/rc.firewall-2.4-
>stronger
>
> So far I think I understand everything except this line:
> $IPTABLES -A OUTPUT -o $INTIF -s $EXTIP -d $INTNET -j ACCEPT
>
> How can an OUTPUT of the internal interface have the external IP address as
> source IP ?? And why would it be accepted?
> As far as I understand it, the masquerading and stuff is all done in the
> FORWARD chain. I can't think of an example where a packet originating from
> the internal interface of my firewall can have the external IP as source.

Masquerading is done in the POSTROUTING chain - pretty much immediately 
before the packet goes out on the wire.

In a wayt that makes it even worse, because POSTROUTING comes *after* all the 
other chains - FORWARD, OUTPUT etc.

I don't understand the above rule either.

 

Antony.

Re: Rule question

[Patrick Schaaf]

> So far I think I understand everything except this line:
> $IPTABLES -A OUTPUT -o $INTIF -s $EXTIP -d $INTNET -j ACCEPT
> 
> How can an OUTPUT of the internal interface have the external IP address as 
> source IP ?? And why would it be accepted?

OUTPUT is for packets from local processes on the firewall machine,
which are going out to one or the other network interface. If you have
a userlevel process bind()ing the external IP of your firewall, and it
happens to connect() to a machine on the internal network, that rule
makes it work. If you do not want that, do not use that rule.

> As far as I understand it, the masquerading and stuff is all done in the 
> FORWARD chain.

Wrong. masquerading and all kind of NAT is done in one or the other
chain of the NAT table.

In the FORWARD chain, you just police the _results_ of the NAT action.
NAT itself is in the NAT table.

> I can't think of an example where a packet originating from 
> the internal interface of my firewall can have the external IP as source.

Be careful with your imagination: it becomes larger every year.

best regards
  Patrick

Re: Rule question

[Antony Stone]

On Saturday 22 June 2002 8:35 am, Patrick Petermair wrote:

> Hi!
>
> I've read the following example script for a linux box with masquerading
> and some firewall rules:
>http://www.ecst.csuchico.edu/~dranch/LINUX/ipmasq/examples/rc.firewall-2.4-stronger

I've just had a look at this script, and I don't like a couple of the 
variables he's set:

INTNET="192.168.1.0/24"
INTIP="192.168.1.1/24"

That INTNET is all very well, but the INTIP is a single address, and 
therefore should end in /32, not /24.

Given this little error, it might be worth checking the rest of this guy's 
script to see if any other little inaccuracies have crept in...

 

Antony.

Re: Rule question

[Antony Stone]

On Saturday 22 June 2002 8:46 am, Patrick Schaaf wrote:

> OUTPUT is for packets from local processes on the firewall machine,
> which are going out to one or the other network interface. If you have
> a userlevel process bind()ing the external IP of your firewall, and it
> happens to connect() to a machine on the internal network, that rule
> makes it work. If you do not want that, do not use that rule.

Why would you have a process specifically binding to the ext.IP, independent 
of the route it's communicating to the client system ?

Surely if you want to run a daemon for access by internal and external 
clients, then you would just let it bind to both interfaces and handle 
requests on a "sensible" address ?

If you only allow a daemon to bind to the ext.IP, surely you would do that 
because you only want it to respond to external requests ?

Maybe there's a good reason for this somewhere, but it's not the way I've 
ever run things...

 

Antony.

Re: Rule question

[Patrick Schaaf]

(replying to myself)
> OUTPUT is for packets from local processes on the firewall machine,
> which are going out to one or the other network interface. If you have
> a userlevel process bind()ing the external IP of your firewall, and it
> happens to connect() to a machine on the internal network, that rule
> makes it work.

For the record, there are methods available today [*] which permit you
to even _force_ select user level processes to be bound on the external IP.
In the context of firewalls, that may be a group of application level
proxies which accept "from the outside world". As usual for an application
level proxy, the next thing it does after accept()ing is making a connection
to an internal IP address.

[*] I am thinking of the chbind feature available with the vserver kernel
patches, found at http://www.solucorp.qc.ca/miscprj/s_context.hc
We are actively using that patch, and it makes a great companion to
iptables. The advantage of such "chbinding" is that even when somebody
happens to be able to exploit that application level gateway from the
outside, it will _not_ be able to impersonate any IP address (as a source)
except the one specified at "chbind" time. This keeps your iptables ruleset
intact and sane.

best regards
  Patrick

Re: Rule question

[Patrick Schaaf]

Hi Anthony,

> Why would you have a process specifically binding to the ext.IP, independent 
> of the route it's communicating to the client system ?

See my second mail (reply to myself) for one situation where I want that.
In general, I _like_ my internal machines to easily be able to look at
a source IP, and see whether it originated internally, or externally.
IOW, I like the incoming TCP connections through my application level
proxy to use the firewall's external IP address as the source, for the
sake of packet filters on my internal nodes.

> Maybe there's a good reason for this somewhere, but it's not the way I've 
> ever run things...

I do. It's very nice to have iptables so capable that it supports all our
different ways of doing things.

all the best
  Patrick

Re: Rule question

[Patrick Schaaf]

(again replying to myself. early morning makes thought so slow...)
> I like the incoming TCP connections through my application level
> proxy to use the firewall's external IP address as the source, for the
> sake of packet filters on my internal nodes.

Make that "for the sake of packet filters AND LOGFILES".

have a nice weekend
  Patrick

RE: Rule question

[Joe Patterson]

just as a note, in my experience, netfilter/iptables does exactly what *I*
think it should do, and treats these two variables as exactly the same.
Bits that are set in the masked-off portion of a network definition are
completely ignored.

So, yes, I'd a agree that this is a *very bad* choice of variables.

-Joe

> -----Original Message-----
> From: netfilter-admin@lists.samba.org
> [mailto:netfilter-admin@lists.samba.org]On Behalf Of Antony Stone
> Sent: Saturday, June 22, 2002 3:46 AM
> To: netfilter@lists.samba.org
> Subject: Re: Rule question
>
>
> On Saturday 22 June 2002 8:35 am, Patrick Petermair wrote:
>
> > Hi!
> >
> > I've read the following example script for a linux box with masquerading
> > and some firewall rules:
> >http://www.ecst.csuchico.edu/~dranch/LINUX/ipmasq/examples/rc.fir
> ewall-2.4-stronger
>
> I've just had a look at this script, and I don't like a couple of the
> variables he's set:
>
> INTNET="192.168.1.0/24"
> INTIP="192.168.1.1/24"
>
> That INTNET is all very well, but the INTIP is a single address, and
> therefore should end in /32, not /24.
>
> Given this little error, it might be worth checking the rest of
> this guy's
> script to see if any other little inaccuracies have crept in...
>
>
>
> Antony.
>
>
>