|Main Archive Page > Month Archives > shorewall-users archives|
Vieri Di Paola wrote:
>I configured a shorewall system as a bridge with an IP address. The
>bridge is a firewall in between two LANs (say, loc and net). There's
>a router within "loc" connecting to a remote network (at IP address
>10.215.144.6). Almost all client systems have custom routes to send
>packets appropriately to this router in the "loc" zone. The default
>gateway is the shorewall bridge which then sends the packets to
>another router/gateway in the "net" zone (I'm using the "bridge" as
>The shorewall bridge has the same routing rules set to the router in
>the "loc" zone because it sometimes needs to access that remote
>network (see routing table).
>Everything was working fine until I stumbled on a video-conferencing
>machine that cannot set routes (its web config only allows setting a
>default gateway which is now set to the shorewall bridge IP
>address). If the routing table is correct on the shorewall
>bridge/gateway then I think that a host with just that default
>gateway should route its way to the remote network via the router in
>the "loc" zone.
>My bridge setup is as in the guide:
>I'm attaching the shorewall dump (old SW version).
>The network is like this (BRIDGE* is the system I'm reporting on):
><ISPs>---<GW>--[net zone]--<BRIDGE*>--[loc zone]--<Router 1>---<network 1>
> \--<Router 2>---<network 2>
>If I ping from a "loc" host to another host behind a "loc" router
>(eg. router 1) then I get arp who-has messages on both the
>bridge/gateway and the "loc" router.
>Can I setup shorewall on the gateway/bridge so that clients do not
>need to define routes?
>I hope I was clear enough.
Firstly, I don't see why you have the shorewall box set as the
default gateway - it isn't a gateway for any traffic and so you are
forcing most traffic to be handled twice.
Basically, you do not need to set routes on ANY client as long as
your network routers are correctly configured - if they aren't then
fix that, if they don't support it, bin them and get something that
qualifies as a router !
So, on the router labelled as <GW>, configure routes to network 1 and
network 2 via their Router 1 and Router 2 respectively. On Router 1,
configure a default route via GW, and a router to network 2 via
Router 2 (and vice versa for Router 2.
On your bridge, configure a default route via GW, and routes to
networks 1&2 via their routers. Enable routeback on the interfaces or
it will drop packets which it needs to send out via the same port.
These are all static routes, no need for any dynamic routing for a
network of this size - it gets different (and more 'interesting')
when you've multiple sites with multiple frame relay, leased line,
and ISDN links and you need it to reconfigure itself when something
In general, I would configure the clients to use GW as their default
route. That way, the majority of their traffic does not have to be
redirected. If you set BRIDGE as the default gateway, then your
shorewall machine has to redirect every new connection to a new IP
which is a waste of effort really.
The only exception is if you have clients where the majority of their
traffic is with devices in other local networks - then it may make
sense to use router 1 or 2 as the default gateway. When I say
majority of traffic, then that is connections to unique IPs - each
router will send a redirect when a client needs to use a different
route, and the client will cache that in it's routing table.
You might find http://linux-ip.net/html/routing-icmp.html makes
useful reading. And you'll need to make sure you don't block
ICMP-Redirect messages - it will still work if you do, but the
router(s) will have to redirect every packet of a connection rather
than just the first as the client won't get the message to send them
-- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Shorewall-users mailing list Shorewallfirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/shorewall-users