|
From: Tom E. <te...@sh...> - 2005-01-24 23:47:22
|
Hello Richard,
Richard wrote:
> Firstly, thank you very much - shorewall is great.
You're welcome. I'm glad that you find it useful.
> I'm not a member of
> this list, and please forgive me if I am suggesting something stupid,
> but the following occurs to me, and I thought it might be useful.
>
> Why no make it possible to specify zones as well as interfaces in the
> /etc/shorewall/masq file ?
>
> Eg: instead of:
>
> eth0 eth1
>
> one might write:
>
> net loc (or masq in Mandrake).
>
>
> A reason this would be useful is for backup internet connectivity.
>
> Eg: local network on eth1, masqueraded. ADSL modem on eth0. Backup dialup
> modem on ppp0. ppp0 and eth0 are both part of the net zone (in
> /etc/shorewall/zones); usually only one of the interfaces is working.
>
> Here is my /etc/shorewall/masq file. The result works fine, but I think
> it seems kludgy.
What seems kludgy about it?
> It's also unclear what might happen if both eth0 and
> ppp0 were up at the same time.
>
It would work fine -- see Shorewall FAQ 32.
> -----------------------------------
> #Normally, we want to use eth0 (ADSL) for internet access
> #But in emergencies, use ppp0 instead.
> eth0 eth1
> ppp0 eth1
> ------------------------------------
>
>
> [I'm using shorewall-2.0.8-1mdk on Mandrake 10.1. I hope this is useful
> rather than daft!]
>
Thank you for the suggestion. I'm inclined, however, to reject it on two
grounds:
1. In Shorewall, Zones are defined based on security requirements
whereas Masquerading/SNAT is defined based on routing deficiencies
(including the use of RFC 1918 addresses which are not
internet-routable). So while the requirements for using MASQ/SNAT may
coincide with firewall security requirements in a particular case, there
is no reason that they should coincide in general.
2. It is not possible to use zone definitions directly in setting up
MASQ/SNAT rules. That is becuase zone definitions are typically tied to
interfaces and rules in the POSTROUTING chain (where MASQ/SNAT is
specified) cannot be qualified by source interface. So when you write
eth0 eth1
in /etc/shorewall/masq, what Shorewall generates is:
for each route out of eth1
eth0 <target of the route>
That's why the interface ("eth1" in this case) must be up and running
when Shorewall starts and also why people get messed up if there are
hosts connected to eth1 that are managed by Proxy ARP or when they have
asymmetric routing.
Suppose that zone Z is based on these two /etc/shorewall/hosts entries:
Z eth1:0.0.0.0/0
Z eth2:192.168.4.9
In that case, Shorewall can't configure Netfilter to match this
/etc/shorewall/entry:
eth0 Z
Do you see why? (hint: consider traffic from 192l.168.4.9 arriving on
eth3). Then you also see that although Shorewall allows it, even this
entry cannot be matched exactly:
eth0 eth1
I let myself get talked into allowing interface names in the SUBNET
column of /etc/shorewall/masq entries and I mildly regret it; I'm not
inclined to compound the problem by allowing zone names as well.
-Tom
--
Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
Shoreline, \ http://shorewall.net
Washington USA \ te...@sh...
PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
|