deya@ozemail.com.au
2003-Aug-21 07:46 UTC
[Shorewall-users] DROP in Rules, with smb port 138 ?
Hi all, I have the following configuration: DMZ | | Loc1 (WST) ------------- FW -------- WAN | | Loc2 (SVR) -------------- Now, there is an smb server running on loc2, and just a master browser on FW. There is no problem with this setup as clients on Loc1 can still view and use resources in Loc2 through the Smb. The problem, is I get an error on the samba log files running on Loc2: connecting to 192.168.168.1 139 then it fails, nmb dies. On the log files, before this incident on the fw, I get such errors : Aug 21 17:20:30 a310 kernel: fp=svr2fw:3 a=DROP IN=eth3 OUT= MAC=00:48:54:53:8a:52:00:48:54:53:6e:de:08:00 SRC=192.168.168.72 DST=192.168.11.255 LEN=273 TOS=0x00 PREC=0x00 TTL=64 ID=5632 PROTO=UDP SPT=138 DPT=138 LEN=253 ------------------------------------------------------------------------------------------------------- Running iptables -L : Chain svr2fw (1 references) target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED LOG udp -- !192.168.168.72 anywhere state NEW udp dpts:netbios-ns:netbios-ssn limit: avg 10/min burst 5 LOG level info prefix `fp=svr2fw:1 a=DROP '' DROP udp -- !192.168.168.72 anywhere state NEW udp dpts:netbios-ns:netbios-ssn LOG udp -- !192.168.168.72 anywhere state NEW udp dpt:who limit: avg 10/min burst 5 LOG level info prefix `fp=svr2fw:2 a=DROP '' DROP udp -- !192.168.168.72 anywhere state NEW udp dpt:who LOG udp -- !192.168.168.1 anywhere state NEW udp dpts:netbios-ns:netbios-ssn limit: avg 10/min burst 5 LOG level info prefix `fp=svr2fw:3 a=DROP '' DROP udp -- !192.168.168.1 anywhere state NEW udp dpts:netbios-ns:netbios-ssn LOG udp -- !192.168.168.1 anywhere state NEW udp dpt:who limit: avg 10/min burst 5 LOG level info prefix `fp=svr2fw:4 a=DROP '' DROP udp -- !192.168.168.1 anywhere state NEW udp dpt:who LOG tcp -- !192.168.168.72 anywhere multiport dports netbios-ns,netbios-ssn,microsoft-ds state NEW limit: avg 10/min burst 5 LOG level info prefix `fp=svr2fw:5 a=DROP '' DROP tcp -- !192.168.168.72 anywhere multiport dports netbios-ns,netbios-ssn,microsoft-ds state NEW LOG tcp -- !192.168.168.1 anywhere multiport dports netbios-ns,netbios-ssn,microsoft-ds state NEW limit: avg 10/min burst 5 LOG level info prefix `fp=svr2fw:6 a=DROP '' DROP tcp -- !192.168.168.1 anywhere multiport dports netbios-ns,netbios-ssn,microsoft-ds state NEW LOG udp -- !192.168.168.72 anywhere state NEW udp spt:netbios-ns dpts:1024:65535 limit: avg 10/min burst 5 LOG level info prefix `fp=svr2fw:7 a=DROP '' DROP udp -- !192.168.168.72 anywhere state NEW udp spt:netbios-ns dpts:1024:65535 LOG udp -- !192.168.168.1 anywhere state NEW udp spt:netbios-ns dpts:1024:65535 limit: avg 10/min burst 5 LOG level info prefix `fp=svr2fw:8 a=DROP '' DROP udp -- !192.168.168.1 anywhere state NEW udp spt:netbios-ns dpts:1024:65535 LOG all -- !192.168.168.72 anywhere limit: avg 10/min burst 5 LOG level info prefix `fp=svr2fw:9 a=DROP '' DROP all -- !192.168.168.72 anywhere LOG all -- !192.168.168.1 anywhere limit: avg 10/min burst 5 LOG level info prefix `fp=svr2fw:10 a=DROP '' DROP all -- !192.168.168.1 anywhere LOG udp -- anywhere anywhere state NEW udp dpts:netbios-ns:netbios-ssn limit: avg 10/min burst 5 LOG level info prefix `fp=svr2fw:11 a=ACCEPT '' ACCEPT udp -- anywhere anywhere state NEW udp dpts:netbios-ns:netbios-ssn LOG tcp -- anywhere anywhere multiport dports netbios-ns,netbios-ssn,microsoft-ds state NEW limit: avg 10/min burst 5 LOG level info prefix `fp=svr2fw:12 a=ACCEPT '' ACCEPT tcp -- anywhere anywhere multiport dports netbios-ns,netbios-ssn,microsoft-ds state NEW LOG udp -- anywhere anywhere state NEW udp spt:netbios-ns dpts:1024:65535 limit: avg 10/min burst 5 LOG level info prefix `fp=svr2fw:13 a=ACCEPT '' ACCEPT udp -- anywhere anywhere state NEW udp spt:netbios-ns dpts:1024:65535 common all -- anywhere anywhere LOG all -- anywhere anywhere limit: avg 10/min burst 5 LOG level info prefix `fp=svr2fw:14 a=REJECT '' reject all -- anywhere anywhere My setup details: ------------------------------------------------------------------------------------------------------- RULES: REJECT:info wst net tcp 6667 REJECT:info wst net tcp 137,445 REJECT:info wst net udp 137:139 # SVR to the Internet - Reject Attempts by Trojans to call external homes # This list is still under dev / const. # DM 1908032350 REJECT:info svr net tcp 137,445 REJECT:info svr net udp 13:139 ############################################################################## # WST to Firewall # Change Next Address When completed. # DROP:info svr:!192.168.168.72,!192.168.168.1 fw udp 137:139,513 DROP:info svr:!192.168.168.72,!192.168.168.1 fw tcp 137,139,445 DROP:info svr:!192.168.168.72,!192.168.168.1 fw udp 1024: 137 DROP:info svr:!192.168.168.72,!192.168.168.1 fw DROP:info wst:~!00-00-39-0E-71-A1 fw ACCEPT wst fw tcp ssh,time,10000,swat,137,139,445 ACCEPT wst fw udp snmp,ntp,445 ACCEPT wst fw udp 137:139,53,68,67 ACCEPT wst fw udp 1024: 137 ACCEPT wst fw icmp 8 ACCEPT wst fw icmp echo-request ACCEPT wst:~00-00-39-0E-71-A1 fw tcp 23,80 ############################################################################## # WST to DMZ # ACCEPT wst dmz tcp ssh,time,10000,smtp,pop3,swat,137,139,445,3128,53,110 ACCEPT wst dmz udp 53 ACCEPT wst dmz icmp echo-request ACCEPT wst dmz icmp 8 #DNAT wst 3128 tcp www - !192.168.2.2 ############################################################################## # WST to SVR # ACCEPT wst svr icmp echo-request ACCEPT wst svr icmp 8 ACCEPT wst svr tcp 1521,1526,80,8888,8080,110,25,23 #ACCEPT wst:~!00-00-39-0E-71-A1 svr all ############################################################################## # NET to WST # ACCEPT net wst udp 6790 ############################################################################## # DMZ to NET # ACCEPT dmz net tcp smtp,domain,www,https,whois,echo,2702,21,2703,ssh,ftp,pop3 ACCEPT dmz net udp domain,ntp ACCEPT dmz net:pop.ozemail.com.au tcp pop3 ACCEPT:info dmz net tcp 1024: 20 ############################################################################## # DMZ to Firewall # ACCEPT dmz fw udp ntp ntp ACCEPT dmz fw tcp snmp,ssh ACCEPT dmz fw udp snmp REJECT dmz fw tcp auth ############################################################################## # DMZ to WST # ACCEPT dmz wst tcp smtp,6001:6010 ############################################################################## # Internet to Firewall # DNAT net dmz:192.168.2.3 tcp smtp ############################################################################## # Internet to DMZ # DNAT net dmz:192.168.2.3 tcp smtp #DNAT net dmz:192.168.2.2 tcp ftp ACCEPT net dmz:192.168.168.2 udp 3130 ############################################################################## # DMZ to Internet # ACCEPT dmz net icmp echo-request ACCEPT dmz net icmp 8 ACCEPT dmz:192.168.168.2 net tcp 80 ACCEPT dmz:192.168.168.2 net tcp 443 ACCEPT dmz:192.168.168.2 net udp 3130 ############################################################################## # Firewall to DMZ # ACCEPT fw dmz:192.168.2.3 udp 53 ACCEPT fw dmz:192.168.2.3 tcp 43 ACCEPT fw dmz:192.168.2.3 tcp 25 ACCEPT fw wst udp 137:139 ACCEPT fw wst tcp 137,139,445 ACCEPT fw wst udp 1024: 137 ############################################################################## # Firewall to SVR # ACCEPT fw svr udp 137:139 ACCEPT fw svr tcp 137,139,445 ACCEPT fw svr udp 1024: 137 ############################################################################## # Firewall to NET --Remove.. # #ACCEPT fw net tcp 25 ############################################################################## # SVR to Firewall # ACCEPT:info svr fw udp 137:139 ACCEPT:info svr fw tcp 137,139,445 ACCEPT:info svr fw udp 1024: 137 #ACCEPT:info svr:192.168.168.88 fw tcp 23 ############################################################################## # SVR to DMZ # #ACCEPT:info svr:192.168.168.88 dmz tcp 3128,80 ACCEPT:info svr:192.168.168.67 dmz udp 53 ############################################################################## # SVR to Internet To Be Removed # ACCEPT:info svr:192.168.168.67 net tcp 110,25 ------------------------------------------------------------------------------------------------------- Policy: ############################################################################### #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST wst svr ACCEPT wst fw REJECT info svr fw REJECT info net all DROP info all all REJECT info #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE ------------------------------------------------------------------------------------------------------- Interfaces: ############################################################################## #ZONE INTERFACE BROADCAST OPTIONS net eth0 81.10.4.183 tcpflags,blacklist,norfc1918,routefilter dmz eth1 192.168.1.255 wst eth2 192.168.11.255 dhcp svr eth3 192.168.168.255 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE I simply want to allow this kind of broadcast on the net, from loc2 to loc1 and the other way to be able to browse the files. With the current setup, it works for sometime, then just dies ! Thanks in advance, This message was sent through MyMail http://www.mymail.com.au
On Thu, 2003-08-21 at 07:46, deya@ozemail.com.au wrote:> > ############################################################################## > # WST to Firewall > # Change Next Address When completed. > # > DROP:info svr:!192.168.168.72,!192.168.168.1 fw udp 137:139,513The above syntax is wrong and with the version of Shorewall you are using (you don''t say what it is), it is doing the wrong thing. A better idea is to: ACCEPT svr:192.168.168.72,192.168.168.1 fw udp 137:139,513 DROP:info svr fw udp 137:139,513 Using Shorewall 1.4.6b, you should be able to code this as: DROP:info svr:!192.168.168.72,192.168.168.1 fw udp 137:139,513 And have it do what you want. As a final request, in the future if you want to sent the output of iptables, use "shorewall show <chain>". It prints the chain contents in the format that I want to see it in. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Thu, 2003-08-21 at 08:09, Tom Eastep wrote:> > Using Shorewall 1.4.6b, you should be able to code this as: > > DROP:info svr:!192.168.168.72,192.168.168.1 fw udp 137:139,513 > > And have it do what you want. >Oops -- that has only been implemented for DNAT and REDIRECT rules so you will have to use the other solution that I offered. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Thu, 2003-08-21 at 08:11, Tom Eastep wrote:> On Thu, 2003-08-21 at 08:09, Tom Eastep wrote: > > > > > Using Shorewall 1.4.6b, you should be able to code this as: > > > > DROP:info svr:!192.168.168.72,192.168.168.1 fw udp 137:139,513 > > > > And have it do what you want. > > > > Oops -- that has only been implemented for DNAT and REDIRECT rules so > you will have to use the other solution that I offered.Sigh -- it isn''t implemented in those cases either; I was confusing this case with another case that I did handle recently (see below). The basic problem here is that with iptables, in order to handle the situation: if NOT (a OR b OR c ) then <rule> an additional "helper" chain is required. This "helper" chain contains: if a then RETURN if b then RETURN if c then RETURN <rule> The relevant rule chain then has a jump to this helper chain. Shorewall currently isn''t smart enough to do that. Your original rule was: DROP:info svr:!192.168.168.72,!192.168.168.1 fw udp 137:139,513 Shorewall converts this into: if source not 192.168.168.72 then DROP if source not 192.168.168.1 then DROP So the first Shorewall-generated rule drops traffic from 192.168.168.1 and the second rule drops traffic from 192.168.168.72. Note that the above treatment is not as irrational as it looks since Shorewall applies the same algorithm for this case: DROP:info svr:192.168.168.72,192.168.168.1 fw udp 137:139,513 In that case, the Shorewall-generated rules do what you intend. if source is 192.168.168.72 then DROP if source is 192.168.168.1 then DROP Some time ago, I looked at trying to solve this problem and the current code structure makes it too difficult to attempt. And as I pointed out in my original response in this thread, there is an easy workaround. What I DID implement was: DNAT z1 z2 proto port - !addr1,addr2,... That allows multiple destination addresses to be excluded from a DNAT rule and uses the "helper" chain technique described above. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
deya@ozemail.com.au
2003-Aug-21 08:50 UTC
[Shorewall-users] DROP in Rules, with smb port 138 ?
Dear Tom,
Thanks for your prompt support and help.
You did a agreat job with this software, I deeply appreciate your efforts,
especially in supporting it.
The mistake, seems, as I didn''t get this error again yet (I hope) is :
!192.168.168.72,!192.168.168.1 ( I used it twice, instead of once at the very
beginning of the line). This
seems to have corrected the problem.
I am using version 1.4.6b.
The output of this chain is (After your change) :
Shorewall-1.4.6b Chain svr2fw at a310 - Thu Aug 21 18:38:47 BREDT 2003
Counters reset Thu Aug 21 18:29:08 BREDT 2003
Chain svr2fw (1 references)
pkts bytes target prot opt in out source destination
45 4451 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
state RELATED,ESTABLISHED
22 4496 LOG udp -- * * !192.168.168.72 0.0.0.0/0
state NEW udp dpts:137:139 limit: avg 10/min burst 5 LOG flags 0 level 6 prefix
`fp=svr2fw:1 a=DROP ''
35 7057 DROP udp -- * * !192.168.168.72 0.0.0.0/0
state NEW udp dpts:137:139
0 0 LOG udp -- * * !192.168.168.72 0.0.0.0/0
state NEW udp dpt:513 limit: avg 10/min burst 5 LOG flags 0 level 6 prefix
`fp=svr2fw:2 a=DROP ''
0 0 DROP udp -- * * !192.168.168.72 0.0.0.0/0
state NEW udp dpt:513
0 0 LOG udp -- * * 192.168.168.1 0.0.0.0/0
state NEW udp dpts:137:139 limit: avg 10/min burst 5 LOG flags 0 level 6 prefix
`fp=svr2fw:3 a=DROP ''
0 0 DROP udp -- * * 192.168.168.1 0.0.0.0/0
state NEW udp dpts:137:139
0 0 LOG udp -- * * 192.168.168.1 0.0.0.0/0
state NEW udp dpt:513 limit: avg 10/min burst 5 LOG flags 0 level 6 prefix
`fp=svr2fw:4 a=DROP ''
0 0 DROP udp -- * * 192.168.168.1 0.0.0.0/0
state NEW udp dpt:513
0 0 LOG tcp -- * * !192.168.168.72 0.0.0.0/0
multiport dports 137,139,445 state NEW limit: avg 10/min burst 5 LOG flags 0
level 6
prefix `fp=svr2fw:5 a=DROP ''
0 0 DROP tcp -- * * !192.168.168.72 0.0.0.0/0
multiport dports 137,139,445 state NEW
0 0 LOG tcp -- * * 192.168.168.1 0.0.0.0/0
multiport dports 137,139,445 state NEW limit: avg 10/min burst 5 LOG flags 0
level 6
prefix `fp=svr2fw:6 a=DROP ''
0 0 DROP tcp -- * * 192.168.168.1 0.0.0.0/0
multiport dports 137,139,445 state NEW
0 0 LOG udp -- * * !192.168.168.72 0.0.0.0/0
state NEW udp spt:137 dpts:1024:65535 limit: avg 10/min burst 5 LOG flags 0
level 6
prefix `fp=svr2fw:7 a=DROP ''
0 0 DROP udp -- * * !192.168.168.72 0.0.0.0/0
state NEW udp spt:137 dpts:1024:65535
0 0 LOG udp -- * * 192.168.168.1 0.0.0.0/0
state NEW udp spt:137 dpts:1024:65535 limit: avg 10/min burst 5 LOG flags 0
level 6
prefix `fp=svr2fw:8 a=DROP ''
0 0 DROP udp -- * * 192.168.168.1 0.0.0.0/0
state NEW udp spt:137 dpts:1024:65535
1 59 LOG all -- * * !192.168.168.72 0.0.0.0/0
limit: avg 10/min burst 5 LOG flags 0 level 6 prefix `fp=svr2fw:9 a=DROP
''
1 59 DROP all -- * * !192.168.168.72 0.0.0.0/0
0 0 LOG all -- * * 192.168.168.1 0.0.0.0/0
limit: avg 10/min burst 5 LOG flags 0 level 6 prefix `fp=svr2fw:10 a=DROP
''
0 0 DROP all -- * * 192.168.168.1 0.0.0.0/0
21 3728 LOG udp -- * * 0.0.0.0/0 0.0.0.0/0
state NEW udp dpts:137:139 limit: avg 10/min burst 5 LOG flags 0 level 6 prefix
`fp=svr2fw:11 a=ACCEPT ''
63 9334 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0
state NEW udp dpts:137:139
1 60 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
multiport dports 137,139,445 state NEW limit: avg 10/min burst 5 LOG flags 0
level 6
prefix `fp=svr2fw:12 a=ACCEPT ''
1 60 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
multiport dports 137,139,445 state NEW
0 0 LOG udp -- * * 0.0.0.0/0 0.0.0.0/0
state NEW udp spt:137 dpts:1024:65535 limit: avg 10/min burst 5 LOG flags 0
level 6
prefix `fp=svr2fw:13 a=ACCEPT ''
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0
state NEW udp spt:137 dpts:1024:65535
3 408 common 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
limit: avg 10/min burst 5 LOG flags 0 level 6 prefix `fp=svr2fw:14 a=REJECT
''
0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0
And the log now shows: (Accept instead of Drop)
Aug 21 18:39:00 a310 kernel: fp=svr2fw:11 a=ACCEPT IN=eth3 OUT=
MAC=00:48:54:53:8a:52:00:48:54:53:6e:de:08:00 SRC=192.168.168.72
DST=192.168.11.255 LEN=273 TOS=0x00
PREC=0x00 TTL=64 ID=3899 PROTO=UDP SPT=138 DPT=138 LEN=253
Aug 21 18:39:00 a310 kernel: fp=svr2fw:11 a=ACCEPT IN=eth3 OUT=
MAC=00:48:54:53:8a:52:00:48:54:53:6e:de:08:00 SRC=192.168.168.72
DST=192.168.168.1 LEN=202 TOS=0x00
PREC=0x00 TTL=64 ID=3900 PROTO=UDP SPT=138 DPT=138 LEN=182
Aug 21 18:39:00 a310 kernel: fp=svr2fw:11 a=ACCEPT IN=eth3 OUT=
MAC=00:48:54:53:8a:52:00:48:54:53:6e:de:08:00 SRC=192.168.168.72
DST=192.168.11.255 LEN=202 TOS=0x00
PREC=0x00 TTL=64 ID=3901 PROTO=UDP SPT=138 DPT=138 LEN=182
The output of the fw2svr is:
Shorewall-1.4.6b Chain fw2svr at a310 - Thu Aug 21 18:41:03 BREDT 2003
Counters reset Thu Aug 21 18:29:08 BREDT 2003
Chain fw2svr (1 references)
pkts bytes target prot opt in out source destination
897 94587 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
state RELATED,ESTABLISHED
22 3221 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0
state NEW udp dpts:137:139
3 180 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
multiport dports 137,139,445 state NEW
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0
state NEW udp spt:137 dpts:1024:65535
0 0 all2all all -- * * 0.0.0.0/0 0.0.0.0/0
However, on the fw logs, where the samba master browser is, I get an error in
the nmbd.log: (for Samba):
[2003/08/21 15:27:28, 0] nmbd/nmbd_responserecordsdb.c:find_response_record(235)
find_response_record: response packet id 15594 received with no matching
record.
[2003/08/21 15:27:28, 0] nmbd/nmbd_responserecordsdb.c:find_response_record(235)
find_response_record: response packet id 15595 received with no matching
record.
[2003/08/21 15:27:28, 0] nmbd/nmbd_responserecordsdb.c:find_response_record(235)
find_response_record: response packet id 15596 received with no matching
record.
[2003/08/21 15:40:50, 0] libsmb/nmblib.c:send_udp(756)
Packet send failed to 192.168.11.255(138) ERRNO=Operation not permitted
[2003/08/21 15:40:50, 0] libsmb/nmblib.c:send_udp(756)
Packet send failed to 192.168.168.255(138) ERRNO=Operation not permitted
This might not be related to Shorewall, I am still trying to find out what / why
is this happening.
Please advise if you have any suggestions.
Regards,
>
> From: Tom Eastep <teastep@shorewall.net>
> Subject: Re: [Shorewall-users] DROP in Rules, with smb port 138 ?
> Date: 22/08/2003 1:09:20
> To: deya@ozemail.com.au
> CC: shorewall-users@lists.shorewall.net
>
> On Thu, 2003-08-21 at 07:46, deya@ozemail.com.au wrote:
>
> >
> >
##############################################################################
> > # WST to Firewall
> > # Change Next Address When completed.
> > #
> > DROP:info svr:!192.168.168.72,!192.168.168.1 fw
udp 137:139,513
>
> The above syntax is wrong and with the version of Shorewall you are
> using (you don''t say what it is), it is doing the wrong thing.
>
> A better idea is to:
>
> ACCEPT svr:192.168.168.72,192.168.168.1 fw udp 137:139,513
> DROP:info svr fw udp 137:139,513
>
> Using Shorewall 1.4.6b, you should be able to code this as:
>
> DROP:info svr:!192.168.168.72,192.168.168.1 fw udp 137:139,513
>
> And have it do what you want.
>
> As a final request, in the future if you want to sent the output of
> iptables, use "shorewall show <chain>". It prints the chain
contents in
> the format that I want to see it in.
>
> -Tom
> --
> Tom Eastep \ Shorewall - iptables made easy
> Shoreline, \ http://shorewall.net
> Washington USA \ teastep@shorewall.net
>
>
This message was sent through MyMail http://www.mymail.com.au
On Thu, 2003-08-21 at 08:50, deya@ozemail.com.au wrote:> Dear Tom, > > Thanks for your prompt support and help. > You did a agreat job with this software, I deeply appreciate your efforts, especially in supporting it. > > The mistake, seems, as I didn''t get this error again yet (I hope) is : > !192.168.168.72,!192.168.168.1 ( I used it twice, instead of once at the very beginning of the line). This > seems to have corrected the problem. >It is STILL NOT DOING WHAT YOU WANT -- read my followup posts. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net