* Re: Understanding the Forward and Postrouting chain
2003-04-15 9:52 Understanding the Forward and Postrouting chain Chris Partsenidis
@ 2003-04-15 10:05 ` Raymond Leach
2003-04-15 12:04 ` Bridge + mangling; any similar experiences? Scott MacKay
2003-04-15 13:23 ` Understanding the Forward and Postrouting chain Joel Newkirk
1 sibling, 1 reply; 4+ messages in thread
From: Raymond Leach @ 2003-04-15 10:05 UTC (permalink / raw)
To: Netfilter Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Understanding the Forward and Postrouting chain
2003-04-15 9:52 Understanding the Forward and Postrouting chain Chris Partsenidis
2003-04-15 10:05 ` Raymond Leach
@ 2003-04-15 13:23 ` Joel Newkirk
1 sibling, 0 replies; 4+ messages in thread
From: Joel Newkirk @ 2003-04-15 13:23 UTC (permalink / raw)
To: Chris; +Cc: netfilter
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
^ permalink raw reply [flat|nested] 4+ messages in thread