All of lore.kernel.org
 help / color / mirror / Atom feed
* problem with forward/nat
@ 2004-03-07  3:13 Pierre Gillet
  2004-03-07  9:26 ` Antony Stone
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Pierre Gillet @ 2004-03-07  3:13 UTC (permalink / raw)
  To: netfilter; +Cc: gpg.gpg

hello,

i have a small private network, 192.168.1.0 on eth1
public network on eth0. the server running a dhcp server for private 
network.

system: SuSE 9.0Pro, iptables 1.2.8

my script:
echo "1" > /proc/sys/net/ipv4/ip_forward

#vidage des tables
iptables -F
iptables -X

#policies par defaut
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

#autorise boucle locale

iptables -A OUTPUT -o lo -m state --state RELATED,ESTABLISHED,NEW -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --dport 443 -j ACCEPT
iptables -A OUTPUT -o eth0 -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -o eth1 -d 192.168.1.0/24 -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --dport 23 -j ACCEPT

iptables -A INPUT -i lo -m state --state RELATED,ESTABLISHED,NEW -j ACCEPT
iptables -A INPUT -i eth0 -p udp --sport 53 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --sport 80 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --sport 443 -j ACCEPT
iptables -A INPUT -i eth1 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --sport 23 -j ACCEPT

#forward

iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE
iptables -A FORWARD -s 192.168.1.0/24 -j ACCEPT -o eth0
#iptables -A FORWARD -i eth0 -o eth0 -m state --state ESTABLISHED,RELATED -j 
ACCEPT

modules are here:
ls /lib/modules/`uname -r`/kernel/net/ipv4/netfilter/
ip_queue.o            ipt_ULOG.o       ipt_pkttype.o
ip_tables.o           ipt_ah.o         ipt_psd.o
arp_tables.o          ipchains.o       ipt_conntrack.o  ipt_state.o
arptable_filter.o     ipfwadm.o        ipt_dscp.o       ipt_string.o
ip_conntrack.o        ipt_DSCP.o       ipt_ecn.o        ipt_tcpmss.o
ip_conntrack_amanda.o ipt_ECN.o        ipt_esp.o        ipt_tos.o
ip_conntrack_ftp.o    ipt_LOG.o        ipt_helper.o     ipt_ttl.o
ip_conntrack_irc.o    ipt_MARK.o       ipt_iplimit.o    ipt_unclean.o
ip_conntrack_tftp.o   ipt_MASQUERADE.o ipt_length.o  iptable_filter.o
ip_nat_amanda.o       ipt_MIRROR.o     ipt_limit.o   iptable_mangle.o
ip_nat_ftp.o          ipt_REDIRECT.o    ipt_mac.o      iptable_nat.o
ip_nat_irc.o          ipt_REJECT.o      ipt_mark.o
ip_nat_snmp_basic.o   ipt_TCPMSS.o      ipt_multiport.o
ip_nat_tftp.o         ipt_TOS.o         ipt_owner.o

problem:
pc firewall can acces on web
pc firewall can acces in private network
private network can acces in pc firewall
private network CAN'T acces on web

i sniff on eth0 and eth1, request from private network are sniffed in eth1 
but not transmiet on eth0, it cant go out.

can you help / explain to me?

sorry for my very bad english and thank you for your help

Pierre
gpg__gpg@hotmail.com

_________________________________________________________________
Calendrier Pirelli, les top modèles de mars... 
http://automobile.fr.msn.be/pirelli2004/mars2/



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: problem with forward/nat
  2004-03-07  3:13 problem with forward/nat Pierre Gillet
@ 2004-03-07  9:26 ` Antony Stone
  2004-03-07  9:46   ` Antony Stone
  2004-03-07 14:47 ` Brad Morgan
  2004-03-07 18:24 ` Fabian Hartmann
  2 siblings, 1 reply; 8+ messages in thread
From: Antony Stone @ 2004-03-07  9:26 UTC (permalink / raw)
  To: netfilter

On Sunday 07 March 2004 3:13 am, Pierre Gillet wrote:

> hello,
>
> i have a small private network, 192.168.1.0 on eth1
> public network on eth0. the server running a dhcp server for private
> network.
>
> #iptables -A FORWARD -i eth0 -o eth0 -m state --state ESTABLISHED,RELATED
> -j ACCEPT

1. Why have you commented out the above command?   It is necessary for teh 
reply packets to be able to return from the Internet to your LAN clients.

2. The above command should read "-i eth0 -o eth1" so that packets are allowed 
from the Internet (eth0) to your LAN (eth1).

I would recommend also that you change all your INPUT rules:

> iptables -A INPUT -i lo -m state --state RELATED,ESTABLISHED,NEW -j ACCEPT
> iptables -A INPUT -i eth0 -p udp --sport 53 -j ACCEPT
> iptables -A INPUT -i eth0 -p tcp --sport 80 -j ACCEPT
> iptables -A INPUT -i eth0 -p tcp --sport 443 -j ACCEPT
> iptables -A INPUT -i eth1 -s 192.168.1.0/24 -j ACCEPT
> iptables -A INPUT -i eth0 -p tcp --sport 23 -j ACCEPT

For a single rule instead:

> iptables -A INPUT -m state --state RELATED,ESTABLISHED,NEW -j ACCEPT

This will allow reply packets from anywhere in response to requests sent out 
by the firewall itself, without leaving your system vulnerable to, for 
example, port scans or access to services where the remote user just 
"happens" to select source port 443 (or any of the others you have listed).

Regards,

Antony.

-- 
This email is intended for the use of the individual addressee(s) named above 
and may contain information that is confidential, privileged or unsuitable 
for overly sensitive persons with low self-esteem, no sense of humour, or 
irrational religious beliefs.

If you have received this email in error, you are required to shred it 
immediately, add some nutmeg, three egg whites and a dessertspoonful of 
caster sugar.   Whisk until soft peaks form, then place in a warm oven for 40 
minutes.   Remove promptly and let stand for 2 hours before adding some 
decorative kiwi fruit and cream.   Then notify me immediately by return email 
and eat the original message.

                                                     Please reply to the list;
                                                           please don't CC me.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: problem with forward/nat
  2004-03-07  9:26 ` Antony Stone
