I have a somewhat complicated firewall and after adding a few more hosts it
took over 6 minutes to restart the firewall. I looked at the generated
iptables and found some duplications and strange things in it.
To isolate it a little I have now created a much smaller configuration and
found the key problem to be related to multiple zones/hosts on one interface.
To duplicate the problem I created a somewhat normal environment with a
local network (LAN) on eth0, a dmz on eth1 and the internet on eth2.
Don''t
know if dmz is needed to reproduce it but...
I manage to get one of my two problems reproduced, will see if I can get the
other one also.
They keypart I think is that on the internet side I have two zones, WAN &
DEV.
DEV is a zone/pile of servers that can ssh straight in to LAN.
#/etc/shorewall/rules
ACCEPT dev lan tcp ssh
#/etc/shorewall/hosts
#ZONE HOST(S) OPTIONS
lan eth0:172.21.15.0/24
dmz eth1:172.21.172.0/24
dev eth2:1.1.1.1
dev eth2:2.2.2.2
dev eth2:3.3.3.3
wan eth2:0/0
#/etc/shorewall/interfaces
#ZONE INTERFACE BROADCAST OPTIONS
lan eth0 detect
dmz eth1 detect
- eth2 detect
#/etc/shorewall/policy
#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
fw lan ACCEPT
lan fw ACCEPT
dev all CONTINUE
wan all CONTINUE
all all REJECT info
When I install this I end up with a "dev_frwd" table that looks like
this;
[root@yar shorewall]# iptables -v -n -L dev_frwd
Chain dev_frwd (3 references)
pkts bytes target prot opt in out source destination
0 0 dev2all all -- * eth2 0.0.0.0/0 0.0.0.0/0
0 0 dev2lan all -- * eth0 0.0.0.0/0
172.21.15.0/24
0 0 dev2lan all -- * eth0 0.0.0.0/0 0.0.0.0/0
0 0 dev2all all -- * eth1 0.0.0.0/0
172.21.172.0/24
0 0 dev2all all -- * eth1 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * eth2 0.0.0.0/0 1.1.1.1
0 0 ACCEPT all -- * eth2 0.0.0.0/0 2.2.2.2
0 0 ACCEPT all -- * eth2 0.0.0.0/0 3.3.3.3
Why all the ACCEPT rules to eth2 in the end? The packages are coming on eth2 and
I don''t have routback enabled anywhere.
my other problem is that the same table looks more like
...
0 0 dev2lan all -- * eth0 0.0.0.0/0
172.21.15.0/24
0 0 dev2lan all -- * eth0 0.0.0.0/0 0.0.0.0/0
0 0 dev2lan all -- * eth0 0.0.0.0/0
172.21.15.0/24
0 0 dev2lan all -- * eth0 0.0.0.0/0 0.0.0.0/0
0 0 dev2lan all -- * eth0 0.0.0.0/0
172.21.15.0/24
0 0 dev2lan all -- * eth0 0.0.0.0/0 0.0.0.0/0
0 0 dev2lan all -- * eth0 0.0.0.0/0
172.21.15.0/24
0 0 dev2lan all -- * eth0 0.0.0.0/0 0.0.0.0/0
0 0 dev2lan all -- * eth0 0.0.0.0/0
172.21.15.0/24
0 0 dev2lan all -- * eth0 0.0.0.0/0 0.0.0.0/0
The same redundant rules repeated once for each dev user.
Have anyone seen anything like this?
What can I do about it?
In this sample I have only 3 users but the production one has more interfaces
and users. Before I added all the users it
took 1 minute to restart shorewall, after adding a first batch of about 50 users
it''s up in over 6 minutes to restart once.
--
-------------------------------------------------------------------
Techwiz, Peter Sjoberg PGP key (12F506C8) on keyserver & homepage
Key fingerprint = 3DC2 CEBA 1590 B41A 3780 955A DB42 02BB 12F5 06C8
mailto:peters AT techwiz.ca http://www.techwiz.ca/~peters
On Friday 19 March 2004 11:51 am, Peter Sjöberg wrote:> I have a somewhat complicated firewall and after adding a few more hosts it > took over 6 minutes to restart the firewall. I looked at the generated > iptables and found some duplications and strange things in it. > To isolate it a little I have now created a much smaller configuration and > found the key problem to be related to multiple zones/hosts on one > interface. > > To duplicate the problem I created a somewhat normal environment with a > local network (LAN) on eth0, a dmz on eth1 and the internet on eth2. Don''t > know if dmz is needed to reproduce it but... > I manage to get one of my two problems reproduced, will see if I can get > the other one also. They keypart I think is that on the internet side I > have two zones, WAN & DEV. DEV is a zone/pile of servers that can ssh > straight in to LAN. > #/etc/shorewall/rules > ACCEPT dev lan tcp ssh > > #/etc/shorewall/hosts > #ZONE HOST(S) OPTIONS > lan eth0:172.21.15.0/24 > dmz eth1:172.21.172.0/24 > dev eth2:1.1.1.1 > dev eth2:2.2.2.2 > dev eth2:3.3.3.3 > wan eth2:0/0 > > #/etc/shorewall/interfaces > #ZONE INTERFACE BROADCAST OPTIONS > lan eth0 detect > dmz eth1 detect > - eth2 detectIf you are going to define lan and wan in your interfaces file then don''t define them AGAIN in your hosts file.> > The same redundant rules repeated once for each dev user. > > Have anyone seen anything like this?Yes -- problems of this sort were rampant in the 1.4.7 timeframe although I thought that most of them were corrected in 1.4.8.> What can I do about it?First correct the double definition of the lan and wan zones. If you are still seeing problems then upgrade to 1.4.10d. Using 2.0.1 Beta 2, I used these two files: interfaces ---------- - eth0 206.124.146.255 dhcp,norfc1918,nobogons,routefilter,blacklist,tcpflags,nosmurfs - eth2 192.168.1.255 dhcp - eth1 - - texas 192.168.9.255 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE hosts ----- tx texas:192.168.8.0/22 dmz eth1:206.124.146.177 dmz eth1:10.10.10.1 dmz eth1:10.10.10.2 loc eth2:192.168.1.0/24 net eth0:0/0 I then get: Chain dmz_frwd (3 references) pkts bytes target prot opt in out source destination 4021 5812116 dmz2net all -- * eth0 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * eth1 0.0.0.0/0 206.124.146.177 0 0 ACCEPT all -- * eth1 0.0.0.0/0 10.10.10.1 0 0 ACCEPT all -- * eth1 0.0.0.0/0 10.10.10.2 338 39772 dmz2loc all -- * eth2 0.0.0.0/0 192.168.1.0/24 0 0 dmz2tx all -- * texas 0.0.0.0/0 192.168.8.0/22 gateway:/etc/test# -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Friday 19 March 2004 12:15 pm, Tom Eastep wrote:> > I then get: > > Chain dmz_frwd (3 references) > pkts bytes target prot opt in out source > destination > 4021 5812116 dmz2net all -- * eth0 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- * eth1 0.0.0.0/0 > 206.124.146.177 > 0 0 ACCEPT all -- * eth1 0.0.0.0/0 > 10.10.10.1 > 0 0 ACCEPT all -- * eth1 0.0.0.0/0 > 10.10.10.2 > 338 39772 dmz2loc all -- * eth2 0.0.0.0/0 > 192.168.1.0/24 > 0 0 dmz2tx all -- * texas 0.0.0.0/0 > 192.168.8.0/22 > gateway:/etc/test# >Doh -- Now I see the problem. We seem to have an assumed ''routeback'' behavior here. I''ll take a look after work... -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Friday 19 March 2004 12:21 pm, Tom Eastep wrote:> On Friday 19 March 2004 12:15 pm, Tom Eastep wrote: > > I then get: > > > > Chain dmz_frwd (3 references) > > pkts bytes target prot opt in out source > > destination > > 4021 5812116 dmz2net all -- * eth0 0.0.0.0/0 > > 0.0.0.0/0 > > 0 0 ACCEPT all -- * eth1 0.0.0.0/0 > > 206.124.146.177 > > 0 0 ACCEPT all -- * eth1 0.0.0.0/0 > > 10.10.10.1 > > 0 0 ACCEPT all -- * eth1 0.0.0.0/0 > > 10.10.10.2 > > 338 39772 dmz2loc all -- * eth2 0.0.0.0/0 > > 192.168.1.0/24 > > 0 0 dmz2tx all -- * texas 0.0.0.0/0 > > 192.168.8.0/22 > > gateway:/etc/test# > > Doh -- Now I see the problem. We seem to have an assumed ''routeback'' > behavior here. > > I''ll take a look after work... >Ok -- I took a quick look and the above behavior is as I had intended. When you define a zone with multiple hosts, Shorewall generates rules to handle traffic between each pair of hosts (even if they are all on the same interface). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
* Tom Eastep <teastep@shorewall.net> [2004-03-19 15:45]:> On Friday 19 March 2004 12:21 pm, Tom Eastep wrote: > > On Friday 19 March 2004 12:15 pm, Tom Eastep wrote: > > > I then get: > > > > > > Chain dmz_frwd (3 references) > > > pkts bytes target prot opt in out source > > > destination > > > 4021 5812116 dmz2net all -- * eth0 0.0.0.0/0 > > > 0.0.0.0/0 > > > 0 0 ACCEPT all -- * eth1 0.0.0.0/0 > > > 206.124.146.177 > > > 0 0 ACCEPT all -- * eth1 0.0.0.0/0 > > > 10.10.10.1 > > > 0 0 ACCEPT all -- * eth1 0.0.0.0/0 > > > 10.10.10.2 > > > 338 39772 dmz2loc all -- * eth2 0.0.0.0/0 > > > 192.168.1.0/24 > > > 0 0 dmz2tx all -- * texas 0.0.0.0/0 > > > 192.168.8.0/22 > > > gateway:/etc/test# > > > > Doh -- Now I see the problem. We seem to have an assumed ''routeback'' > > behavior here. > > > > I''ll take a look after work... > > > > Ok -- I took a quick look and the above behavior is as I had intended. When > you define a zone with multiple hosts, Shorewall generates rules to handle > traffic between each pair of hosts (even if they are all on the same > interface).Ok, so how do I stop it? I didn''t see any "ROUTBACK=NO" parameter. I had this problem about a year ago and then you sent me a patch that fixed the problem. Now we have expanded the lab and I upgraded the firewall. My problem is that I now have 3 lab zones(=NICs) + the incoming side. On the incoming side I have about 100 users that connects to the different lab zones depending on what group they belong to. With this behaviour each user get a rule to access each other user generating 100x100 rules extra, I don''t need that...> > -Tom > -- > Tom Eastep \ Nothing is foolproof to a sufficiently talented fool > Shoreline, \ http://shorewall.net > Washington USA \ teastep@shorewall.net >-- ------------------------------------------------------------------- Techwiz, Peter Sjoberg PGP key (12F506C8) on keyserver & homepage Key fingerprint = 3DC2 CEBA 1590 B41A 3780 955A DB42 02BB 12F5 06C8 mailto:peters AT techwiz.ca http://www.techwiz.ca/~peters
On Friday 19 March 2004 01:01 pm, Peter Sjöberg wrote:> > > > > > I''ll take a look after work... > > > > Ok -- I took a quick look and the above behavior is as I had intended. > > When you define a zone with multiple hosts, Shorewall generates rules to > > handle traffic between each pair of hosts (even if they are all on the > > same interface). > > Ok, so how do I stop it? I didn''t see any "ROUTBACK=NO" parameter. > I had this problem about a year ago and then you sent me a patch that fixed > the problem. Now we have expanded the lab and I upgraded the firewall. > > My problem is that I now have 3 lab zones(=NICs) + the incoming side. On > the incoming side I have about 100 users that connects to the different lab > zones depending on what group they belong to. With this behaviour each user > get a rule to access each other user generating 100x100 rules extra, I > don''t need that... >Please try this patch -- it is against 2.0.1 Beta 2 (where I''ve tested it) but it applies (with a little fuzz) to 1.4.8. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net