Question about nat filtering with FORWARD

Question about nat filtering with FORWARD

[Jorge Bastos]

Hi there,
I use to do nat filtering with the PREROUTE chain, but in the latest
version i see that is no longer possible.
After trying to ajust my scripts i did:


#allow TCP PORT 22
iptables -t filter -A FORWARD -p tcp --dport 22 -j ACCEPT # ssh
#block everything else
iptables -t filter -A FORWARD -j DROP


Am i doing it in the correct way?
The problem is, i cannot access the 22 port to the outside world when the
DROP rule is applied.

Jorge,

Re: Question about nat filtering with FORWARD

[Oskar Berggren]

You need to allow the return traffic also. This can be done with
connection tracking and the state match.

/Oskar


2009/6/24 Jorge Bastos <mysql.jorge@decimal.pt>:
> Hi there,
> I use to do nat filtering with the PREROUTE chain, but in the latest
> version i see that is no longer possible.
> After trying to ajust my scripts i did:
>
>
> #allow TCP PORT 22
> iptables -t filter -A FORWARD -p tcp --dport 22 -j ACCEPT # ssh
> #block everything else
> iptables -t filter -A FORWARD -j DROP
>
>
> Am i doing it in the correct way?
> The problem is, i cannot access the 22 port to the outside world when the
> DROP rule is applied.
>
> Jorge,
>
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Question about nat filtering with FORWARD

[Jorge Bastos]

> You need to allow the return traffic also. This can be done with
> connection tracking and the state match.
>
> /Oskar
>

Forgive me, but i'm a bit confused in a gray area right now.
With the PREROUTING it wasn't needed to add that and it worked, for this
new scenario, i tried:

#allow all (??)
iptables -t filter -A FORWARD -j ALLOW
#allow TCP PORT 22
iptables -t filter -A FORWARD -p tcp --dport 22 -j ACCEPT # ssh
#block everything else
iptables -t filter -A FORWARD -j DROP

And it allow's everything!
I must say that i'm not a big expert with iptables, if you can give me a
few more lights with this i'll thank you.

Jorge,

RE: Question about nat filtering with FORWARD

[Rob Sterenborg]

> > You need to allow the return traffic also. This can be done with
> > connection tracking and the state match.
> >
> > /Oskar

> Forgive me, but i'm a bit confused in a gray area right now.
> With the PREROUTING it wasn't needed to add that and it worked, for
> this
> new scenario, i tried:
> 
> #allow all (??)
> iptables -t filter -A FORWARD -j ALLOW
> #allow TCP PORT 22
> iptables -t filter -A FORWARD -p tcp --dport 22 -j ACCEPT # ssh
> #block everything else
> iptables -t filter -A FORWARD -j DROP

I think you want this:

$ipt -P FORWARD DROP
$ipt -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
$ipt -A FORWARD -m state --state NEW -p tcp --dport 22 -j ACCEPT

- You don't need to specify "-t filter". It's the default table.
- All packets that are not explicitly allowed will be dropped in the
FORWARD chain (policy = DROP).
- Any reply packet in an established connection will be accepted using
"--state RELATED,ESTABLISHED". Actually, you don't need RELATED here,
but it doesn't hurt either and you do need it if you want to forward FTP
and such protocols.
- The first packet in a connection for port 22/tcp will be accepted.
(Any subsequent packets will be accepted by the previous rule.)

For more info, you might want to read (parts of) Oskar Andreasson's
IPTables Tutorial at:
http://iptables-tutorial.frozentux.net/iptables-tutorial.html


-- Rob

Re: Question about nat filtering with FORWARD

[Christoph Paasch]

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

On Wed June 24 2009 wrote Rob Sterenborg:
> $ipt -P FORWARD DROP
> $ipt -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
> $ipt -A FORWARD -m state --state NEW -p tcp --dport 22 -j ACCEPT
Watch out, that with these rules, you will allow any traffic to pass, that has 
destination port 22. Thus, the outside can contact you to port 22. And the 
inside can contact any host on the Internet on port 22.

Best regards,
--
Christoph Paasch

www.rollerbulls.be
--

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

Re: Question about nat filtering with FORWARD

[Jorge Bastos]

> On Wed June 24 2009 wrote Rob Sterenborg:
>> $ipt -P FORWARD DROP
>> $ipt -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
>> $ipt -A FORWARD -m state --state NEW -p tcp --dport 22 -j ACCEPT
> Watch out, that with these rules, you will allow any traffic to pass, that
> has
> destination port 22. Thus, the outside can contact you to port 22. And the
> inside can contact any host on the Internet on port 22.

No good then, i just want to allow traffic for ports defined by me, for
the NAT'd machines.