@ 2004-03-07  9:46   ` Antony Stone
  0 siblings, 0 replies; 8+ messages in thread
From: Antony Stone @ 2004-03-07  9:46 UTC (permalink / raw)
  To: netfilter

On Sunday 07 March 2004 9:26 am, Antony Stone wrote:

> I would recommend also that you change all your INPUT rules:
>
> For a single rule instead:
> > iptables -A INPUT -m state --state RELATED,ESTABLISHED,NEW -j ACCEPT

Sorry!   I did *not* mean to leave the "NEW" in that rule!!

It should read:

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

It's too early in the morning for me - I shouldn't be answering technical 
questions yet :-)

Antony.

-- 
There are two possible outcomes:

 If the result confirms the hypothesis, then you've made a measurement.
 If the result is contrary to the hypothesis, then you've made a discovery.

 - Enrico Fermi

                                                     Please reply to the list;
                                                           please don't CC me.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: problem with forward/nat
  2004-03-07  3:13 problem with forward/nat Pierre Gillet
  2004-03-07  9:26 ` Antony Stone
@ 2004-03-07 14:47 ` Brad Morgan
  2004-03-07 15:03   ` Antony Stone
  2004-03-07 18:24 ` Fabian Hartmann
  2 siblings, 1 reply; 8+ messages in thread
From: Brad Morgan @ 2004-03-07 14:47 UTC (permalink / raw)
  To: 'Pierre Gillet', netfilter; +Cc: gpg.gpg

> my script:
> echo "1" > /proc/sys/net/ipv4/ip_forward
> 
> #vidage des tables
> iptables -F
> iptables -X
> 
> #policies par defaut
> iptables -P INPUT DROP
> iptables -P OUTPUT DROP
> iptables -P FORWARD DROP
> 
> #autorise boucle locale
> 
> iptables -A OUTPUT -o lo -m state --state RELATED,ESTABLISHED,NEW -j
> ACCEPT
> iptables -A OUTPUT -o eth0 -p tcp --dport 80 -j ACCEPT
> iptables -A OUTPUT -o eth0 -p tcp --dport 443 -j ACCEPT
> iptables -A OUTPUT -o eth0 -p udp --dport 53 -j ACCEPT
> iptables -A OUTPUT -o eth1 -d 192.168.1.0/24 -j ACCEPT
> iptables -A OUTPUT -o eth0 -p tcp --dport 23 -j ACCEPT
> 
> iptables -A INPUT -i lo -m state --state RELATED,ESTABLISHED,NEW -j ACCEPT
> iptables -A INPUT -i eth0 -p udp --sport 53 -j ACCEPT
> iptables -A INPUT -i eth0 -p tcp --sport 80 -j ACCEPT
> iptables -A INPUT -i eth0 -p tcp --sport 443 -j ACCEPT
> iptables -A INPUT -i eth1 -s 192.168.1.0/24 -j ACCEPT
> iptables -A INPUT -i eth0 -p tcp --sport 23 -j ACCEPT
> 
> #forward
> 
> iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE
> iptables -A FORWARD -s 192.168.1.0/24 -j ACCEPT -o eth0
> #iptables -A FORWARD -i eth0 -o eth0 -m state --state ESTABLISHED,RELATED
> -j
> ACCEPT
>
> problem:
> pc firewall can acces on web
> pc firewall can acces in private network
> private network can acces in pc firewall
> private network CAN'T acces on web
>

The first problem I see is that you allow ESTABLISHED,RELATED,NEW in your
INPUT and OUTPUT chains.  Once you hit that rule, the only thing going past
are INVALID packets so the rest of the INPUT and OUTPUT chains aren't doing
anything useful.

The second problem I see is the FORWARD chain has "-i eth0 -o eth0" on the
ESTABLISHED,RELATED rule which can't be right.  All the packets on the
FORWARD chain are going to be either "-i eth0 -o eth1" or "-i eth1 -o eth0".

Since your private address space (192.168.1.0/24) shouldn't exist on the
outside, there's little need to specify both the address and the interface
in your rules.

It looks like you have rules in your INPUT and OUTPUT chains intended to
pass traffic through the firewall.  Only packets directed at the firewall go
through INPUT and only packets generated by the firewall go through OUTPUT.
Packets passing through the firewall are seen on FORWARD.  

Look at (make that study!) the tutorial, including a nice diagram (in
"Traversing of Tables and Chains"), written by Oskar Andreasson at
http://iptables-tutorial.frozentux.net.  

Here's what I suggest to help get you going...

Change your default policies to ACCEPT (temporarily).

# Keep this
iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE

The first two rules in each chain should be:

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -m state --state INVALID -j DROP

iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state INVALID -j DROP

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

Now the only packets the rest of the rules in each chain see are state NEW.

Add your rules one at a time and check the packet counts using the command:

iptables -nvL

If you add a rule for web traffic and then surf the web.  The rule should
have a count associated with it.  If not, then the rule isn't doing what you
expect!

When all the rules you add have counts then you can change the default
policies back to DROP and your firewall is complete.  Optionally you can add
the following to the end of each chain so when something doesn't work, you
can examine the firewall syslog to see what went wrong.  Make sure if you do
this that you have set up some kind of log rotation so you don't fill the
disk up with log files.

#
# Log whats left before dropping (should be last rule in each chain)
#
iptables -A FORWARD -m limit --limit 20/minute -j LOG --log-level \
notice --log-prefix "[FORWARD] "

iptables -A INPUT -m limit --limit 20/minute -j LOG --log-level \
notice --log-prefix "[INPUT] "

iptables -A OUTPUT -m limit --limit 20/minute -j LOG --log-level \
notice --log-prefix "[OUTPUT] "





^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: problem with forward/nat
  2004-03-07 14:47 ` Brad Morgan
