Understanding the Forward and Postrouting chain

Understanding the Forward and Postrouting chain

[Chris Partsenidis]

[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]

Greetings everyone,

While building a complex set a rules for my firewall I have stumbbled
accross a few problems and would like to know if there is anyone to help me
clear a few things in my mind.

If I was to set the Forward chain default policy to DROP, what rules would I
be required to enter in order to allow e.g my internal network hosts to
telnet anywhere on the internet ?

For example take this setup:

LAN -----------------FIREWALL------------------------ Internet
192.168.1.0/24		 public ip: 200.0.0.1
				
In this simple setup, my guess is that Im required to create 3 rules for the
telnet to work.
One for the packets travelling from the Lan to the firewall, one for the
oppisite (internet to the firewall) and then one more
for the postrouting chain to masquerade the packets. Here is what I've done:

1) iptables -P FORWARD DROP
2) iptables -A FORWARD -s 192.168.1.0/24 -p tcp -d 0/0 --dport 23 -j ACCEPT
3) iptables -A FORWARD -p tcp -s 0/0 --sport 23 -d  200.0.0.1 -j ACCEPT
4) iptables -A POSTROUTING -t nat -s 192.168.1.0/24 -p tcp -d 0/0 --dport 23
-j MASQUERADE

Would this be correct, and if not, can you please explain why. I'm not to
sure if loading ip_conntrack would eliminate the need for rule no. 3.

Regards, 

Chris Partsenidis

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2308 bytes --]

Re: Understanding the Forward and Postrouting chain

[Raymond Leach]

[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]

On Tue, 2003-04-15 at 11:52, Chris Partsenidis wrote:
> Greetings everyone,
> 
> While building a complex set a rules for my firewall I have stumbbled
> accross a few problems and would like to know if there is anyone to
> help me clear a few things in my mind.
> 
> If I was to set the Forward chain default policy to DROP, what rules
> would I be required to enter in order to allow e.g my internal network
> hosts to telnet anywhere on the internet ?
> 
> For example take this setup:
> 
> LAN -----------------FIREWALL------------------------ Internet
> 192.168.1.0/24           public ip: 200.0.0.1
>                                 
> In this simple setup, my guess is that Im required to create 3 rules
> for the telnet to work.
> One for the packets travelling from the Lan to the firewall, one for
> the oppisite (internet to the firewall) and then one more
> 
> for the postrouting chain to masquerade the packets. Here is what I've
> done:
> 
> 1) iptables -P FORWARD DROP
> 2) iptables -A FORWARD -s 192.168.1.0/24 -p tcp -d 0/0 --dport 23 -j
> ACCEPT
> 3) iptables -A FORWARD -p tcp -s 0/0 --sport 23 -d  200.0.0.1 -j
> ACCEPT

This one should be:
iptables -A FORWARD -p tcp -s 0/0 --sport 23 -d  192.168.1.0/24 -j
ACCEPT
because the traffic is going back to the client not the firewall.

> 4) iptables -A POSTROUTING -t nat -s 192.168.1.0/24 -p tcp -d 0/0
> --dport 23 -j MASQUERADE
> 
> Would this be correct, and if not, can you please explain why. I'm not
> to sure if loading ip_conntrack would eliminate the need for rule no.
> 3.
No, conntrack is connection tracking for NAT. Without conntrack you
would have many more rules to tell iptables how to track the NATed
traffic.


> 
> Regards, 
> 
> Chris Partsenidis

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Bridge + mangling; any similar experiences?

[Scott MacKay]

Hiyas, sorry to bother this list, but the ebtables
mailing list is kinda quiet (plus the bridge feature I
think is integrated into 2.5 kernel...).

I have been having a problem, and was wondering if
anyone had similar experiences.  I am using 2.4.20;
RedHat distro + recompiled kernel with the latest
ebtables + br thing patch.  The sole, only, and
probably ever only reason is so I can be in bridge
mode and have prerouting & postrouting hooks (so if a
non-ebtables approach is known, please let me know).

I have a custom userspace module which I am using to
mangle packets.  I mangle the contents of TCP/UDP
payloads, recalcing the IP and TCP/UDP headers.  I
basically mangle the packets between 2 bridge boxes,
demangling packets on each side's 'intranet'.  No
firewall denial rules or nothing; just the pre/post
routing.  When I do not mangle (just pass in/out my
userspace), it works fine.  When I reconfigure in a
router mode (as opposed to bridge), my mangling works
fine.  In bridge mode, though, with mangling, by
traffic crawls to tens of bytes/second.  If I turn off
the mangling, it picks back up to happy 10mbit rates.
The payload, when finally delivered (in my testing, I
use a simple TCP push/receive pair of applications),
is valid, so it does  mangle/demangle OK.  

Does anyone have any ideas why this could be
happening?  
Any pointers, thoughts on the
netfilter/ebtables/whatever would help me greatly. 
Thanks!!!

-Scott



__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com

Re: Understanding the Forward and Postrouting chain

[Joel Newkirk]

On Tue, 2003-04-15 at 05:52, Chris Partsenidis wrote:
> Greetings everyone,
> 
> While building a complex set a rules for my firewall I have stumbbled
> accross a few problems and would like to know if there is anyone to help me
> clear a few things in my mind.
> 
> If I was to set the Forward chain default policy to DROP, what rules would I
> be required to enter in order to allow e.g my internal network hosts to
> telnet anywhere on the internet ?
> 
> For example take this setup:
> 
> LAN -----------------FIREWALL------------------------ Internet
> 192.168.1.0/24		 public ip: 200.0.0.1
> 				
> In this simple setup, my guess is that Im required to create 3 rules for the
> telnet to work.
> One for the packets travelling from the Lan to the firewall, one for the
> oppisite (internet to the firewall) and then one more
> for the postrouting chain to masquerade the packets. Here is what I've done:
> 
> 1) iptables -P FORWARD DROP
> 2) iptables -A FORWARD -s 192.168.1.0/24 -p tcp -d 0/0 --dport 23 -j ACCEPT
> 3) iptables -A FORWARD -p tcp -s 0/0 --sport 23 -d  200.0.0.1 -j ACCEPT
> 4) iptables -A POSTROUTING -t nat -s 192.168.1.0/24 -p tcp -d 0/0 --dport 23
> -j MASQUERADE
> 
> Would this be correct, and if not, can you please explain why. I'm not to
> sure if loading ip_conntrack would eliminate the need for rule no. 3.

#3 is your problem.  When the reply packets come back through, they are
un-SNATted (un-MASQUERADEd in this case) in nat PREROUTING, before they
enter the FORWARD chain, so you need to match the local IP addresses not
the public one.

However, if you use ip_conntrack, you can handle this with:

iptables -A FORWARD -d 192.168.1.0/24 -m state --state ESTABLISHED -j
ACCEPT

which tells netfilter that anything with a state ESTABLISHED (reply or
ongoing traffic) destined for the specified subnet is ACCEPTed.  The
more generalized and expanded form, which will greatly reduce the number
of rules you actually need to explicitly define, is:

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

This way anything that is part of an already-established connection, or
related to one, is accepted.  RELATED state is netfilter magic.  Some
things like icmp_host_unreachable can be related to an attempted
connection, and RELATED also encompasses things handled by conntrack
helpers like FTP data (active or passive) being related to the control
connection, so all you have to do is ACCEPT tcp port 21 outbound,
EST/REL out and in, and local machines can then use FTP.

> Regards, 
> 
> Chris Partsenidis

j