Can you guys help on this? Sorry but i really have no idea, with the
PREROUTING it was easy for me.

Re: Question about nat filtering with FORWARD

[Christoph Paasch]

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


On Wed June 24 2009 wrote Jorge Bastos:
> > On Wed June 24 2009 wrote Rob Sterenborg:
> >> $ipt -P FORWARD DROP
> >> $ipt -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
> >> $ipt -A FORWARD -m state --state NEW -p tcp --dport 22 -j ACCEPT
> >
> > Watch out, that with these rules, you will allow any traffic to pass,
> > that has
> > destination port 22. Thus, the outside can contact you to port 22. And
> > the inside can contact any host on the Internet on port 22.
>
> No good then, i just want to allow traffic for ports defined by me, for
> the NAT'd machines.
>
> Can you guys help on this? Sorry but i really have no idea, with the
> PREROUTING it was easy for me.
You can add -i and -o to specify the incoming and outgoing interface to 
distinguish from the Internet and the LAN-side.

--
Christoph Paasch

www.rollerbulls.be
--

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

RE: Question about nat filtering with FORWARD

[Rob Sterenborg]

>> On Wed June 24 2009 wrote Rob Sterenborg:
>>> $ipt -P FORWARD DROP
>>> $ipt -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
>>> $ipt -A FORWARD -m state --state NEW -p tcp --dport 22 -j ACCEPT
>>> 
>> Watch out, that with these rules, you will allow any traffic to
>> pass, that has destination port 22. Thus, the outside can contact
>> you to port 22. And the inside can contact any host on the Internet
>> on port 22.

Yes, I didn't say the ruleset was perfect; it's just a starting point..
;-)

> No good then, i just want to allow traffic for ports defined by me,
> for the NAT'd machines.

So create more restrictive rules. Use -s and/or -d, etc. Think about
what you specifically want to allow and drop (or reject) everything
else. Your posts only mention port 22 so that's what my example does.

> Can you guys help on this? Sorry but i really have no idea, with
> the PREROUTING it was easy for me.

We don't know what you really want; there are no details so it's
impossible to say what exactly you should do. If you tell us what you
want you'll probably get a more detailed answer.

However, this is quite basic stuff which really is covered in the
IPTables Tutorial.


-- Rob

Re: Question about nat filtering with FORWARD

[Jorge Bastos]

>> Can you guys help on this? Sorry but i really have no idea, with the
>> PREROUTING it was easy for me.
> You can add -i and -o to specify the incoming and outgoing interface to
> distinguish from the Internet and the LAN-side.

no luck:

I think it's always better to first allow, and drop in the end, no?

iptables -t filter -A FORWARD -p tcp --dport 22 -j ACCEPT
iptables -t filter -A FORWARD -m state --state NEW -p tcp --dport 22 -j
ACCEPT
or
iptables -t filter -A FORWARD -o eth1 -m state --state NEW -p tcp --dport
22 -j ACCEPT
iptables -t filter -A FORWARD -j DROP

no luck.

Re: Question about nat filtering with FORWARD

[Richard Horton]

> no luck:
>
> I think it's always better to first allow, and drop in the end, no?
>
> iptables -t filter -A FORWARD -p tcp --dport 22 -j ACCEPT
> iptables -t filter -A FORWARD -m state --state NEW -p tcp --dport 22 -j
> ACCEPT
> or
> iptables -t filter -A FORWARD -o eth1 -m state --state NEW -p tcp --dport
> 22 -j ACCEPT
> iptables -t filter -A FORWARD -j DROP
>

You are always advised to make the default rule (Ie policy) drop with
any firewall then only explicitly allow traffic you wish allow:

(I am assuming here you want to allow connections *to* port 22 on the
external network from your internal network, for my example the
internal network has an ip address of 192.168.0.0/24)
iptables -t filter -F FORWARD  # Clear out what exists already
iptables -t filter -P FORWARD -j drop # Set default to drop
iptables -t filter -A FORWARD -s 192.168.0.0/24 -d ! 192.168.0.0/24 -p
tcp --dport 22 -j ACCEPT


--
Richard Horton
Users are like a virus: Each causing a thousand tiny crises until the
host finally dies.
http://www.solstans.co.uk - Solstans Japanese Bobtails and Norwegian Forest Cats
http://www.pbase.com/arimus - My online photogallery

Re: Question about nat filtering with FORWARD

[Jorge Bastos]