@ 2004-03-07 15:03   ` Antony Stone
  2004-03-07 15:57     ` Brad Morgan
  0 siblings, 1 reply; 8+ messages in thread
From: Antony Stone @ 2004-03-07 15:03 UTC (permalink / raw)
  To: netfilter

On Sunday 07 March 2004 2:47 pm, Brad Morgan wrote:

> > iptables -A OUTPUT -o lo -m state --state RELATED,ESTABLISHED,NEW -j
> > ACCEPT
> >
> > iptables -A INPUT -i lo -m state --state RELATED,ESTABLISHED,NEW -j
> > ACCEPT
>
> The first problem I see is that you allow ESTABLISHED,RELATED,NEW in your
> INPUT and OUTPUT chains.

Only to/from interface lo (see above).

>  Once you hit that rule, the only thing going past
> are INVALID packets so the rest of the INPUT and OUTPUT chains aren't doing
> anything useful.

No, the other rules are dealing with packets to interfaces other than lo.

> The second problem I see is the FORWARD chain has "-i eth0 -o eth0" on the
> ESTABLISHED,RELATED rule which can't be right.  All the packets on the
> FORWARD chain are going to be either "-i eth0 -o eth1" or "-i eth1 -o
> eth0".

Agreed, however a more fundamental problem with this rule is that it is 
commented out and therefore non-functional:

> > #iptables -A FORWARD -i eth0 -o eth0 -m state --state ESTABLISHED,RELATED
> > -j ACCEPT

> Since your private address space (192.168.1.0/24) shouldn't exist on the
> outside, there's little need to specify both the address and the interface
> in your rules.

Lots of people like to do that on the basis that you can't have too much 
security, and just in case someone outside does manage to send you a packet 
from your own address space, you'd rather your system didn't try to respond 
to it.

> It looks like you have rules in your INPUT and OUTPUT chains intended to
> pass traffic through the firewall.  Only packets directed at the firewall
> go through INPUT and only packets generated by the firewall go through
> OUTPUT. Packets passing through the firewall are seen on FORWARD.

