Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Tom Van Overbeke <tvanoverbeke@ccncsi.net>
To: "Netfilter (E-mail)" <netfilter@lists.netfilter.org>
Subject: daisy chaining firewalls causes connection tracking problems ?
Date: Tue, 12 Aug 2003 15:38:40 +0200	[thread overview]
Message-ID: <000501c360d7$0b5f5ca0$d90315ac@rsrc.be.local> (raw)

Hi,


I'm faced with an environment where there are 3 iptables firewalls directly
connected to one another. I have a few servers on one end, that need to talk
to servers on the other end of the 3 firewalls. (we use fwbuilder to
maintain the firewalls).

normally, i have no problems adding stateful rules to enable/disable
traffic, but in this case, i seem to either have hit a bug, or maybe a
limitation of iptables ???


my case:

i need to have a server talk to our backup server via an agent. we know
which ports the backup app uses, and have before succesfully changed our
firewall to enable backups on previous occasions.

now, with 3 firewalls in between, i thought i could just use the exact 3
rules and put them on each firewall, and it should work.


but ... it doesn't. on one of the outer firewalls, i see that the session
setup packets (ACK SYN bits are set) is being blocked.


i had already solved a similar problem (with big brother) by doing it the
'ipchains' way, that is creating a rule for the traffic in each direction,
and disabling the 'statefulness' of the rule. obviously, i'm not too happy
with this solution, so I'd thought i ask you guys if the connection tracking
might have problems with multiple firewalls chained together ?



thx,


Tom.





****************************************************************************
Disclaimer: 
This electronic transmission and any files attached to it are strictly 
confidential and intended solely for the addressee. If you are not 
the intended addressee, you must not disclose, copy or take any
action in reliance of this transmission. If you have received this 
transmission in error, please notify the sender by return and delete
the transmission.  Although the sender endeavors to maintain a
computer virus free network, the sender does not warrant that this
transmission is virus-free and will not be liable for any damages 
resulting from any virus transmitted. 
Thank You.
****************************************************************************



             reply	other threads:[~2003-08-12 13:38 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-12 13:38 Tom Van Overbeke [this message]
2003-08-12 14:14 ` daisy chaining firewalls causes connection tracking problems ? Ramin Dousti
2003-08-13 11:46   ` Tom Van Overbeke
2003-08-15  2:15 ` BroadCast, Multicast and Unicast sarky
2003-08-15  9:52   ` Chris Wilson

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='000501c360d7$0b5f5ca0$d90315ac@rsrc.be.local' \
    --to=tvanoverbeke@ccncsi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox