From: "Eric Poulin" <epoulin@onepost.net>
To: netfilter@lists.netfilter.org
Subject: Re: Output Chain Problem...
Date: Fri, 18 Jun 2004 09:28:11 -0400 [thread overview]
Message-ID: <009b01c45538$1ab69780$800101df@lvl.digidyne.ca> (raw)
In-Reply-To: 200406181402.51862.Antony@Soft-Solutions.co.uk
Good Day Anthony
> > Now, packet flow through a chain from top to bottom, and will hit
the
> > Default Policy if no rules are match... My first test was to put those
> > rules in my output chain(That was completly empty before).
> >
> > iptables -A OUTPUT -p ALL -s 127.0.0.1 -j ACCEPT
> > iptables -A OUTPUT -p ALL -s 192.168.0.0/24 -j ACCEPT
> > iptables -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
>
> That second rule suggests to me that you are slightly mistaken about what
> packets go through the OUTPUT chain - you have allowed all packets sourced
> from an entire Class C, so I suspect you think that all packets from your
> local network, which pass through the Firewall, are traversing the OUTPUT
> chain?
Not really, I got several virtual IP on my NIC facing the internal Network,
so some packet will sent from my firewall(like those coming from it while
i'm doing ssh in it), and I have decided to set the entire subnet. Remember
this is a test, I'm doing large rule to make it works first...
>
> In fact, the only packets which go through OUTPUT are those originating on
the
> machine itself - any which are being routed through it go through FORWARD
> instead (and they don't go through INPUT, either...).
Like I said, I'm troubleshooting a ssh connection between internal machines
and my firewall, since I'm allowing ssh from the inside only towards the
firewall. I need to accept some data on my OUTPUT chain to receive response
from my Firewall.
> > After this, I did try to set the Default policy to drop...
Strangely, I
> > lost my ssh connection(but as expected, all my NAT rules continued to
work
> > perfectly).
>
> Do you mean for connections which were already in place (ESTABLISHED), or
new
> ones which you set up after changing the rules? Bear in mind that
existing
> connections will largely be handled in the background, rather than by your
> ruleset - most rules only apply to the first packets of new connections.
iptables -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
This rule accept all of them actual, which is pretty similar to accept
everything with checking the state. (I believe).
> > To my surprise, nothing seems to hit my LOG rule, and even the
overall
> > ACCEPT rule... But again, as soon as I change the default policy to
DROP, I
> > can't communicate with the box.
>
> And when that happens, do you get any packets LOGged before being DROPped?
> I'm not too surprised nothing gets logged when it's working (as I
explained
> above, those will probably be established connections), however I *would*
> expect something to get logged when you cannot connect. Basically, you
want
> to log when there's a problem, not when it's working fine :)
The problem can be simplify as the following. Everything is fine now,
because my Default Policy is set to ACCEPT. Following "Best Practices", I
would prefer to set it to "DROP" and only allow what I need. The problem is
that I have rules that ACCEPT my ssh response packet form the firewall
perfectly. PLease check the counters:
Chain OUTPUT (policy ACCEPT 19 packets, 2060 bytes)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- * * 127.0.0.1
0.0.0.0/0
3543 625244 ACCEPT all -- * * 192.168.0.0/24
0.0.0.0/0
36 3240 ACCEPT all -- * * 66.11.160.119
0.0.0.0/0
6 1948 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state NEW,RELATED,ESTABLISHED
0 0 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0
0.0.0.0/0 LOG flags 0 level 4 prefix `Output:'
The second rule accept almost everything. Witness the counters for the last
2 rules, they are set to ZERO. This means that all packets are being
ACCEPTed in the first 4 rules, therefor, it shouldn't hit the bottom of the
chain, making the Default Policy to apply. If I set the Default policy to
drop with iptables -P OUTPUT DROP, I'm loosing my ssh connection, which
means that a packet HIT the Default Policy, which is at the bottom of the
chain, under my LOG rule.... But since nothing is logged, the packet is
being accepted before, so it shoudn't hit the Default policy.
If I put back the default output policy to ACCEPT, everything is fine... I
don't know if you understand my point, or if I'm wrong...
Eric
next prev parent reply other threads:[~2004-06-18 13:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-18 12:44 Output Chain Problem Eric Poulin
2004-06-18 13:02 ` Antony Stone
2004-06-18 13:28 ` Eric Poulin [this message]
2004-06-18 14:49 ` Antony Stone
2004-06-18 15:47 ` Output Chain Problem... (nfcan: addressed to exclusive sender for this address) Jim Laurino
2004-06-18 15:49 ` Jim Laurino
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='009b01c45538$1ab69780$800101df@lvl.digidyne.ca' \
--to=epoulin@onepost.net \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.