Agreed - I wasn't sure when looking at Pierre's ruleset whether he was 
completely clear about the difference between INPUT/OUTPUT and FORWARD.

> Look at (make that study!) the tutorial, including a nice diagram (in
> "Traversing of Tables and Chains"), written by Oskar Andreasson at
> http://iptables-tutorial.frozentux.net.
>
> Here's what I suggest to help get you going...

I agree with the remainder of your suggestions - they should help Pierre get 
his firewall working, and understand how/why at the same time.

Regards,

Antony.

-- 
"The joy of X!!??  I've always hated compiling graphical shite.  You have a 10 
line program, and it ends up depending on the entire known universe."

 - Philip Hands

                                                     Please reply to the list;
                                                           please don't CC me.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: problem with forward/nat
  2004-03-07 15:03   ` Antony Stone
@ 2004-03-07 15:57     ` Brad Morgan
  0 siblings, 0 replies; 8+ messages in thread
From: Brad Morgan @ 2004-03-07 15:57 UTC (permalink / raw)
  To: 'Antony Stone', netfilter

> >  Once you hit that rule, the only thing going past
> > are INVALID packets so the rest of the INPUT and OUTPUT chains aren't
> doing
> > anything useful.
> 
> No, the other rules are dealing with packets to interfaces other than lo.

Opps, I missed the lo!  That means there is no ESTABLISHED,RELATED rule for
the Ethernet traffic.  My suggestions remove the lo interface which fixes
that.

So for local traffic add the rule:

iptables -A INPUT -i lo -j ACCEPT

just after the drop of INVALID state packets.  Since I leave the OUTPUT
default policy as ACCEPT, I don't have an OUTPUT rule for lo but it would
probably be:

iptables -A OUTOUT -o lo -j ACCEPT

again placed just after the drop of INVALID state packets.




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: problem with forward/nat
  2004-03-07  3:13 problem with forward/nat Pierre Gillet
  2004-03-07  9:26 ` Antony Stone
  2004-03-07 14:47 ` Brad Morgan
@ 2004-03-07 18:24 ` Fabian Hartmann
  2004-03-07 18:37   ` Antony Stone
  2 siblings, 1 reply; 8+ messages in thread
From: Fabian Hartmann @ 2004-03-07 18:24 UTC (permalink / raw)
  To: netfilter; +Cc: Pierre Gillet

> hello,
>
Hi Pierre

> #forward
> 
> iptables -A FORWARD -s 192.168.1.0/24 -j ACCEPT -o eth0

The rule above won't work! you must set the -o flag before you set the -j <TARGET>
i. e. iptables -A FORWARD -o eth0 -s 192.168.1.0/24 -j ACCEPT

Otherwise the rule won't be accepted by iptables and you have no rule that
accepts  forwarded traffic when the default policy for the FORWARD chain is set
to DROP.

---
Fabian Hartmann

realdeal@realdealz.ch
www.realdealz.ch


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: problem with forward/nat
  2004-03-07 18:24 ` Fabian Hartmann
@ 2004-03-07 18:37   ` Antony Stone
  0 siblings, 0 replies; 8+ messages in thread
From: Antony Stone @ 2004-03-07 18:37 UTC (permalink / raw)
  To: netfilter

On Sunday 07 March 2004 6:24 pm, Fabian Hartmann wrote:

> > hello,
>
> Hi Pierre
>
> > #forward
> >
> > iptables -A FORWARD -s 192.168.1.0/24 -j ACCEPT -o eth0
>
> The rule above won't work! you must set the -o flag before you set the -j
> <TARGET> i. e. iptables -A FORWARD -o eth0 -s 192.168.1.0/24 -j ACCEPT

My netfilter accepts it perfectly well, and afterwards "iptables -L FORWARD 
-nvx" shows:

pkts   bytes target    prot opt in     out     source              destination
   0     0 ACCEPT    all  --  *      eth0    192.168.1.0/24       0.0.0.0/0

> Otherwise the rule won't be accepted by iptables and you have no rule that
> accepts  forwarded traffic when the default policy for the FORWARD chain is
> set to DROP.

Let me know which version of netfilter you have a problem with using the above 
syntax - admittedly it's non-standard, but it seems to work okay.

Antony.

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

                                                     Please reply to the list;
                                                           please don't CC me.



^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2004-03-07 18:37 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-03-07  3:13 problem with forward/nat Pierre Gillet
2004-03-07  9:26 ` Antony Stone
2004-03-07  9:46   ` Antony Stone
2004-03-07 14:47 ` Brad Morgan
2004-03-07 15:03   ` Antony Stone
2004-03-07 15:57     ` Brad Morgan
2004-03-07 18:24 ` Fabian Hartmann
2004-03-07 18:37   ` Antony Stone

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.