From: "Shaun T. Erickson" <ste@smxy.org>
To: Jason Opperisano <Jopperisano@alphanumeric.com>
Cc: netfilter@lists.netfilter.org
Subject: Re: Need to replace a SonicWall firewall with an iptables firewall.
Date: Mon, 30 Aug 2004 16:23:52 -0400 [thread overview]
Message-ID: <41338CD8.30603@smxy.org> (raw)
In-Reply-To: <D5C9032B2B09C64EA2409D6214E91AC9051304@asimail2.alphanumeric.com>
>>I believe I know how to set it up so that traffic from either internal
>>LAN gets NAT'd to the firewall's external IP address, for traffic headed
>>to the Internet, and de-NAT'd on the way back. I also believe I know how
>>to allow traffic to flow back and forth between the two LANs, where
>>NAT'ing isn't needed.
>
>
> just to be clear:
>
> iptables -t nat -A POSTROUTING -o $EXTERNAL_IF \
> -s $INTERNAL_NET_1 -j SNAT --to-source $EXTERNAL_IP
>
> iptables -t nat -A POSTROUTING -o $EXTERNAL_IF \
> -s $INTERNAL_NET_2 -j SNAT --to-source $EXTERNAL_IP
Ok, and I know how to do the inter-LAN stuff, as I'm doing it on the
current linux box, where the database LAN is substantially firewalled
off from the corporate LAN and everything else.
>>However, I'm not sure how to handle the external network and the DMZ. We
>>have a /28 subnet from our ISP. Our router uses one address on the
>>subnet. From the router, you proceed to a switch, where three devices
>>are plugged in: a wireless access point, a VPN device, and the external
>>interface of the SonicWall firewall. All three devices have addresses on
>>the same /28 subnet as the router. Additionally, the SonicWall's DMZ
>>interface does not have and address assigned to it - it is somehow
>>logically bridged to the external interface. The systems in the DMZ are
>>also on the same /28 subnet. You tell the SonicWall which IP addresses
>>are in use in the DMZ, so that it knows which interface to send traffic
>>for that subnet out of. Internal traffice, heading out either the
>>external or DMZ interfaces of the SonicWall, appear to come from the
>>external address of the SonicWall. I have no idea how to replicate this
>>setup under iptables.
>
>
> if you desire to replicate this exactly with netfilter, you would create
> a bridge between the external and DMZ interfaces (man 8 brctl), and use
> ebtables to do the bridge filtering (http://ebtables.sourceforge.net/).
Ok.
> your other option could be to leave the /28 of public space outside the
> firewall, re-address the DMZ hosts to use private space, and setup
> one-to-one NATs for the DMZ hosts, and keep your firewall solely layer 3
> (my bias--i love the routing).
I like this idea better, but I'm confused about a couple of things.
First, I've never done one-to-one NAT, but I'm sure I can look that up.
Second, will I require any special rules to allow internal LAN hosts to
access the DMZ systems by their public IP addresses? I want to be sure
internal systems access them the same way as external systems. Third,
when I write rules for what access is allowed to what systems in the DMZ
from either the Internet or the LANs, what do I write the rule against:
the real, pulic IP of the DMZ server, or it's private IP address?
>>Lastly, some systems in the DMZ need to access database servers on one
>>of the internal LANs. The LANs use private, non-routable address space
>>(192.168.32.0 & 192.168.40.0). So, I need certain systems in the DMZ, to
>>be able to initiate connections through the firewall, to systems on my
>>40-net. No NAT'ing is needed for these connections, but I'm not sure how
>>to set them up, either. On the SonicWall, we just put a rule in that
>>allows it, and two static routes, so it knows to forward traffic for
>>those nets to the linux box. Somehow I think it isn't as simple under
>>iptables, but hopefully I'm wrong.
>
>
> well--the linux box in the new scenario will be directly connected to those LANs (as it is now)--so you won't need static routes to them. you will need rules that allow the DMZ hosts to connect, though:
>
> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> iptables -A FORWARD -i $DMZ_IF -o $LAN_IF1 -p tcp --syn \
> -s $DMZ_HOST --sport 1024:65535 -d $LAN_HOST --dport $DB_PORT -j ACCEPT
>
> [ repeat as necessary ]
Ok.
> let me know what i missed.
So far, so good. I may have more questions after your reply. :) Thanks
for your help. :)
-ste
next prev parent reply other threads:[~2004-08-30 20:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-30 19:30 Need to replace a SonicWall firewall with an iptables firewall Jason Opperisano
2004-08-30 20:23 ` Shaun T. Erickson [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-08-31 14:11 Jason Opperisano
2004-08-30 22:25 Jason Opperisano
2004-08-31 13:47 ` Shaun T. Erickson
2004-08-30 22:23 Daniel Chemko
2004-08-31 0:02 ` Nick Drage
2004-08-30 20:45 Jason Opperisano
2004-08-30 20:41 Jason Opperisano
2004-08-30 21:11 ` Shaun T. Erickson
2004-08-30 16:01 Shaun T. Erickson
2004-08-30 18:41 ` Shaun T. Erickson
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=41338CD8.30603@smxy.org \
--to=ste@smxy.org \
--cc=Jopperisano@alphanumeric.com \
--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