All of lore.kernel.org
 help / color / mirror / Atom feed
* bridge/firewall example
@ 2003-01-02  2:03 cc
  2003-01-02  8:00 ` Joel Newkirk
  0 siblings, 1 reply; 3+ messages in thread
From: cc @ 2003-01-02  2:03 UTC (permalink / raw)
  To: Netfilter Group

Hi,

This is my first time posting to this ML.  First, I want
to wish everyone a very Happy New Year. :)

Next, and quite coincidentially(or not), the first
thread I read was what I wanted to know about, amongst
other things.   Pardon my ignorance and stupidity, I'm
familiar with IPChains, but IPtables is a little tad
bit more complicated so some of my questions might
sound a tad bit..um.. stupid.

But just for clarification,  I'm using 2.4.20 (Slackware)
and using IPTABLES(probably redundant info).  I'm not
entirely familiar with the 2.4.x kernel system. (I'm
more or less familiar with the 2.2. version, but I figured
with a new system, I might as well try the newest stable
kernels.)


I currently have a LAN behind a router that's using
dynamic IP.  But within the next few days, we'll
be setting up a fixed IP (while still using the
dynamic one in parallel for backup for now).

I'm thinking of setting up a system to be the router/firewall for
the fixed IP until the dynamic IP plan expires. AFter that, I'll
remove the router functionality from the system and use it as
a strict firewall.  Can someone tell me whether or not this is
a good idea?

With bridging in place (according to the "Doing Bridge with firewall"
thread), the router's internal IP should belong to the same network
as the LAN, right?  Then the firewalling functionality of the bridge
system will still work?  (I too was a little confused on the issue
of bridging vs. NATing).

Is it necessary to even set up a bridge for the firewall system?

Also, just as an aside, I've setup a 'temporary test' setup where
this firewall system is within the LAN but hooked up to a test
machine whereby this test machine's IP is different from the
rest of the LAN (as follows:)

     test machine IP = 192.168.10.1
     firewall 'internal' IP  = 192.168.10.2    (eth0)
     firewall 'external' IP  = 192.168.11.120  (eth1 )
            (the LAN's network is 192.168.11.0)

     So far, with the following command:
#
# also including the necessary flushing of the iptables
#
/usr/sbin/iptables -A FORWARD -i eth0 -o eth1 -j MASQUERADE

   I can surf the web and check email, but I can't log in to the
LAN's network (Novell-based).   Now I realize that this might
defeat the functionality of the firewall, but is there a way
to allow Novell-packets through the firewall?  (It is only
temporary.  The real firewall won't allow Novell IPX packets
going through..)


Any clarifications appreciated.

Edmund




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

* Re: bridge/firewall example
  2003-01-02  2:03 bridge/firewall example cc
@ 2003-01-02  8:00 ` Joel Newkirk
  2003-01-03  7:34   ` Joel Newkirk
  0 siblings, 1 reply; 3+ messages in thread
From: Joel Newkirk @ 2003-01-02  8:00 UTC (permalink / raw)
  To: cc, Netfilter Group

On Wednesday 01 January 2003 09:03 pm, cc wrote:

> familiar with IPChains, but IPtables is a little tad
> bit more complicated so some of my questions might

bookmark the chunky HTML pages at:
http://iptables-tutorial.frozentux.net
and consider printing the PS version for mobile reference and spare-time 
reading on the go.

> I currently have a LAN behind a router that's using
> dynamic IP.  But within the next few days, we'll
> be setting up a fixed IP (while still using the
> dynamic one in parallel for backup for now).
>
> I'm thinking of setting up a system to be the router/firewall for
> the fixed IP until the dynamic IP plan expires. AFter that, I'll
> remove the router functionality from the system and use it as
> a strict firewall.  Can someone tell me whether or not this is
> a good idea?

Sounds fine to me personally, as long as your rules are tight and the box 
is secure.  Of course this is the desired situation regardless.  
Essentially you want the LAN talking to the new box, and you want it 
talking to the LAN and two 'external' connections.  The fact that one is 
a router with a dynamic IP on the 'outside' isn't really significant.  
Set up a NIC on the firewall box with a private IP on the LAN's subnet, 
a second with the static IP connection, and a third talking to the 
Dynamic IP router, with the third NIC and the router's local connection 
on a different subnet from the LAN.  Set up the new box with the default 
route specified as the static IP connection, or set up both connections 
with load-balancing to distribute communications between them.  ( 
http://lartc.org )  If you go with just one external connection you 
usually don't have to fiddle with routing at all.  If "until the dynamic 
IP plan expires" is only a short time away (weeks), and you're not 
already comfortable customising routing, my suggestion would be to just 
ditch it.  If it's going to be around for a reasonable time (months), 
then it's worth the time and effort now to learn how to set up the 
routing.

If you set up this new box as a gateway from the LAN to the new static 
connection, and the router with the Dynamic outside IP is still directly 
accessible by the LAN, you'll have problems.  You would need to specify 
either one or the other as the default gateway for the LAN clients.  If 
only the new box is gateway, then it can handle everything smoothly, 
likely without needing to touch anything on the LAN client machines. 
(Provided you give it the address those clients currently consider their 
default gateway)  This is probably desirable...  You could actually 
probably get away with leaving the current dynamic connection on the LAN 
wiring as is, but change to a different subnet for it, and set up two 
addresses on the internal NIC of the firewall box - one on the LAN and 
one on the new subnet.  As long as the router isn't promiscuously 
listening to all traffic, and the new box is assigned the LAN IP that 
was previously the inside connection on the router, this should work.  
It is NOT as secure, however, since it would be physically possible this 
way for a client to still talk to the router directly, instead of 
through the firewall.

> With bridging in place (according to the "Doing Bridge with firewall"
> thread), the router's internal IP should belong to the same network
> as the LAN, right?  Then the firewalling functionality of the bridge
> system will still work?  (I too was a little confused on the issue
> of bridging vs. NATing).

Do you mean the current router with the Dynamic IP, or the new box?  If 
the current router remains accessible directly by the LAN clients, then 
the firewall box will normally never see packets from the clients going 
out that connection.  Firewalling in the sense you seem to use it means 
functioning as a filtering gateway, right?  A single-point connection 
between the lan and the internet?  Technically the 'firewalling 
functionality' will work even if the box is the only thing hanging on 
the connection, since firewalling in the general sense is simply 
selectively filtering connections or packets or whatnot.  If the box 
also handles routing functions then firewalling extends to mean 
filtering of connections etc between different points, IE the LAN and 
the internet.  As long as the local client machines believe that this 
box is their pipeline (and their ONLY pipeline) to anything not within 
their subnet (they're configured with it as their gateway) then it's 
firewall can extend to protect them as well as the firewall box itself, 
since any traffic not local will be sent to it for forwarding.  If 
another possible route exist for them to communicate with the outside 
world (IE the present router remains on the same subnet) then the 
firewall will NOT protect them, since they will talk to the router 
directly without first going through the firewall.

If you have a box with IP's on two different subnets, and it passes 
communications between those subnets, you've essentially got a bridge.  
It's a router.  NAT is Network Address Translation, where you explicitly 
need to change the source or destination IP of data packets passing 
through. It only becomes necessary when some factor (like having a 
single-point connection to the internet for several machines) forces you 
to use a single IP address for several machines.  Like a single public 
internet-routable IP assigned, but several machines need to use it. 
That's SNAT, Source NAT.  Or when it is desirable to redirect 
connections somewhere other than the destination they originally were 
addressed to, with DNAT.  With iptables MASQUERADE is a special case of 
SNAT that automatically handles a dynamic IP situation, but 'masquerade' 
is also a general term for hiding several machines behind a single 
public IP.

> Is it necessary to even set up a bridge for the firewall system?

If you have a single subnet, and this box is the only connection point to 
anything outside that subnet, then just set up it's local IP as the 
gateway for the clients, set up SNAT for outbound packets in nat 
POSTROUTING, construct a filter FORWARD ruleset that allows the minimum 
necessary through, and set DROP policy for INPUT, OUTPUT, and FORWARD 
filter chains.  If the firewall box needs to communicate itself, then 
work in INPUT and OUTPUT chains in the filter table to ACCEPT the things 
you must allow in or out of the box's local processes.

> Also, just as an aside, I've setup a 'temporary test' setup where
> this firewall system is within the LAN but hooked up to a test
> machine whereby this test machine's IP is different from the
> rest of the LAN (as follows:)
>
>      test machine IP = 192.168.10.1
>      firewall 'internal' IP  = 192.168.10.2    (eth0)
>      firewall 'external' IP  = 192.168.11.120  (eth1 )
>             (the LAN's network is 192.168.11.0)
>
>      So far, with the following command:
> #
> # also including the necessary flushing of the iptables
> #
> /usr/sbin/iptables -A FORWARD -i eth0 -o eth1 -j MASQUERADE

If this is the command you are actually using it won't work.  MASQUERADE 
is a target that is only valid in the NAT table's POSTROUTING chain, 
just like the SNAT target.  You need to use it as:

/usr/sbin/iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Also, the MASQ target is ONLY used for a dynamic IP setup, since it 
incurs extra overhead to constantly check the IP of the outbound 
interface.  For static IP setup, with your test scenario, use:

/usr/sbin/iptables -t nat -A POSTROUTING -o eth1 SNAT --to 192.168.11.120

Your rule above is written to go into the FORWARD chain, and since no 
table is specified it defaults to filter table's FORWARD chain.  (there 
is also a FORWARD chain in the mangle table, but rarely used)  This is 
the one that you use to ACCEPT/DROP/REJECT packets forwarding back and 
forth between two machines outside the firewall box itself.  IE, if this 
is a router and a firewall/gateway to the internet then the filter 
FORWARD chain has to deal with packets from local A to local B, local to 
internet, and internet back to local.  Keep this multidirectionality in 
mind when writing rules for this chain, as this can easily trip you up 
when you allow all the connections in the world through, but only in one 
direction, or when you want more lenient rules for some things (like 
local to local routing) but forget to specify source/destination or 
in/out interface and leave things wide open for the connections you 
/think/ you've restricted tightly.

>    I can surf the web and check email, but I can't log in to the
> LAN's network (Novell-based).   Now I realize that this might
> defeat the functionality of the firewall, but is there a way
> to allow Novell-packets through the firewall?  (It is only
> temporary.  The real firewall won't allow Novell IPX packets
> going through..)

I'm not qualified on this one, but I suspect quite a bit may be necessary 
to set the box up as an IPX router, which I believe is what you'd need.  
If I'm right, then unless you need this in normal use, or want to learn 
how to do it, you might save yourself quite a bit of 
time/effort/headache if you just forego this part.  Again, this is 
uneducated speculation on my part here.

> Any clarifications appreciated.
>
> Edmund

j



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

* Re: bridge/firewall example
  2003-01-02  8:00 ` Joel Newkirk
@ 2003-01-03  7:34   ` Joel Newkirk
  0 siblings, 0 replies; 3+ messages in thread
From: Joel Newkirk @ 2003-01-03  7:34 UTC (permalink / raw)
  To: cc, Netfilter Group

On Thursday 02 January 2003 03:00 am, Joel Newkirk wrote:

[snipped down to my screwup]

> If you have a box with IP's on two different subnets, and it passes
> communications between those subnets, you've essentially got a bridge.
> It's a router.  NAT is Network Address Translation, where you

Sorry, I didn't finish this thought, I was cut'n'pasting all over the 
place.  That should read:
"(It's a router) living on two subnets, passing packets between them."

I guess I should re-read my posts an extra time before posting.  (or not 
read them after posting, and take the heat :^) (or maybe compose more 
concise messages, to ease proofreading...)

j



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

end of thread, other threads:[~2003-01-03  7:34 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-01-02  2:03 bridge/firewall example cc
2003-01-02  8:00 ` Joel Newkirk
2003-01-03  7:34   ` Joel Newkirk

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.