Hi, I''m evaluating Shorewall (looks excellent so far!), but have run into a problem I can''t quite figure... I''m getting inconsistent results when trying to use a nested zone. I have a three-zone setup with loc (internal), dmz and net (external) zones. I want to have one system on my internal net as an admin server with the ability to pass email & DNS traffic to my DMZ. I''m putting this server (by itself) in a zone called ''svr'' which is nested in zone ''loc''. With the rules I have set up, as far as I can tell, systems in the ''loc'' zone that are NOT in the ''svr'' zone should not get through for this traffic. The ''loc'' zone host I''m using to test is named ''carrera'' (the ''svr'' zone host is not relevent - it works regardless of what I do). My test is as follows (all done on ''carrera'', the ''loc'' zone host), starting with the firewall turned OFF. - issue a ''dig'' to query the nameserver (on the DMZ, IP 192.168.1.2) dig @192.168.1.2 ns1.octigabay.com a this succeeds. - issue a ''shorewall start'' command on the firewall. - re-issue the ''dig'' command as above. This FAILS as it should (the firewall rules should permit only the host in the ''svr'' zone to get through) - issue a ''shorewall stop'' command on the firewall. - re-issue the ''dig'' command. It succeeds. - issue a ''shorewall start'' command on the firewall. - re-issue the ''dig'' command. It SUCCEEDS!! It should not as far as I can tell! - issue a ''shorewall stop'' command, wait a while (5 minutes?) try again, the scenario repeats itself. Running tcpdump on the firewall and on the DNS server in the dmz verifies that the packets are getting through and are not coming from some unexpected spot. I have no resolver set up on the host I''m trying the queries from, nor do I have one set up on the firewall. My ''interfaces'' file: - eth0 detect dmz eth1 detect dropunclean,tcpflags net eth2 detect norfc1918,dropunclean,tcpflags My ''zones'' file: svr Server Internal Server net Net Internet loc Local Local Networks dmz DMZ Demilitarized Zone My ''hosts'' file: loc eth0:192.168.2.0/24 svr eth0:192.168.2.54 My ''policy'' file: svr all CONTINUE loc dmz REJECT loc net ACCEPT net all DROP info all all REJECT info My ''rules'' file: ACCEPT loc fw tcp 22 ACCEPT loc dmz tcp 22 ACCEPT svr dmz tcp 53 ACCEPT svr dmz udp 53 ACCEPT loc fw icmp 8 ACCEPT fw loc icmp 8 ACCEPT dmz fw icmp 8 ACCEPT fw dmz icmp 8 ACCEPT loc dmz icmp 8 ACCEPT dmz net icmp 8 ACCEPT svr dmz tcp 25 ACCEPT dmz svr tcp 25 ACCEPT dmz net tcp 25 ACCEPT net dmz tcp 25 My ''routestopped'' file: eth0 - eth1 - Any ideas, anyone? This is stumping me... Cheers, Ross -- Ross Parker OctigaBay Systems Corp. phone: 604-415-9379 x5453 cell: 604-817-3500
The order of the entries in the hosts file is significant if one is a subzone of the other. In other words, list the subzone first. hosts file: svr eth0:192.168.2.54 loc eth0:192.168.2.0/24 -----Original Message----- From: shorewall-users-bounces@lists.shorewall.net [mailto:shorewall-users-bounces@lists.shorewall.net]On Behalf Of Ross Parker Sent: Friday, April 04, 2003 5:07 PM To: shorewall-users@lists.shorewall.net Subject: [Shorewall-users] Nested zone problem Hi, I''m evaluating Shorewall (looks excellent so far!), but have run into a problem I can''t quite figure... I''m getting inconsistent results when trying to use a nested zone. I have a three-zone setup with loc (internal), dmz and net (external) zones. I want to have one system on my internal net as an admin server with the ability to pass email & DNS traffic to my DMZ. I''m putting this server (by itself) in a zone called ''svr'' which is nested in zone ''loc''. With the rules I have set up, as far as I can tell, systems in the ''loc'' zone that are NOT in the ''svr'' zone should not get through for this traffic. The ''loc'' zone host I''m using to test is named ''carrera'' (the ''svr'' zone host is not relevent - it works regardless of what I do). My test is as follows (all done on ''carrera'', the ''loc'' zone host), starting with the firewall turned OFF. - issue a ''dig'' to query the nameserver (on the DMZ, IP 192.168.1.2) dig @192.168.1.2 ns1.octigabay.com a this succeeds. - issue a ''shorewall start'' command on the firewall. - re-issue the ''dig'' command as above. This FAILS as it should (the firewall rules should permit only the host in the ''svr'' zone to get through) - issue a ''shorewall stop'' command on the firewall. - re-issue the ''dig'' command. It succeeds. - issue a ''shorewall start'' command on the firewall. - re-issue the ''dig'' command. It SUCCEEDS!! It should not as far as I can tell! - issue a ''shorewall stop'' command, wait a while (5 minutes?) try again, the scenario repeats itself. Running tcpdump on the firewall and on the DNS server in the dmz verifies that the packets are getting through and are not coming from some unexpected spot. I have no resolver set up on the host I''m trying the queries from, nor do I have one set up on the firewall. My ''interfaces'' file: - eth0 detect dmz eth1 detect dropunclean,tcpflags net eth2 detect norfc1918,dropunclean,tcpflags My ''zones'' file: svr Server Internal Server net Net Internet loc Local Local Networks dmz DMZ Demilitarized Zone My ''hosts'' file: loc eth0:192.168.2.0/24 svr eth0:192.168.2.54 My ''policy'' file: svr all CONTINUE loc dmz REJECT loc net ACCEPT net all DROP info all all REJECT info My ''rules'' file: ACCEPT loc fw tcp 22 ACCEPT loc dmz tcp 22 ACCEPT svr dmz tcp 53 ACCEPT svr dmz udp 53 ACCEPT loc fw icmp 8 ACCEPT fw loc icmp 8 ACCEPT dmz fw icmp 8 ACCEPT fw dmz icmp 8 ACCEPT loc dmz icmp 8 ACCEPT dmz net icmp 8 ACCEPT svr dmz tcp 25 ACCEPT dmz svr tcp 25 ACCEPT dmz net tcp 25 ACCEPT net dmz tcp 25 My ''routestopped'' file: eth0 - eth1 - Any ideas, anyone? This is stumping me... Cheers, Ross -- Ross Parker OctigaBay Systems Corp. phone: 604-415-9379 x5453 cell: 604-817-3500 _______________________________________________ Shorewall-users mailing list Post: Shorewall-users@lists.shorewall.net Subscribe/Unsubscribe: http://lists.shorewall.net/mailman/listinfo/shorewall-users Support: http://www.shorewall.net/support.htm FAQ: http://www.shorewall.net/FAQ.htm
Hi, No difference if I reverse svr and loc in the hosts file. It almost seems to be a cacheing issue - if I leave the firewall running for 5 minutes and try my test again, the DNS connection is (correctly) refused, but if I then stop Shorewall, do the ''dig'', and start Shorewall again, I can ''dig'' away for another 5 minutes. I''m only guessing at the ''5 minutes'', I haven''t done a definitive test. I do not seem to have this issue with other protocols, just DNS queries, however as I indicated below if I watch the packets with tcpdump, I can see the DNS queries getting through where I believe they should not. Cheers, Ross> The order of the entries in the hosts file is significant if one is a > subzone of the other. In other words, list the subzone first. > > hosts file: > svr eth0:192.168.2.54 > loc eth0:192.168.2.0/24 > > > > -----Original Message----- > From: shorewall-users-bounces@lists.shorewall.net > [mailto:shorewall-users-bounces@lists.shorewall.net]On Behalf Of Ross > Parker > Sent: Friday, April 04, 2003 5:07 PM > To: shorewall-users@lists.shorewall.net > Subject: [Shorewall-users] Nested zone problem > > > Hi, > > I''m evaluating Shorewall (looks excellent so far!), but have run into a > problem I can''t quite figure... > > I''m getting inconsistent results when trying to use a nested zone. I > have a three-zone setup with loc (internal), dmz and net (external) > zones. I want to have one system on my internal net as an admin server > with the ability to pass email & DNS traffic to my DMZ. I''m putting this > server (by itself) in a zone called ''svr'' which is nested in zone ''loc''. > > With the rules I have set up, as far as I can tell, systems in the ''loc'' > zone that are NOT in the ''svr'' zone should not get through for this > traffic. The ''loc'' zone host I''m using to test is named ''carrera'' (the > ''svr'' zone host is not relevent - it works regardless of what I do). > > My test is as follows (all done on ''carrera'', the ''loc'' zone host), > starting with the firewall turned OFF. > > - issue a ''dig'' to query the nameserver (on the DMZ, IP 192.168.1.2) > > dig @192.168.1.2 ns1.octigabay.com a > > this succeeds. > > - issue a ''shorewall start'' command on the firewall. > > - re-issue the ''dig'' command as above. This FAILS as it should (the > firewall rules should permit only the host in the ''svr'' zone to get > through) > > - issue a ''shorewall stop'' command on the firewall. > > - re-issue the ''dig'' command. It succeeds. > > - issue a ''shorewall start'' command on the firewall. > > - re-issue the ''dig'' command. It SUCCEEDS!! It should not as far as I > can tell! > > - issue a ''shorewall stop'' command, wait a while (5 minutes?) try again, > the scenario repeats itself. > > Running tcpdump on the firewall and on the DNS server in the dmz > verifies that the packets are getting through and are not coming from > some unexpected spot. > > I have no resolver set up on the host I''m trying the queries from, nor > do I have one set up on the firewall. > > > > My ''interfaces'' file: > > - eth0 detect > dmz eth1 detect dropunclean,tcpflags > net eth2 detect norfc1918,dropunclean,tcpflags > > My ''zones'' file: > > svr Server Internal Server > net Net Internet > loc Local Local Networks > dmz DMZ Demilitarized Zone > > My ''hosts'' file: > > loc eth0:192.168.2.0/24 > svr eth0:192.168.2.54 > > My ''policy'' file: > > svr all CONTINUE > loc dmz REJECT > loc net ACCEPT > net all DROP info > all all REJECT info > > My ''rules'' file: > > ACCEPT loc fw tcp 22 > ACCEPT loc dmz tcp 22 > ACCEPT svr dmz tcp 53 > ACCEPT svr dmz udp 53 > ACCEPT loc fw icmp 8 > ACCEPT fw loc icmp 8 > ACCEPT dmz fw icmp 8 > ACCEPT fw dmz icmp 8 > ACCEPT loc dmz icmp 8 > ACCEPT dmz net icmp 8 > ACCEPT svr dmz tcp 25 > ACCEPT dmz svr tcp 25 > ACCEPT dmz net tcp 25 > ACCEPT net dmz tcp 25 > > My ''routestopped'' file: > > eth0 - > eth1 - > > > Any ideas, anyone? This is stumping me... > > Cheers, > > Ross > -- > Ross Parker > OctigaBay Systems Corp. > > phone: 604-415-9379 x5453 > cell: 604-817-3500 > > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe: > http://lists.shorewall.net/mailman/listinfo/shorewall-users > Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm-- Ross Parker OctigaBay Systems Corp. phone: 604-415-9379 x5453 cell: 604-817-3500
On 7 Apr 2003, Ross Parker wrote:> Hi, > > No difference if I reverse svr and loc in the hosts file. > > It almost seems to be a cacheing issue - if I leave the firewall running > for 5 minutes and try my test again, the DNS connection is (correctly) > refused, but if I then stop Shorewall, do the ''dig'', and start Shorewall > again, I can ''dig'' away for another 5 minutes. I''m only guessing at the > ''5 minutes'', I haven''t done a definitive test. > > I do not seem to have this issue with other protocols, just DNS queries, > however as I indicated below if I watch the packets with tcpdump, I can > see the DNS queries getting through where I believe they should not. >What you are seeing is the "statefulness" of Netfilter. Once you have a connection established to a DNS server, you can dig away to that server even though you have rules to prevent such connections. Once the connection times one due to inactivity then further connection attempts are again subject to your ruleset. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
Hi, Tom,> > What you are seeing is the "statefulness" of Netfilter. Once you have a > connection established to a DNS server, you can dig away to that server > even though you have rules to prevent such connections. Once the > connection times one due to inactivity then further connection attempts > are again subject to your ruleset.Thanks, I discovered this about 3 secs before your message arrived! Duh. Sorry to trouble the list... Cheers, Ross -- Ross Parker OctigaBay Systems Corp. phone: 604-415-9379 x5453 cell: 604-817-3500