> You are always advised to make the default rule (Ie policy) drop with
> any firewall then only explicitly allow traffic you wish allow:
>
> (I am assuming here you want to allow connections *to* port 22 on the
> external network from your internal network, for my example the
> internal network has an ip address of 192.168.0.0/24)
> iptables -t filter -F FORWARD  # Clear out what exists already
> iptables -t filter -P FORWARD -j drop # Set default to drop
> iptables -t filter -A FORWARD -s 192.168.0.0/24 -d ! 192.168.0.0/24 -p
> tcp --dport 22 -j ACCEPT


cisne:/etc/rc.d# iptables -t filter -P FORWARD -j DROP
iptables v1.4.4: -P requires a chain and a policy
Try `iptables -h' or 'iptables --help' for more information.

Re: Question about nat filtering with FORWARD

[Oskar Berggren]

2009/6/24 Jorge Bastos <mysql.jorge@decimal.pt>:
>> You are always advised to make the default rule (Ie policy) drop with
>> any firewall then only explicitly allow traffic you wish allow:
>>
>> (I am assuming here you want to allow connections *to* port 22 on the
>> external network from your internal network, for my example the
>> internal network has an ip address of 192.168.0.0/24)
>> iptables -t filter -F FORWARD  # Clear out what exists already
>> iptables -t filter -P FORWARD -j drop # Set default to drop
>> iptables -t filter -A FORWARD -s 192.168.0.0/24 -d ! 192.168.0.0/24 -p
>> tcp --dport 22 -j ACCEPT
>
>
> cisne:/etc/rc.d# iptables -t filter -P FORWARD -j DROP
> iptables v1.4.4: -P requires a chain and a policy
> Try `iptables -h' or 'iptables --help' for more information.


So did you try iptables -h for more information as it suggests? This
simple typo is easy to resolve by reading the top few lines of the
help message. :-)

/Oskar

Re: Question about nat filtering with FORWARD

[Jorge Dávila]

Hi Jorge,

Well, the scenary is that you want to allow outgoing traffic to tcp
port number 22 from your internal LAN.

The rules suggested


1) $ipt -P FORWARD DROP
2) $ipt -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
3) $ipt -A FORWARD -m state --state NEW -p tcp --dport 22 -j ACCEPT


are for:

1) Apply a POLICY to DROP any packet that does not match any rule in
the chain (in this case, the FORWARD chain)

2) Allow incoming traffic in response to traffic generated from your
internal network or from the GNU/Linux router itself. If you does not
use that rule (the second rule) you will not able to "speak" with the
world

3) Allow packets marked with the SYN flag to travel to the world, but
if the second rule does not exists, the traffic in response to the
initial request to initiate a ssh sesion will not receive an answer
from the world.

I suggest you try to understand the mechanics to establish a tcp sesion.

Best regards,

Jorge Dávila.

On Wed, Jun 24, 2009 at 9:45 AM, Jorge Bastos<mysql.jorge@decimal.pt> wrote:
>> You are always advised to make the default rule (Ie policy) drop with
>> any firewall then only explicitly allow traffic you wish allow:
>>
>> (I am assuming here you want to allow connections *to* port 22 on the
>> external network from your internal network, for my example the
>> internal network has an ip address of 192.168.0.0/24)
>> iptables -t filter -F FORWARD  # Clear out what exists already
>> iptables -t filter -P FORWARD -j drop # Set default to drop
>> iptables -t filter -A FORWARD -s 192.168.0.0/24 -d ! 192.168.0.0/24 -p
>> tcp --dport 22 -j ACCEPT
>
>
> cisne:/etc/rc.d# iptables -t filter -P FORWARD -j DROP
> iptables v1.4.4: -P requires a chain and a policy
> Try `iptables -h' or 'iptables --help' for more information.
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Jorge Isaac Dávila López
+505 8430 5462
jorgedavilalopez@gmail.com
---
Esta tierra es Linux. En las noches calladas puede escucharse a las
máquinas Windows re-iniciándose...

Re: Question about nat filtering with FORWARD

[Jorge Bastos]

> Hi Jorge,
>
> Well, the scenary is that you want to allow outgoing traffic to tcp
> port number 22 from your internal LAN.
>
> The rules suggested
>
>
> 1) $ipt -P FORWARD DROP
> 2) $ipt -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
> 3) $ipt -A FORWARD -m state --state NEW -p tcp --dport 22 -j ACCEPT
>
>
> are for:
>
> 1) Apply a POLICY to DROP any packet that does not match any rule in
> the chain (in this case, the FORWARD chain)
>
> 2) Allow incoming traffic in response to traffic generated from your
> internal network or from the GNU/Linux router itself. If you does not
> use that rule (the second rule) you will not able to "speak" with the
> world
>
> 3) Allow packets marked with the SYN flag to travel to the world, but
> if the second rule does not exists, the traffic in response to the
> initial request to initiate a ssh sesion will not receive an answer
> from the world.
>
> I suggest you try to understand the mechanics to establish a tcp sesion.


Thanks alot!
This inicial part helps.
I know how to do basic filtering with input/output, and i was doing nat
filtering with the PREROUTING chain and it was easy, now things got a bit
complicated for me :-) i have to study again... last time i did this was
more than 5 years ago, i have to RElearn iptables basics!

jorge,

Re: Question about nat filtering with FORWARD

[lists]

On Wed, 2009-06-24 at 20:40 +0100, Jorge Bastos wrote:
> > Hi Jorge,
> >
> > Well, the scenary is that you want to allow outgoing traffic to tcp
> > port number 22 from your internal LAN.
> >
> > The rules suggested
> >
> >
> > 1) $ipt -P FORWARD DROP
> > 2) $ipt -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
> > 3) $ipt -A FORWARD -m state --state NEW -p tcp --dport 22 -j ACCEPT
> >
> >
> > are for:
> >
> > 1) Apply a POLICY to DROP any packet that does not match any rule in
> > the chain (in this case, the FORWARD chain)
> >
> > 2) Allow incoming traffic in response to traffic generated from your
> > internal network or from the GNU/Linux router itself. If you does not
> > use that rule (the second rule) you will not able to "speak" with the
> > world

No, not really.

Packets travel only one chain in the filter table: either the INPUT,
OUTPUT or FORWARD chain. Packets *for* the Linux host travel the INPUT
chain, packets *from* the Linux host travel the OUTPUT chain, packets
*routed through* the Linux router travel the FORWARD chain.
Since the FORWARD chain is used here, this rule will only match packets
of which routing determined that the packet was not sent to or from the
Linux host (at the risk of getting slapped because of not explaining it
right).

http://www.shorewall.com.au/misc/netfilterflow.pdf
http://jengelh.medozas.de/images/nf-packet-flow.png

The second chain allows all packets going from the internet to LAN and
vice versa, thus in or out, that are know to be in an already accepted
connection. That may be good, bad or something in between, depending on
what you want the complete ruleset to do.

> > 3) Allow packets marked with the SYN flag to travel to the world, but
> > if the second rule does not exists, the traffic in response to the
> > initial request to initiate a ssh sesion will not receive an answer
> > from the world.

The --syn flag was not used but in this case the result would be the
same.. AFAIK the first tcp packet in a connection that is in NEW state
normally carries the syn flag. If not, it may be a portscan or
something. This doesn't go for the other protocols like udp and icmp
which don't have a syn flag so it can't be specified in non-tcp rules.

> > I suggest you try to understand the mechanics to establish a tcp sesion.
> 
> 
> Thanks alot!
> This inicial part helps.

Without meaning to be rude..
I don't see how you are helped more now than before. The ruleset hasn't
changed and before you said it doesn't suit you, because it would allow
more than you wanted. You haven't shown a more detailed scenario of what
you actually want so no advice could be given to change the ruleset to
what you want it to do. (Yes: this example ruleset is too permissive if
you ask me, but it was meant as a working example.)

> I know how to do basic filtering with input/output, and i was doing nat
> filtering with the PREROUTING chain and it was easy, now things got a bit
> complicated for me :-) i have to study again... last time i did this was
> more than 5 years ago, i have to RElearn iptables basics!

So perhaps Oskar's IPTables Tutorial really would be a good place to
start. It has all the basics in it and more. I know it's a bit dated
(last change seems to be from 2006) but the basics still hold.


-- Rob

Re: Question about nat filtering with FORWARD

[Pascal Hambourg]

Hello,

Rob Sterenborg a écrit :
> 
> - Any reply packet in an established connection will be accepted using
> "--state RELATED,ESTABLISHED". Actually, you don't need RELATED here,
> but it doesn't hurt either and you do need it if you want to forward FTP
> and such protocols.

ICMP error messages (destination unreachable, TTL exceeded, 
fragmentation needed...) are in the RELATED state. So you need RELATED 
if you don't want to break ICMP error signalling and mechanisms which 
rely on it such as Path MTU Detection (PMTUD).

Re: Question about nat filtering with FORWARD

[Pascal Hambourg]

Pascal Hambourg a écrit :
> 
> ICMP error messages (destination unreachable, TTL exceeded, 
> fragmentation needed...) are in the RELATED state. So you need RELATED 
> if you don't want to break ICMP error signalling and mechanisms which 
> rely on it such as Path MTU Detection (PMTUD).

Oops, s/Detection/Discovery/

Note that ICMP error signalling is a mandatory part of IP operation, and 
path MTU discovery is enabled by default in Linux, and possibly other 
operating systems.