Hi All, I emailed the list yesturday, asking for help, but i went back and rethought my questions. I guess what I need to ask is there any "recipies" I could follow. I have 5 web servers in the DMZ serving both http and https, I have an ftp server in the dmz that needs outside access, I have an several ssh servers that need outside access as well. My mail servers (2 ea) needs both smtp and imap on ports 993 and 465 and I have two dns servers. the webservers have a many to one nat currently 66.235.43.xx to 192.168.1.xx. Our current firewall is serving the purpose but it is not as managable as we would like and there is no real support for it. I am running Debian with the deb package on the new firewall. I have added all the external to internal mapping in the nat file. I have made a stab at the rules file but I am not really sure if its correct. My second question is if there is anyway I can test this before I put it in production. Here are my policy entries: #SOURCE DEST POLICY LOG LIMIT:BURST # LEVEL loc net ACCEPT loc dmz ACCEPT net all DROP info all all REJECT info here are my rules: #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ # PORT PORT(S) DEST LIMIT GROUP # Accept DNS connections from the firewall to the Internet # ACCEPT fw net tcp 53 ACCEPT fw net udp 53 # # # Accept SSH connections from the local network to the firewall and DMZ # ACCEPT loc fw tcp 22 ACCEPT loc dmz tcp 22 # # Make ping work bi-directionally between the dmz, net, Firewall and local zone # (assumes that the loc-> net policy is ACCEPT). # ACCEPT net fw icmp 8 ACCEPT loc fw icmp 8 ACCEPT dmz fw icmp 8 ACCEPT loc dmz icmp 8 ACCEPT dmz loc icmp 8 ACCEPT dmz net icmp 8 ACCEPT fw net icmp ACCEPT fw loc icmp ACCEPT fw dmz icmp # # # Web ACCEPT net dmz tcp 80 ACCEPT loc dmz tcp 80 ACCEPT net dmz tcp 443 ACCEPT loc dmz tcp 443 # FTP ACCEPT net dmz tcp 21 ACCEPT loc dmz tcp 21 # DNS #ACTION SOURCE DEST PROTO DEST COMMENTS # PORT(S) ACCEPT net dmz:192.168.1.5 udp domain #UDP DNS from ACCEPT net dmz:192.168.1.6 udp domain #Internet ACCEPT net dmz:192.168.1.5 tcp domain #TCP DNS from ACCEPT net dmz:192.168.1.6 tcp domain #Internet ACCEPT loc dmz:192.168.1.5 udp domain #UDP DNS from ACCEPT loc dmz:192.168.1.6 udp domain #Local Network ACCEPT loc dmz:192.168.1.5 tcp domain #TCP DNS from ACCEPT loc dmz:192.168.1.6 tcp domain #Local Network ACCEPT fw dmz:192.168.1.5 udp domain #UDP DNS from ACCEPT fw dmz:192.168.1.6 udp domain #the Firewall ACCEPT fw dmz:192.168.1.5 tcp domain #TCP DNS from ACCEPT fw dmz:192.168.1.6 tcp domain #the Firewall ACCEPT dmz:192.168.1.5 net udp domain #UDP DNS to ACCEPT dmz:192.168.1.6 net udp domain #the Internet ACCEPT dmz:192.168.1.5 net tcp domain #TCPP DNS to ACCEPT dmz:192.168.1.5 net tcp domain #the Internet # Mail ACCEPT net dmz:192.168.1.20 tcp smtp #Mail from ACCEPT net dmz:192.168.1.25 tcp smtp #Internet ACCEPT net dmz:192.168.1.20 tcp imap #Imap from ACCEPT net dmz:192.168.1.25 tcp imap #Internet ACCEPT net dmz:192.168.1.20 tcp imaps #Imap from ACCEPT net dmz:192.168.1.25 tcp imaps #Internet ACCEPT net dmz:192.168.1.20 tcp ssmtp #Imap from ACCEPT net dmz:192.168.1.25 tcp ssmtp #Internet ACCEPT loc dmz:192.168.1.20 tcp smtp #Mail from local ACCEPT loc dmz:192.168.1.25 tcp smtp #Network ACCEPT loc dmz:192.168.1.20 tcp imap #Imap from local ACCEPT loc dmz:192.168.1.25 tcp imap #Network ACCEPT loc dmz:192.168.1.20 tcp imaps #Imap from local ACCEPT loc dmz:192.168.1.25 tcp imaps #Network ACCEPT loc dmz:192.168.1.20 tcp ssmtp #Imap from local ACCEPT loc dmz:192.168.1.25 tcp ssmtp #Network ACCEPT fw dmz:192.168.1.20 tcp smtp #Mail from the ACCEPT fw dmz:192.168.1.25 tcp smtp #Firewall ACCEPT dmz:192.168.1.20 net tcp smtp #Mail to the ACCEPT dmz:192.168.1.25 net tcp smtp #Internet here is a sample of nat file: #EXTERNAL INTERFACE INTERNAL ALL LOCAL # INTERFACES # 66.235.241.3 eth0 192.168.1.250 66.235.241.5 eth0 192.168.1.5 66.235.241.6 eth0 192.168.1.6 66.235.241.7 eth0 192.168.4.5 66.235.241.9 eth0 192.168.1.254 66.235.241.10 eth0 192.168.2.10 66.235.241.11 eth0 192.168.1.101 66.235.241.12 eth0 192.168.1.102 66.235.241.13 eth0 192.168.1.103 66.235.241.14 eth0 192.168.1.104 I guess I need a sanity check on my rules before I go put this in production. Any input would be great. Thanks, Sean Roe ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> Hi All, > > I emailed the list yesturday, asking for help, but i went back and > rethought my questions. I guess what I need to ask is there any > "recipies" I could follow. I have 5 web servers in the DMZ serving both > http and https, I have an ftp server in the dmz that needs outside > access, I have an several ssh servers that need outside access as well. > My mail servers (2 ea) needs both smtp and imap on ports 993 and 465 and > I have two dns servers. the webservers have a many to one nat currently > 66.235.43.xx to 192.168.1.xx. Our current firewall is serving the > purpose but it is not as managable as we would like and there is no real > support for it. I am running Debian with the deb package on the new > firewall. I have added all the external to internal mapping in the nat > file. I have made a stab at the rules file but I am not really sure if > its correct.See below...> > My second question is if there is anyway I can test this before I put it > in production.Not really, that is why I''m a night hawk. ;-) <snip>> and DMZ > # > ACCEPT loc fw tcp 22 > ACCEPT loc dmz tcp 22 > #The loc 2 dmz rule is not required as you have a policy of "loc dmz ACCEPT" <snip>> # Web > ACCEPT net dmz tcp 80 > ACCEPT loc dmz tcp 80 > ACCEPT net dmz tcp 443 > ACCEPT loc dmz tcp 443All the loc - dmz rules are useless, as you have the policy already. <snip> Sorry, I don''t use the nat file, can''t say "for sure".> > I guess I need a sanity check on my rules before I go put this in > production. > > Any input would be great. >With public ip addresses you may want to look at proxyarp, it''s in the docs. Jerry ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Jerry Vonau wrote: <snipped for brevity>>All the loc - dmz rules are useless, as you have the policy already. > ><snip> > > >Okay....I removed thoose entries----Thanks>Sorry, I don''t use the nat file, can''t say "for sure". > > >With public ip addresses you may want to look at proxyarp, it''s in the >docs. > >Jerry > > >I think I understand the nat part of the setup fairly well, and it looks like it is the least impactful on our curent setup One other question I have is this: our loc interface is actually a T-1 to our office. It is currently the 192.168.5.1 interface the 192.168.5 range is just the point to point connection between the two routers. I need to show/allow the 192.168.4.xx traffic which is at the end of the 192.168.5.2 T-1 When I tried this initially last week with shorewall, it blew away the routing table I copied from the existing firewall, how do I keep that and allow the 192.168.4.xx traffic to be considered loc traffic? Thanks, Sean ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Sean Roe wrote:> Jerry Vonau wrote: > <snipped for brevity> > >> All the loc - dmz rules are useless, as you have the policy already. >> >> <snip> >> >> >> > Okay....I removed thoose entries----Thanks > > >> Sorry, I don''t use the nat file, can''t say "for sure". >> >> >> With public ip addresses you may want to look at proxyarp, it''s in the >> docs. >> >> Jerry >> >> >> > I think I understand the nat part of the setup fairly well, and it > looks like it is the least impactful on our curent setup > > One other question I have is this: > > our loc interface is actually a T-1 to our office. It is currently > the 192.168.5.1 interface the 192.168.5 range is just the point to > point connection between the two routers. I need to show/allow the > 192.168.4.xx traffic which is at the end of the 192.168.5.2 T-1 > > When I tried this initially last week with shorewall, it blew away the > routing table I copied from the existing firewall, how do I keep that > and allow the 192.168.4.xx traffic to be considered loc traffic? > > > Thanks, > SeanI was just looking at the docs, do I need to set up some sort of tunnel in the shorewall config? I guess I should say that this firewall is in the web server colocation facility and the office connection (loc interface) is connected via T-1 behind the firewall Thanks, Sean ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Sean Roe wrote:>> Sean > > I was just looking at the docs, do I need to set up some sort of tunnel > in the shorewall config? I guess I should say that this firewall is in > the web server colocation facility and the office connection (loc > interface) is connected via T-1 behind the firewallYou should be reading http://www1.shorewall.net/Multiple_Zones.html -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:>Sean Roe wrote: > > > >>>Sean >>> >>> >>I was just looking at the docs, do I need to set up some sort of tunnel >>in the shorewall config? I guess I should say that this firewall is in >>the web server colocation facility and the office connection (loc >>interface) is connected via T-1 behind the firewall >> >> > >You should be reading http://www1.shorewall.net/Multiple_Zones.html > >-Tom >-- >Tom Eastep \ Nothing is foolproof to a sufficiently talented fool >Shoreline, \ http://shorewall.net >Washington USA \ teastep@shorewall.net >PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key > >Kewl!!! Thanks. Sean ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> Sean Roe wrote: > > > Jerry Vonau wrote: > > <snipped for brevity> > > > >> All the loc - dmz rules are useless, as you have the policy already. > >> > >> <snip> > >> > >> > >> > > Okay....I removed thoose entries----Thanks > > > > > >> Sorry, I don''t use the nat file, can''t say "for sure". > >> > >> > >> With public ip addresses you may want to look at proxyarp, it''s in the > >> docs. > >> > >> Jerry > >> > >> > >> > > I think I understand the nat part of the setup fairly well, and it > > looks like it is the least impactful on our curent setup > > > > One other question I have is this: > > > > our loc interface is actually a T-1 to our office. It is currently > > the 192.168.5.1 interface the 192.168.5 range is just the point to > > point connection between the two routers. I need to show/allow the > > 192.168.4.xx traffic which is at the end of the 192.168.5.2 T-1 > > > > When I tried this initially last week with shorewall, it blew away the > > routing table I copied from the existing firewall, how do I keep that > > and allow the 192.168.4.xx traffic to be considered loc traffic? > > > > > > Thanks, > > Sean > > I was just looking at the docs, do I need to set up some sort of tunnel > in the shorewall config? I guess I should say that this firewall is in > the web server colocation facility and the office connection (loc > interface) is connected via T-1 behind the firewall > > Thanks, > SeanFunny you brought that up, the lastest patch does that. I have a remote subnet routed this way, using a tun device and the "copy" feature, but the theory is the same. Setup your remote subnet as a "provider", and mark the allowed traffic in tcrule. I''d need to see some interface and routing stuff, and all your config files. Jerry ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Sean Roe wrote:> ... > My second question is if there is anyway I can test this before I put it > in production. > > Here are my policy entries: > #SOURCE DEST POLICY LOG LIMIT:BURST > # LEVEL > loc net ACCEPT > loc dmz ACCEPT > net all DROP info > all all REJECT infoSome general advice to help you troubleshoot: You should put more specific policies than that cover all the combinations of your zones. Not because they''re required to work, but when you get error messages, they will be a lot more specific, so troubleshooting is easier. If you''re running a proxy server in dmz, you probably should have a ''dmz all ACCEPT'' policy, or at least a rule that allows outgoing traffic on any TCP port from that server. Otherwise you''ll have users complaining that they can''t get to their favourite web server on port 36174 or whatever.> ... > here are my rules: > ... > ACCEPT fw net tcp 53 > ACCEPT fw net udp 53Don''t mix port names & numbers - use one convention and stick with it. Some of your ping rules seem either unnecessary or a bad idea:> ACCEPT net fw icmp 8 > ACCEPT dmz fw icmp 8 > ACCEPT dmz loc icmp 8 > ACCEPT fw loc icmp> ... > ACCEPT net dmz:192.168.1.5 udp domain #UDP DNS from > ACCEPT net dmz:192.168.1.6 udp domain #InternetI would use either a variable or a subzone instead of retyping those IPs every time - saves you from typos.> ... > ACCEPT net dmz:192.168.1.20 tcp imap #Imap from > ACCEPT net dmz:192.168.1.25 tcp imap #InternetUnsecured IMAP across an Internet connection (well, across any connection, really) is a bad idea.> ... > I guess I need a sanity check on my rules before I go put this in > production.When you put in more specific policies, you should add logging - even ACCEPT policies initially - so that you can see what''s going on when it happens. Implementing a firewall that works from day one is almost impossible - for most of us it''s a matter of putting in something mostly workable, then tuning from there. -- Paul <http://paulgear.webhop.net> -- Did you know? Microsoft Internet Explorer and Outlook have a poor track record for security <http://www.kb.cert.org/vuls/id/713878>. Why not try one of the more secure alternatives from <http://mozilla.org>?
Paul Gear wrote:> ... > If you''re running a proxy server in dmz, you probably should have a ''dmz > all ACCEPT'' policy, or at least a rule that allows outgoing traffic on > any TCP port from that server. Otherwise you''ll have users complaining > that they can''t get to their favourite web server on port 36174 or whatever.What drugs *am* i on? That should have been ''dmz net ACCEPT''! -- Paul <http://paulgear.webhop.net> -- Did you know? If you use two dashes followed by a space as your signature separator, good email programs will chop them off automatically, reducing noise in email replies.
OK, I think understand. I just have one question (so far..) does the loc1 zone inherit the rules from the loc zone as a nested zone? BTW we dont have a squid box yet...its on my list to do Sean Tom Eastep wrote:>Sean Roe wrote: > > > >>>Sean >>> >>> >>I was just looking at the docs, do I need to set up some sort of tunnel >>in the shorewall config? I guess I should say that this firewall is in >>the web server colocation facility and the office connection (loc >>interface) is connected via T-1 behind the firewall >> >> > >You should be reading http://www1.shorewall.net/Multiple_Zones.html > >-Tom >-- >Tom Eastep \ Nothing is foolproof to a sufficiently talented fool >Shoreline, \ http://shorewall.net >Washington USA \ teastep@shorewall.net >PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key > >------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Last time through and I swear I''ll be quiet: If you see any brain cramps please let me know. /Hosts file:/ #ZONE HOST(S) OPTIONS loc1 eth1:192.168.4.0/24 /Zone file:/ net Internet The big bad Internet loc1 Gilbert Gilbert local network loc Pipe2Gilbert T-1 to Gilbert dmz DMZ Phoenix COLO zone. /Interfaces file:/ net eth0 detect rfc1918 loc eth1 detect dmz eth2 detect /Policy file:/ #SOURCE DEST POLICY LOG LIMIT:BURST # LEVEL loc net ACCEPT loc dmz ACCEPT loc loc1 ACCEPT loc1 loc ACCEPT net all DROP info all all REJECT info /rules file:/ # Accept DNS connections from the firewall to the Internet # ACCEPT fw net tcp 53 ACCEPT fw net udp 53 # # # Accept SSH connections from the local network to the firewall and DMZ # ACCEPT loc fw tcp 22 /Will the following allow these IPS to access us from outside?/ ACCEPT dmz:68.108.204.21 loc:192.168.1.5 tcp 22 ACCEPT dmz:68.109.133.238 loc:192.168.1.5 tcp 22 ACCEPT dmz:207.218.250.61 loc:192.168.1.5 tcp 22 ACCEPT dmz:68.2.87.236 loc:192.168.1.5 tcp 22 # # Make ping work bi-directionally between the dmz, net, Firewall and local zone # (assumes that the loc-> net policy is ACCEPT). # ACCEPT net fw icmp 8 ACCEPT loc fw icmp 8 ACCEPT loc fw icmp 8 ACCEPT dmz fw icmp 8 ACCEPT dmz loc icmp 8 ACCEPT dmz net icmp 8 ACCEPT fw net icmp ACCEPT fw loc icmp ACCEPT fw dmz icmp # # # Web ACCEPT net dmz tcp 80 ACCEPT net dmz tcp 443 # FTP ACCEPT net dmz:192.168.1.201 tcp 21 # DNS #ACTION SOURCE DEST PROTO DEST COMMENTS # PORT(S) ACCEPT net dmz:192.168.1.5 udp 53 #UDP DNS from ACCEPT net dmz:192.168.1.6 udp 53 #Internet ACCEPT net dmz:192.168.1.5 tcp 53 #TCP DNS from ACCEPT net dmz:192.168.1.6 tcp 53 #Internet ACCEPT fw dmz:192.168.1.5 udp 53 #UDP DNS from ACCEPT fw dmz:192.168.1.6 udp 53 #the Firewall ACCEPT fw dmz:192.168.1.5 tcp 53 #TCP DNS from ACCEPT fw dmz:192.168.1.6 tcp 53 #the Firewall ACCEPT dmz:192.168.1.5 net udp 53 #UDP DNS to ACCEPT dmz:192.168.1.6 net udp 53 #the Internet ACCEPT dmz:192.168.1.5 net tcp 53 #TCPP DNS to ACCEPT dmz:192.168.1.5 net tcp 53 #the Internet # Mail ACCEPT net dmz:192.168.1.20 tcp 25 #Mail from ACCEPT net dmz:192.168.1.25 tcp 25 #Internet ACCEPT net dmz:192.168.1.20 tcp 143 #Imap from ACCEPT net dmz:192.168.1.25 tcp 143 #Internet ACCEPT net dmz:192.168.1.20 tcp 993 #Imap from ACCEPT net dmz:192.168.1.25 tcp 993 #Internet ACCEPT net dmz:192.168.1.20 tcp 465 #Imap from ACCEPT net dmz:192.168.1.25 tcp 465 #Internet ACCEPT fw dmz:192.168.1.20 tcp 25 #Mail from the ACCEPT fw dmz:192.168.1.25 tcp 25 #Firewall ACCEPT dmz:192.168.1.20 net tcp 25 #Mail to the ACCEPT dmz:192.168.1.25 net tcp 25 #Internet Thanks, Sean Sean Roe wrote:> OK, I think understand. I just have one question (so far..) does the > loc1 zone inherit the rules from the loc zone as a nested zone? > > BTW we dont have a squid box yet...its on my list to do > > Sean > > > Tom Eastep wrote: > >> Sean Roe wrote: >> >> >> >>>> Sean >>>> >>> >>> I was just looking at the docs, do I need to set up some sort of tunnel >>> in the shorewall config? I guess I should say that this firewall is in >>> the web server colocation facility and the office connection (loc >>> interface) is connected via T-1 behind the firewall >>> >> >> >> You should be reading http://www1.shorewall.net/Multiple_Zones.html >> >> -Tom >> -- >> Tom Eastep \ Nothing is foolproof to a sufficiently talented fool >> Shoreline, \ http://shorewall.net >> Washington USA \ teastep@shorewall.net >> PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key >> >> > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Sean Roe wrote:> OK, I think understand. I just have one question (so far..) does the > loc1 zone inherit the rules from the loc zone as a nested zone? >If you use CONTINUE policies, yes. See http://shorewall.net/Documentation.htm#Nested -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:>Sean Roe wrote: > > >>OK, I think understand. I just have one question (so far..) does the >>loc1 zone inherit the rules from the loc zone as a nested zone? >> >> >> > >If you use CONTINUE policies, yes. See >http://shorewall.net/Documentation.htm#Nested > >-Tom >-- >Tom Eastep \ Nothing is foolproof to a sufficiently talented fool >Shoreline, \ http://shorewall.net >Washington USA \ teastep@shorewall.net >PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key > >Tom et al, Thanks all for your help. I think its ready to rock. I changed policy as per suggested above, and I think I am ready to deploy this. I am looking for the section on speeding up the switch over for tonight. something about gratutius arp I think? Thanks, Sean ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Sean Roe wrote:> Tom Eastep wrote: > >> Sean Roe wrote: >> >> >>> OK, I think understand. I just have one question (so far..) does the >>> loc1 zone inherit the rules from the loc zone as a nested zone? >>> >>> >> >> If you use CONTINUE policies, yes. See >> http://shorewall.net/Documentation.htm#Nested >> >> -Tom >> -- >> Tom Eastep \ Nothing is foolproof to a sufficiently talented fool >> Shoreline, \ http://shorewall.net >> Washington USA \ teastep@shorewall.net >> PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key >> >> > Tom et al, > > Thanks all for your help. I think its ready to rock. I changed policy > as per suggested above, and I think I am ready to deploy this. I am > looking for the section on speeding up the switch over for tonight. > something about gratutius arp I think? >http://www.shorewall.net/ProxyARP.htm -> "ARP Cache" -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key