* iptables, portforward, DNAT, SNAT
@ 2002-10-31 15:33 Thomas Meindl
2002-10-31 16:39 ` Antony Stone
0 siblings, 1 reply; 5+ messages in thread
From: Thomas Meindl @ 2002-10-31 15:33 UTC (permalink / raw
To: netfilter
I have a decent problem that started spreading out in an unconvinient way - for now it simply takes to much time to get solved;
like most of the time it is an simple problem
here we have it - portforwarding:
I have a small LAN at home with a cable connection. so I get my ip from the ISP thru' dhcp..
and here's a part of my script:
#!/bin/bash
EXTIF=eth0
INTIF=eth1
EXTIP=www.xxx.yyy.zzz
INTIP=192.168.0.1
WWWSRV=192.168.0.2
#here I'll make some
echo 1 > /proc/sys/net/ipv4/*
#to some features like ip_dynaddr, ip_forward, tcp_syncookie
#then I set the default policies
#accept everything except the FORWARD chain
#and flush them
iptables -P INPUT -j ACCEPT
iptables -F INPUT
iptables -P OUTPUT -j ACCEPT
iptables -F OUTPUT
iptables -P FORWARD -j DROP
iptables -F FORWARD
iptables -t nat -f #flush the nat table
# and here's my little disaster
# i try to forward port 1234 to my internal www-server
iptables -t nat -A PREROUTING -p tcp -i $EXTIF -d $EXTIP --dport 1234 -j DNAT --to-destination $WWWSRV:80
iptables -A FORWARD -p tcp -i $EXTIF -o $INTIF -d $WWWSRV --dport 80 -j ACCEPT
iptables -t nat -A POSTROUTING -p tcp -o $EXTIF -s $WWWSRV --sport 80 -j SNAT --to-source $EXTIP:1234
# for what i understand from iptables till now is
# packet comes in thru ethernet, arrives in kernel
# so packet looks like this
# ip-layer: source-ip: WWWREQUEST destination-ip: $EXTIP
# tcp-layer: source-port: a port higher than 1024 destination-port: 1234
# and hits the PREROUTING chain
# with the DNAT rule above it changes following
# ip-layer: source-ip: WWWREQUEST destination-ip: $WWSRV
# tcp-layer: source-port: a port higher than 1024 destination-port: 80
# then hits FORWARD chain (usually it would hit the INPUT chain,
# but we changed that with DNAT; it has to go out on $INTIF to reach
# its destination..)
# with the FORWARD rule it can bypass..
# when applying DNAT all other packets in that stream are bypassed as well
# with this two rules it is sure that a request from a www-client from
# the inet is reaching the inner $WWWSRV, and the $WWWSRV can respond but # there is still something wrong with the reply packet:
# ip-layer: source-ip: $WWWSRV destination-ip: WWWREQUEST
# tcp-layer: source-port: 80 destination-port: 1024:
# when the packet arrives at the WWWREQUEST-host-browser it doesn't know
# what to do with the packet (there was no request to this host $WWWSRV)
# so here comes rule 3; it changes the source ip and port to this
# ip-layer: source-ip: $EXTIP destination-ip: WWWREQUEST
# tcp-layer: source-port: 1234 destination-port: 1024:
# now the packet seems like the awaited reply from the request
# he has given to $EXTIP:1234
# and another few rules to complete the firewall script
# allow all connections from inside out and only related
# and established ones in
iptables -A FORWARD -p tcp -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p tcp -o $EXTIF -i $INTIF -j ACCEPT
# enable masquerading
iptables -t NAT -A POSTROUTING -o $EXTIF -j MASQUERADE
I hope anyone out there can help me..
I tried serveral permutations with the three portforwarding rules:
I changed some params or even let them away
One Variation was to ACCEPT the full FORWARD chain
I hope there aren't any spelling mistakes, cause I wrote this script
just for email purpose´; on my router is the original..
I've also read dozens of mailing-list entry like this and everyone seemed pausible but till now it didn't work - I've tried two days now and I'm kind of frustrated
oh yeah, modules loaded by the kernel:
ip_tables
iptable_nat
ip_conntrack
ip_conntrack_ftp
ip_conntrack_irc
ip_nat_ftp
iptable_filter
ipt_state
ipt_LOG
ipt_MASQUERADE
it must be a kind of silly, tiny failure
one I haven't looked for yet..
thanks for any little hint!
methodaut
__________________________________________________________________
The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp
Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: iptables, portforward, DNAT, SNAT
2002-10-31 15:33 iptables, portforward, DNAT, SNAT Thomas Meindl
@ 2002-10-31 16:39 ` Antony Stone
2002-10-31 16:47 ` Robert P. J. Day
0 siblings, 1 reply; 5+ messages in thread
From: Antony Stone @ 2002-10-31 16:39 UTC (permalink / raw
To: netfilter
On Thursday 31 October 2002 3:33 pm, Thomas Meindl wrote:
> #!/bin/bash
>
> EXTIF=eth0
> INTIF=eth1
> EXTIP=www.xxx.yyy.zzz
> INTIP=192.168.0.1
> WWWSRV=192.168.0.2
>
> #here I'll make some
> echo 1 > /proc/sys/net/ipv4/*
Does that line really say "echo 1 to every file in the /proc/sys/net/ipv4
directory" !?
Why ???
> #to some features like ip_dynaddr, ip_forward, tcp_syncookie
>
> #then I set the default policies
> #accept everything except the FORWARD chain
> #and flush them
> iptables -P INPUT -j ACCEPT
I don't like that - you should have a default DROP on INPUT and then create
rules to ACCEPT what you know you want. Otherwise you're accepting anything
anyone cares to send you....
> iptables -F INPUT
> iptables -P OUTPUT -j ACCEPT
> iptables -F OUTPUT
> iptables -P FORWARD -j DROP
> iptables -F FORWARD
> iptables -t nat -f #flush the nat table
>
> # and here's my little disaster
> # i try to forward port 1234 to my internal www-server
> iptables -t nat -A PREROUTING -p tcp -i $EXTIF -d $EXTIP --dport 1234 -j
> DNAT --to-destination $WWWSRV:80
Okay - that will redirect the incoming packets on TCP port 1234 to your
internal web server, port 80
> iptables -A FORWARD -p tcp -i $EXTIF -o $INTIF -d $WWWSRV --dport 80 -j
ACCEPT
That rule will forward the packets through your firewall to the web server
(do you have a rule somewhere to allow the replies back again ?)
> iptables -t nat -A POSTROUTING -p tcp -o $EXTIF -s $WWWSRV --sport 80 -j
SNAT --to-source $EXTIP:1234
I don't understand this rule - replies from the webserver are going to get
automagically reverse NATted anyway, so this rule is redundant...
> # for what i understand from iptables till now is
> # packet comes in thru ethernet, arrives in kernel
> # so packet looks like this
> # ip-layer: source-ip: WWWREQUEST destination-ip: $EXTIP
> # tcp-layer: source-port: a port higher than 1024 destination-port: 1234
> # and hits the PREROUTING chain
Looks good so far.
> # with the DNAT rule above it changes following
> # ip-layer: source-ip: WWWREQUEST destination-ip: $WWSRV
> # tcp-layer: source-port: a port higher than 1024 destination-port: 80
Yup.
> # then hits FORWARD chain (usually it would hit the INPUT chain,
> # but we changed that with DNAT; it has to go out on $INTIF to reach
> # its destination..)
Correct.
> # with the FORWARD rule it can bypass..
Sorry - what do you mean ?
> # when applying DNAT all other packets in that stream are bypassed as well
All other packets in that stream are translated (both ways), yes.
> # with this two rules it is sure that a request from a www-client from
> # the inet is reaching the inner $WWWSRV, and the $WWWSRV can respond but
> # there is still something wrong with the reply packet:
> # ip-layer: source-ip: $WWWSRV destination-ip: WWWREQUEST
> # tcp-layer: source-port: 80 destination-port: 1024:
That's how it goes out from the web server, yes, but that doesn't show the
reverse NAT which will have been applied by netfilter by the time it gets
back to the client. Borrowing your terminology, that would look like:
> # ip-layer: source-ip: $EXTIP destination-ip: WWWREQUEST
> # tcp-layer: source-port: 1234 destination-port: 1024:
> # when the packet arrives at the WWWREQUEST-host-browser it doesn't know
> # what to do with the packet (there was no request to this host $WWWSRV)
> # so here comes rule 3; it changes the source ip and port to this
> # ip-layer: source-ip: $EXTIP destination-ip: WWWREQUEST
> # tcp-layer: source-port: 1234 destination-port: 1024:
> # now the packet seems like the awaited reply from the request
> # he has given to $EXTIP:1234
I think you do not realise that netfilter automagically applies the reverse
NAT rules to reply packets, so you do not have to create your own rules to do
this.
> # and another few rules to complete the firewall script
>
> # allow all connections from inside out and only related
> # and established ones in
> iptables -A FORWARD -p tcp -i $EXTIF -o $INTIF -m state --state
> ESTABLISHED,RELATED -j ACCEPT
> iptables -A FORWARD -p tcp -o $EXTIF -i $INTIF -j ACCEPT
Okay, these two rules (specifically the last one) will allow your replies
back out from the web server to the client.
> # enable masquerading
> iptables -t NAT -A POSTROUTING -o $EXTIF -j MASQUERADE
"NAT" in this rule should read "nat" - it matters !
> I hope anyone out there can help me..
> I tried serveral permutations with the three portforwarding rules:
I think if you remove the third one it will work.
> I changed some params or even let them away
> One Variation was to ACCEPT the full FORWARD chain
Ugh !!!
Antony.
--
It is also possible that putting the birds in a laboratory setting
inadvertently renders them relatively incompetent.
- Daniel C Dennett
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: iptables, portforward, DNAT, SNAT
2002-10-31 16:39 ` Antony Stone
@ 2002-10-31 16:47 ` Robert P. J. Day
0 siblings, 0 replies; 5+ messages in thread
From: Robert P. J. Day @ 2002-10-31 16:47 UTC (permalink / raw
To: netfilter mailing list
On Thu, 31 Oct 2002, Antony Stone wrote:
> On Thursday 31 October 2002 3:33 pm, Thomas Meindl wrote:
>
> > #!/bin/bash
> >
> > EXTIF=eth0
> > INTIF=eth1
> > EXTIP=www.xxx.yyy.zzz
> > INTIP=192.168.0.1
> > WWWSRV=192.168.0.2
> >
> > #here I'll make some
> > echo 1 > /proc/sys/net/ipv4/*
>
> Does that line really say "echo 1 to every file in the /proc/sys/net/ipv4
> directory" !?
>
> Why ???
more to the point, it won't work anyway -- bash will give you an
"ambiguous redirect" error.
rday
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: iptables, portforward, DNAT, SNAT
@ 2002-10-31 19:23 Thomas Meindl
2002-10-31 21:54 ` Anders Fugmann
0 siblings, 1 reply; 5+ messages in thread
From: Thomas Meindl @ 2002-10-31 19:23 UTC (permalink / raw
To: netfilter
Antony Stone <Antony@Soft-Solutions.co.uk> wrote:
>On Thursday 31 October 2002 3:33 pm, Thomas Meindl wrote:
>
>> #!/bin/bash
>>
>> EXTIF=eth0
>> INTIF=eth1
>> EXTIP=www.xxx.yyy.zzz
>> INTIP=192.168.0.1
>> WWWSRV=192.168.0.2
>>
>> #here I'll make some
>> echo 1 > /proc/sys/net/ipv4/*
>
>Does that line really say "echo 1 to every file in the /proc/sys/net/ipv4
>directory" !?
>
>Why ???
no, i didn't write it that way in the actual script.
just to save some tipping here..
* stands for the three below
sorry for that confusing
I simply should have copied and pasted it like
echo 1 > /proc/sys/net/ipv4/ip_dynaddr
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/tcp_syncookie
>
>> #to some features like ip_dynaddr, ip_forward, tcp_syncookie
>>
>> #then I set the default policies
>> #accept everything except the FORWARD chain
>> #and flush them
>> iptables -P INPUT -j ACCEPT
>
>I don't like that - you should have a default DROP on INPUT and then create
>rules to ACCEPT what you know you want. Otherwise you're accepting anything
>anyone cares to send you....
>
I know. I have a more extended script, but to be sure that portforwarding works pretty soon, i'll keep that one simple
>> iptables -F INPUT
>> iptables -P OUTPUT -j ACCEPT
>> iptables -F OUTPUT
>> iptables -P FORWARD -j DROP
>> iptables -F FORWARD
>> iptables -t nat -f #flush the nat table
>>
>> # and here's my little disaster
>> # i try to forward port 1234 to my internal www-server
>> iptables -t nat -A PREROUTING -p tcp -i $EXTIF -d $EXTIP --dport 1234 -j
>> DNAT --to-destination $WWWSRV:80
>
>Okay - that will redirect the incoming packets on TCP port 1234 to your
>internal web server, port 80
>
>> iptables -A FORWARD -p tcp -i $EXTIF -o $INTIF -d $WWWSRV --dport 80 -j
>ACCEPT
>
>That rule will forward the packets through your firewall to the web server
>(do you have a rule somewhere to allow the replies back again ?)
>
>> iptables -t nat -A POSTROUTING -p tcp -o $EXTIF -s $WWWSRV --sport 80 -j
>SNAT --to-source $EXTIP:1234
>
>I don't understand this rule - replies from the webserver are going to get
>automagically reverse NATted anyway, so this rule is redundant...
>
>> # for what i understand from iptables till now is
>> # packet comes in thru ethernet, arrives in kernel
>> # so packet looks like this
>> # ip-layer: source-ip: WWWREQUEST destination-ip: $EXTIP
>> # tcp-layer: source-port: a port higher than 1024 destination-port: 1234
>> # and hits the PREROUTING chain
>
>Looks good so far.
>
>> # with the DNAT rule above it changes following
>> # ip-layer: source-ip: WWWREQUEST destination-ip: $WWSRV
>> # tcp-layer: source-port: a port higher than 1024 destination-port: 80
>
>Yup.
>
>> # then hits FORWARD chain (usually it would hit the INPUT chain,
>> # but we changed that with DNAT; it has to go out on $INTIF to reach
>> # its destination..)
>
>Correct.
>
>> # with the FORWARD rule it can bypass..
>
>Sorry - what do you mean ?
>
>> # when applying DNAT all other packets in that stream are bypassed as well
>
>All other packets in that stream are translated (both ways), yes.
>
>> # with this two rules it is sure that a request from a www-client from
>> # the inet is reaching the inner $WWWSRV, and the $WWWSRV can respond but
>> # there is still something wrong with the reply packet:
>> # ip-layer: source-ip: $WWWSRV destination-ip: WWWREQUEST
>> # tcp-layer: source-port: 80 destination-port: 1024:
>
>That's how it goes out from the web server, yes, but that doesn't show the
>reverse NAT which will have been applied by netfilter by the time it gets
>back to the client. Borrowing your terminology, that would look like:
>
>> # ip-layer: source-ip: $EXTIP destination-ip: WWWREQUEST
>> # tcp-layer: source-port: 1234 destination-port: 1024:
>
>> # when the packet arrives at the WWWREQUEST-host-browser it doesn't know
>> # what to do with the packet (there was no request to this host $WWWSRV)
>> # so here comes rule 3; it changes the source ip and port to this
>> # ip-layer: source-ip: $EXTIP destination-ip: WWWREQUEST
>> # tcp-layer: source-port: 1234 destination-port: 1024:
>> # now the packet seems like the awaited reply from the request
>> # he has given to $EXTIP:1234
>
>I think you do not realise that netfilter automagically applies the reverse
>NAT rules to reply packets, so you do not have to create your own rules to do
>this.
>
>> # and another few rules to complete the firewall script
>>
>> # allow all connections from inside out and only related
>> # and established ones in
>> iptables -A FORWARD -p tcp -i $EXTIF -o $INTIF -m state --state
>> ESTABLISHED,RELATED -j ACCEPT
>> iptables -A FORWARD -p tcp -o $EXTIF -i $INTIF -j ACCEPT
>
>Okay, these two rules (specifically the last one) will allow your replies
>back out from the web server to the client.
>
>> # enable masquerading
>> iptables -t NAT -A POSTROUTING -o $EXTIF -j MASQUERADE
>
>"NAT" in this rule should read "nat" - it matters !
>
spelling mistake sorry! nat
>> I hope anyone out there can help me..
>> I tried serveral permutations with the three portforwarding rules:
>
>I think if you remove the third one it will work.
I just tried it without the third (i have tried it that way before)
but it still won't work !!!
>
>> I changed some params or even let them away
>> One Variation was to ACCEPT the full FORWARD chain
>
>Ugh !!!
i know, i know; but one gets really bad ideas when sth doesn't work
>
>
>Antony.
>
>--
>
>It is also possible that putting the birds in a laboratory setting
>inadvertently renders them relatively incompetent.
>
> - Daniel C Dennett
>
>
__________________________________________________________________
The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp
Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: iptables, portforward, DNAT, SNAT
2002-10-31 19:23 Thomas Meindl
@ 2002-10-31 21:54 ` Anders Fugmann
0 siblings, 0 replies; 5+ messages in thread
From: Anders Fugmann @ 2002-10-31 21:54 UTC (permalink / raw
To: Thomas Meindl; +Cc: netfilter
Thomas Meindl wrote:
> Antony Stone <Antony@Soft-Solutions.co.uk> wrote:
>
> no, i didn't write it that way in the actual script.
> just to save some tipping here..
>
> * stands for the three below
>
> sorry for that confusing
> I simply should have copied and pasted it like
>
> echo 1 > /proc/sys/net/ipv4/ip_dynaddr
> echo 1 > /proc/sys/net/ipv4/ip_forward
> echo 1 > /proc/sys/net/ipv4/tcp_syncookie
>
>>># enable masquerading
>>>iptables -t NAT -A POSTROUTING -o $EXTIF -j MASQUERADE
>>
>>"NAT" in this rule should read "nat" - it matters !
>>
>
>
> spelling mistake sorry! nat
>
Something that completely eludes me. You have hand typed the script you
post for debugging? Then how do you know that the error is in the script?
Try to narrow the problem down to a very small set of rules, and test
the script. If it still does not work then post the script as is - copy
and paste. I imagine that over 50% of all script questions posted to
this list would answer itself, it the scripts posted had actually been
tested.
I'm not flaming you, and apologize if you take it that way.
I'm trying to provide you with the tools to solve the problem. I guess
that if you work systematically, then one of two will happen: you
solve the problem yourself, or you will be able to ask very
accurate/specific questions to the list, which has a much higher chance
of being answered correctly.
Regards
Anders Fugmann
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2002-10-31 21:54 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-10-31 15:33 iptables, portforward, DNAT, SNAT Thomas Meindl
2002-10-31 16:39 ` Antony Stone
2002-10-31 16:47 ` Robert P. J. Day
-- strict thread matches above, loose matches on Subject: below --
2002-10-31 19:23 Thomas Meindl
2002-10-31 21:54 ` Anders Fugmann
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.