From: <bigman@monster-solutions.net>
To: Antony Stone <Antony@Soft-Solutions.co.uk>,
netfilter@lists.netfilter.org
Subject: Re: DHCRELAY through IPTABLES Firewall
Date: Mon, 28 Oct 2002 06:26:17 -0500 [thread overview]
Message-ID: <002c01c27e74$d989fb80$8f33e40f@lsmith5953> (raw)
In-Reply-To: 200210281054.g9SAsee08116@vulcan.rissington.net
my comments for each question are in BOLD... thanks for all of the help.
----- Original Message -----
From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
To: <netfilter@lists.netfilter.org>
Sent: Monday, October 28, 2002 5:54 AM
Subject: Re: DHCRELAY through IPTABLES Firewall
> On Monday 28 October 2002 10:36 am, bigman@monster-solutions.net wrote:
>
> > iptables -N lan1-in
> > iptables -N ext-int-in
> > iptables -N lan2-in
> > iptables -N lan1-lan2-fwd
> > iptables -N lan2-lan1-fwd
> > iptables -N ext-int-fwd
> > iptables -N lan1-ext-fwd
> > iptables -N lan2-ext-fwd
> > iptables -N lan1-lan2
> >
> > iptables -A INPUT -i eth1 -j lan1-in
> > iptables -A INPUT -i eth0 -j ext-int-in
> > iptables -A INPUT -i eth2 -j lan2-in
> >
> > iptables -A FORWARD -i eth1 -o eth2 -j lan1-lan2-fwd
> > iptables -A FORWARD -i eth2 -o eth2 -j lan2-lan1-fwd
>
> I don't like the look of that rule !
IT SHOULD BE -O ETH1 AND NOT -O ETH2
>
> > iptables -A FORWARD -i eth0 -j ext-int-fwd
> > iptables -A FORWARD -i eth1 -j lan1-ext-fwd
> > iptables -A FORWARD -i eth2 -j lan2-ext-fwd
> >
> > iptables -A OUTPUT -o eth2 -j lan1-lan2
>
> That seems like a strange name to use, but okay....
>
> > iptables -A OUTPUT -o eth0 -j ACCEPT
> > iptables -A OUTPUT -s 192.168.1.0/24 -j ACCEPT
>
> Presumably that rule is the one which allows packets from the firewall to
> eth1, since you don't have another rule specifically for that ?
>
> > iptables -A OUTPUT -p tcp -d x.x.x.x (ISP Assigned IP) -j ACCEPT
>
> What is this destination address ? (No, I don't mean tell me what it is
> numerically, I mean tell me which machine it belongs to and why you might
be
> sending packets there from your firewall.)
THIS IS JUST FOR MY OWN TESTING IS ALL.....
>
> > iptables -A ext-int-fwd -i eth0 -m state --state RELATED,ESTABLISHED -j
> > ACCEPT
> > iptables -A ext-int-fwd -i eth0 -j DROP
>
> Why are you specifying -i eth0 in these rules ? If a packet didn't come
in
> through eth0 it wouldn't get as far as the ext-int-fwd chain....
VERY VALID POINT!!!
>
> > iptables -A ext-int-in -i eth0 -m state --state RELATED,ESTABLISHED -j
> > ACCEPT
> > iptables -A ext-int-in -i eth0 -j DROP
>
> Same comment again - why bother to specify -i eth0 ?
>
> In fact, I'd make the same comment for virtually all the following rules.
> You've already specified the input & output interfaces when selecting the
> packets to go to these chains, so why do it all again ?
>
> > iptables -A lan1-ext-fwd -i eth1 -m state --state
NEW,RELATED,ESTABLISHED
> > -j ACCEPT
> > iptables -A lan1-ext-fwd -i eth1 -j DROP
> >
> > iptables -A lan1-in -i eth1 -s 192.168.1.0/24 -j ACCEPT
> > iptables -A lan1-in -i eth1 -j DROP
> >
> > iptables -A lan1-lan2 -p udp -o eth2 --dport 68 -j ACCEPT
> > iptables -A lan1-lan2 -o eth2 -d 192.168.2.0/24 -m state --state
> > RELATED,ESTABLISHED -j ACCEPT
> > iptables -A lan1-lan2 -j DROP
> >
> > iptables -A lan1-lan2-fwd -o eth2 -d 192.168.2.0/24 -m state --state
> > RELATED,ESTABLISHED -j ACCEPT
> > iptables -A lan1-lan2-fwd -o eth2 -j DROP
> >
> > iptables -A lan2-ext-fwd -i eth2 -m state --state
NEW,RELATED,ESTABLISHED
> > -j ACCEPT
> > iptables -A lan2-ext-fwd -i eth2 -j DROP
> >
> > iptables -A lan2-in -i eth2 -p udp --dport 67 -j ACCEPT
> > iptables -A lan2-in -i eth2 -s 192.168.2.0/24 -j ACCEPT
> > iptables -A lan2-in -i eth2 -j DROP
> >
> > iptables -A lan2-lan1-fwd -i eth2 -o eth1 -j ACCEPT
> > iptables -A lan2-lan1-fwd -i eth2 -o eth1 -j DROP
> >
> > iptables -t nat -A POSTROUTING -o eth0 -s 192.168.0.0/16 -j MASQUERADE
>
> Well, aside from my very first comment above, I can't see anything else
which
> I'd expect to cause your problem, so the best thing might be to add a
LOGging
> rule just before the DROP rule in each of your lan1-lan2-fwd and
> lan2-lan1-fwd chains so you can see if anything's being blocked...
SO DHCRELAY WILL USE FORWARDING INSTEAD OF OUTPUT AND INPUT FOR IT TO WORK?
>
>
> Antony.
>
> --
>
> Anything that improbable is effectively impossible.
>
> - Murray Gell-Mann, Nobel Prizewinner in Physics
>
next prev parent reply other threads:[~2002-10-28 11:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-27 4:33 DHCRELAY through IPTABLES Firewall bigman
2002-10-27 8:09 ` Antony Stone
2002-10-27 8:58 ` bigman
2002-10-28 8:49 ` Antony Stone
2002-10-28 10:36 ` bigman
2002-10-28 10:54 ` Antony Stone
2002-10-28 11:26 ` bigman [this message]
2002-10-28 11:39 ` Antony Stone
2002-10-29 7:37 ` bigman
2002-10-29 9:15 ` Antony Stone
2002-10-29 11:20 ` bigman
2002-10-29 13:03 ` Antony Stone
2002-10-30 0:30 ` bigman
2002-10-30 0:41 ` Antony Stone
2002-10-30 7:15 ` bigman
2002-10-29 10:02 ` bigman
2002-10-29 10:29 ` Antony Stone
2002-10-29 11:44 ` bigman
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='002c01c27e74$d989fb80$8f33e40f@lsmith5953' \
--to=bigman@monster-solutions.net \
--cc=Antony@Soft-Solutions.co.uk \
--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.