For a few years we have been using a configuration for multiple zones
through one interface (actually eth+) using the interfaces and hosts
files. (We've got this on 600+ servers as a modular host-based
firewall.) Many of our hosts have two eth devices. For background
here's existing config:
/etc/shorewall/interfaces:
- eth+ detect
/etc/shorewall/hosts:
net eth+:0.0.0.0/0
uw eth+:$N_ALL_UW_AFFILIATED
Now we are introducing bonded interfaces so a host may have bond+ or
eth+ or a combination of bond+ and eth+. To accomodate this with no
fussing with per-host configs I switched to these configs:
/etc/shorewall/interfaces:
- enet detect physical=+
/etc/shorewall/hosts:
net enet:0.0.0.0/0
uw enet:$N_ALL_UW_AFFILIATED
This (nearly) works and results in this INPUT chain (apologies if it wraps):
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
1678 54427 dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate INVALID,NEW
33631 4085K enet_in all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT all -- lo * 0.0.0.0/0
0.0.0.0/0
0 0 enet_in all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 Drop all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0
0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:INPUT:DROP:'
0 0 DROP all -- * * 0.0.0.0/0
0.0.0.0/0
The problem here is that physical=+ results in a * match in the table.
Unfortunately this * also matches 'lo', the loopback device. Traffic
never makes it to the ACCEPT all rule for loopback and for lack of
another rule is blocked. Blocking loopback is not so good.
It seems to me that when producing the INPUT chain, the more specific
non-pattern interface names should be listed first (eg lo), partial
wildcards (eg eth+) second and bare wildcards (eg +) should be last.
This would most likely result in matching that people expect. In my
case, the config would work fine if "lo" were above "enet_in".
As an aside, the input chain above is confusing that it contains two
enet_in rules. Maybe be quirk I'm seeing is a matter of the first
enet_in, before lo, being in the wrong place?
I assume I'm not overlooking something. Anybody have any thoughts on
this configuration or observed quirk?
Thanks,
-Eric
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
