Hi Tom - thanks much for the patch - has done the trick (and greetings from Shoreline, we're neighbors).

I've been able to reproduce this on 3.4.0 so I assume that is the release
that you are running.
Er, yes, apologies for the missing info.

   Processing /etc/shorewall/stop ...
   /var/lib/shorewall/.start: line 211: source_ip_range: command not found
   /var/lib/shorewall/.start: line 212: dest_ip_range: command not found
I'm concerned about the above messages. It means that somehow
source_ip_range() and dest_ip_range() are getting called out of a compiled
script which shouldn't happen. Do you have anything in your
/etc/shorewall/stop file? Does this happen on a normal "shorewall stop" or
only when you have a startup error in the compiled script?

It only happened with the startup error, ie when there was a CONTINUE policy, or IMPLICIT_CONTINUE=Yes was set in shorewall.conf - there's nothing in my stop file...

On another note - I'm now having problems now with a wildcard entry for VLAN interfaces in the interfaces file, when using multiple zones on an interface (ie, using the hosts file) - I'm trying :

-       eth1.*        detect            tcpflags,nosmurfs

I also tried :

-       eth1+       detect            tcpflags,nosmurfs
-       eth1.+        detect            tcpflags,nosmurfs

With my corresponding hosts file entries of :

foo1    eth1.2:192.168.168.0/24         tcpflags
foo2    eth1.3:192.168.169.0/24         tcpflags

But 'shorewall check' is returning things like (with the + sign) :

Validating hosts file...
ERROR: Unknown interface (eth1.2) in record "foo1 eth1.2:192.168.168.0/24 tcpflags"
Terminated

or (with the * ) :

Validating interfaces file...
/usr/share/shorewall/lib.config: line 372: eth1_*_broadcast=detect: command not found
/usr/share/shorewall/lib.config: line 373: eth1_*_zone=: command not found
/usr/share/shorewall/lib.config: line 374: eth1_*_options=tcpflags detectnets nosmurfs: command not found
Validating hosts file...
ERROR: Unknown interface (eth1.2) in record "foo1 eth1.2:192.168.168.0/24 tcpflags"
Terminated

(shorewall trace check output attached below).

Is this simply unsupported? Or am I approaching things incorrectly here? I have dozens of internal client subnets behind one interface, that I need separate zones for. I thought I could likely increase security by placing each client zone on a VLAN interface. If this is not allowed, the only other approach that I appear to see would be to place all the VLAN'd interfaces in one zone (not using the hosts file), and specify the access allowed to the clients by using the one zone and different VLAN interfaces alone in the rules file - this does not seem to provide quite the fine level of granularity and control via specifying policies for different zones in the policy file though...

PS: Tom I would not dare impinge upon your time, but if you might know a good Shorewall person preferably in our local Seattle area that would be available for a few hours of consulting work, I could really use some hands-on help getting this all up and running... I'm stumbling in the dark on some of this stuff... Thanks!!!

Regards,
Phil Cordier













Attachment: trace-check.txt.gz
Description: application/gzip

begin:vcard
fn:Phil Cordier
n:Cordier;Phil
org:GridZones
adr;dom:;;PO Box 55099;Seattle;WA;98155
email;internet:[EMAIL PROTECTED]
title:President / CEO
tel;work:206-441-7580
tel;fax:206-219-5307
tel;pager:[EMAIL PROTECTED]
tel;cell:206-407-3037
x-mozilla-html:TRUE
url:http://www.gridzones.com
version:2.1
end:vcard

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to