Bram Mertens
2005-Feb-13 14:57 UTC
How to allow specific services for machines in LAN behind router?
Hi I know I still need to learn a lot about firewalls so if I''ve missed some doc I should have read don''t hesitate to point it out to me. I have set up shorewall on my desktop and my laptop and everything appears to be working fine but now I''d like to allow certain services (like shh, rsync, unison, http) between these two PC''s. My LAN looks like this: ISP | Cable-modem | dhcp <- assigned by dhcp from ISP Router (Linksys WRT54G) | 192.168.1.1 | | | (wireless) eth0 eth(1|2) 192.168.1.1xx 192.168.1.1yy <- assigned by dhcp on router desktop laptop (debian/testing) (debian/testing) I''m running version 2.0.15-1 on both the desktop and the laptop. What should I add to allow me to run unison and scp to and from my desktop and my laptop without opening this to the outside world? TIA -- # Mertens Bram "M8ram" <bram-mertens@linux.be> Linux User #349737 # # debian testing kernel 2.6.8-1-686 i686 512MB RAM # # 15:17:30 up 4 days, 19:04, 2 users, load average: 0.60, 0.36, 0.27 #
Tom Eastep
2005-Feb-13 15:43 UTC
Re: How to allow specific services for machines in LAN behind router?
Bram Mertens wrote:> > I''m running version 2.0.15-1 on both the desktop and the laptop. > > What should I add to allow me to run unison and scp to and from my > desktop and my laptop without opening this to the outside world? >For each service that you want to allow from other local systems add a rule of the form: ACCEPT net:192.168.1.0/24 fw <protocol> <port> So for SSH: ACCEPT net:192.168.1.0/24 fw tcp 22 -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
Bram Mertens
2005-Feb-14 18:38 UTC
Re: How to allow specific services for machines in LAN behind router?
On Sun, 2005-02-13 at 07:43 -0800, Tom Eastep wrote:> Bram Mertens wrote: > > > > I''m running version 2.0.15-1 on both the desktop and the laptop. > > > > What should I add to allow me to run unison and scp to and from my > > desktop and my laptop without opening this to the outside world? > > > For each service that you want to allow from other local systems add a > rule of the form: > > ACCEPT net:192.168.1.0/24 fw <protocol> <port> > > So for SSH: > > ACCEPT net:192.168.1.0/24 fw tcp 22Thanks, I still have one question about this though. If I understand this correctly this would allow ssh for machines with an IP address between 192.168.1.0 and 192.168.1.255. Is there a way to allow only the IP addresses between 192.168.1.100 and 192.168.1.149? TIA Bram -- # Mertens Bram "M8ram" <bram-mertens@linux.be> Linux User #349737 # # debian testing kernel 2.6.8-1-686 i686 512MB RAM # # 19:32:19 up 5 days, 23:19, 7 users, load average: 1.28, 1.13, 0.88 #
Tom Eastep
2005-Feb-14 19:46 UTC
Re: How to allow specific services for machines in LAN behind router?
Bram Mertens wrote:> >>For each service that you want to allow from other local systems add a >>rule of the form: >> >>ACCEPT net:192.168.1.0/24 fw <protocol> <port> >> >>So for SSH: >> >>ACCEPT net:192.168.1.0/24 fw tcp 22 > > > Thanks, I still have one question about this though. > > If I understand this correctly this would allow ssh for machines with an > IP address between 192.168.1.0 and 192.168.1.255. > > Is there a way to allow only the IP addresses between 192.168.1.100 and > 192.168.1.149? >When working with networks, it is always best to pretend that human beings were given either 8 or 16 fingers rather than 10. Then you would be thinking of "IP addresses between 192.168.1.128 and 192.168.1.159" which would be: ACCEPT net:192.168.1.128/27 fw tcp 22 But if you don''t sleep well unless all of the boundaries in your life are at multiples of 10 then: a) If you run Shorewall 2.2.0 and your kernel and iptables support the iprange match (look at the output of "shorewall check" -- it will be near the top), then you can write: ACCEPT net:192.168.1.100-192.168.1.149 fw tcp 22 b) If your kernel and iptables do not have the proper support, then you need to use the "shorewall iprange" command: gateway:/etc/racoon# shorewall iprange 192.168.1.100-192.168.1.149 192.168.1.100/30 192.168.1.104/29 192.168.1.112/28 192.168.1.128/28 192.168.1.144/30 192.168.1.148/31 gateway:/etc/racoon# Then for each of those networks, you need a rule: ACCEPT net:192.168.1.100/30 fw tcp 22 ACCEPT net:192.168.1.104/29 fw tcp 22 ... (see why powers of 2 are preferred to multiples of 10?) -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
Bram Mertens
2005-Feb-14 20:01 UTC
Re: How to allow specific services for machines in LAN behind router?
On Mon, 2005-02-14 at 11:46 -0800, Tom Eastep wrote: [...]> > If I understand this correctly this would allow ssh for machines with an > > IP address between 192.168.1.0 and 192.168.1.255. > > > > Is there a way to allow only the IP addresses between 192.168.1.100 and > > 192.168.1.149? > > > > When working with networks, it is always best to pretend that human > beings were given either 8 or 16 fingers rather than 10. Then you would > be thinking of "IP addresses between 192.168.1.128 and 192.168.1.159" > which would be: > > ACCEPT net:192.168.1.128/27 fw tcp 22/27 because that would be the VLSM with a Subnet Mask of 255.255.255.224 (as per Table 3. VLSM in the Shorewall Setup Guide)> But if you don''t sleep well unless all of the boundaries in your life > are at multiples of 10 then:[...]> (see why powers of 2 are preferred to multiples of 10?)Point taken... <scratch my head> So... It would be easier to configure the dhcp of my router to provide IP addresses starting from 192.168.1.128 rather than 192.168.1.100 and have it assign only 31 addresses in stead of 50. That way I can use the ACCEPT net:192.168.1.128/27 fw tcp 22 rule you suggested, right? TIA Bram -- # Mertens Bram "M8ram" <bram-mertens@linux.be> Linux User #349737 # # debian testing kernel 2.6.8-1-686 i686 512MB RAM # # 20:54:36 up 6 days, 41 min, 7 users, load average: 1.34, 0.93, 0.74 #
Tom Eastep
2005-Feb-14 20:09 UTC
Re: How to allow specific services for machines in LAN behind router?
Bram Mertens wrote:> > So... > > It would be easier to configure the dhcp of my router to provide IP > addresses starting from 192.168.1.128 rather than 192.168.1.100 and have > it assign only 31 addresses in stead of 50.It could assign all 32... (192.168.1.128-192.168.1.159 is a range of 32 addresses).> That way I can use the > ACCEPT net:192.168.1.128/27 fw tcp 22 > rule you suggested, right? >Yes. -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
Bram Mertens
2005-Feb-15 13:13 UTC
Re: How to allow specific services for machines in LAN behind router?
On Mon, 2005-02-14 at 12:09 -0800, Tom Eastep wrote:> Bram Mertens wrote: > > > > > So... > > > > It would be easier to configure the dhcp of my router to provide IP > > addresses starting from 192.168.1.128 rather than 192.168.1.100 and have > > it assign only 31 addresses in stead of 50. > > It could assign all 32... (192.168.1.128-192.168.1.159 is a range of 32 > addresses). > > > That way I can use the > > ACCEPT net:192.168.1.128/27 fw tcp 22 > > rule you suggested, right?Unfortunately I still seem to do something wrong... I have edited my router, restarted the connection on the desktop and on the laptop so their IP addresses are now 192.168.1.128 and 198.168.1.129 When shorewall is cleared on both machines I can log in through ssh in both directions. When I start the firewall on the desktop, I can log in on the laptop from the desktop but ssh connections from the laptop to the desktop are blocked (on the laptop, as dmesg on the laptop shows) and ssh returns a connection timed out error. If I start the firewall on the laptop I get a connection refused when I try to log in on the desktop from the laptop. Logging in on the laptop from the desktop returns the connection timed out error. The output of dmesg looks like: Shorewall:rfc1918:DROP:IN=eth0 OUTMAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=192.168.1.129 DST=192.168.1.128 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=25516 DF PROTO=TCP SPT=32776 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 Should I remove the norfc1918 option from /etc/shorewall/interfaces? TIA -- # Mertens Bram "M8ram" <bram-mertens@linux.be> Linux User #349737 # # debian testing kernel 2.6.8-1-686 i686 512MB RAM # # 13:45:38 up 6 days, 17:32, 8 users, load average: 0.40, 0.30, 0.20 #
Jeff
2005-Feb-15 13:38 UTC
Re: How to allow specific services for machinesin LAN behind router?
Hey Bram; The ''DROP'' entry states that the packet was dropped because of the norfc1918 option on eth0 in your interfaces file. Yes you should remove it as you have a 192.168.1.0 network on both ethernet interfaces and should NOT be used. Shorewall:rfc1918:DROP:IN=eth0 OUT BTW You *might* also keep in mind that taking the time to remove the MAC address is probably pointless. That info is really ONLY useful to anyone on your local network (or maybe one hop away). Jeff ----- Original Message ----- From: "Bram Mertens" <bram-mertens@linux.be> To: "Mailing List for Shorewall Users" <shorewall-users@lists.shorewall.net> Sent: Tuesday, February 15, 2005 8:13 AM Subject: Re: [Shorewall-users] How to allow specific services for machinesin LAN behind router?> On Mon, 2005-02-14 at 12:09 -0800, Tom Eastep wrote: > > Bram Mertens wrote: > > > > > > > > So... > > > > > > It would be easier to configure the dhcp of my router to provide IP > > > addresses starting from 192.168.1.128 rather than 192.168.1.100 andhave> > > it assign only 31 addresses in stead of 50. > > > > It could assign all 32... (192.168.1.128-192.168.1.159 is a range of 32 > > addresses). > > > > > That way I can use the > > > ACCEPT net:192.168.1.128/27 fw tcp 22 > > > rule you suggested, right? > > Unfortunately I still seem to do something wrong... > > I have edited my router, restarted the connection on the desktop and on > the laptop so their IP addresses are now 192.168.1.128 and 198.168.1.129 > > When shorewall is cleared on both machines I can log in through ssh in > both directions. > When I start the firewall on the desktop, I can log in on the laptop > from the desktop but ssh connections from the laptop to the desktop are > blocked (on the laptop, as dmesg on the laptop shows) and ssh returns a > connection timed out error. > > If I start the firewall on the laptop I get a connection refused when I > try to log in on the desktop from the laptop. Logging in on the laptop > from the desktop returns the connection timed out error. > > The output of dmesg looks like: > Shorewall:rfc1918:DROP:IN=eth0 OUT> MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=192.168.1.129 > DST=192.168.1.128 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=25516 DF PROTO=TCP > SPT=32776 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 > > Should I remove the norfc1918 option from /etc/shorewall/interfaces? > > TIA > -- > # Mertens Bram "M8ram" <bram-mertens@linux.be> Linux User #349737 # > # debian testing kernel 2.6.8-1-686 i686 512MB RAM # > # 13:45:38 up 6 days, 17:32, 8 users, load average: 0.40, 0.30, 0.20 # > > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe:https://lists.shorewall.net/mailman/listinfo/shorewall-users> Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm >
Bram Mertens
2005-Feb-15 14:16 UTC
Re: How to allow specific services for machinesin LAN behind router?
On Tue, 2005-02-15 at 08:38 -0500, Jeff wrote:> Hey Bram; > > The ''DROP'' entry states that the packet was dropped because of the norfc1918 > option on eth0 in your interfaces file. Yes you should remove it as you have > a 192.168.1.0 network on both ethernet interfaces and should NOT be used. > > Shorewall:rfc1918:DROP:IN=eth0 OUTThanks everything seems to be working fine now!> BTW You *might* also keep in mind that taking the time to remove the MAC > address is probably pointless. That info is really ONLY useful to anyone on > your local network (or maybe one hop away).How about for one of my neighbours who also have a wifi network? Still it seemed better not to have the MAC address archived on the web... But you''re probably right. Thanks for all the quick responses! Regards Bram -- # Mertens Bram "M8ram" <bram-mertens@linux.be> Linux User #349737 # # debian testing kernel 2.6.8-1-686 i686 512MB RAM # # 15:13:47 up 6 days, 19:00, 8 users, load average: 0.11, 0.38, 0.44 #
Jeff
2005-Feb-15 14:28 UTC
Re: How to allow specific services formachinesin LAN behind router?
Comments inline ----- Original Message ----- From: "Bram Mertens" <bram-mertens@linux.be> To: "Mailing List for Shorewall Users" <shorewall-users@lists.shorewall.net> Sent: Tuesday, February 15, 2005 9:16 AM Subject: Re: [Shorewall-users] How to allow specific services formachinesin LAN behind router?> On Tue, 2005-02-15 at 08:38 -0500, Jeff wrote: > > Hey Bram; > > > > The ''DROP'' entry states that the packet was dropped because of thenorfc1918> > option on eth0 in your interfaces file. Yes you should remove it as youhave> > a 192.168.1.0 network on both ethernet interfaces and should NOT beused.> > > > Shorewall:rfc1918:DROP:IN=eth0 OUT> > Thanks everything seems to be working fine now! > > > BTW You *might* also keep in mind that taking the time to remove the MAC > > address is probably pointless. That info is really ONLY useful to anyoneon> > your local network (or maybe one hop away). > > How about for one of my neighbours who also have a wifi network? Still > it seemed better not to have the MAC address archived on the web... But > you''re probably right.That''s what the maclist option can be used for. You put all of the wireless MAC addresses that YOU own in a file and add the option to the interface file. I thought WEP would be useful in this case but that is too easily hacked and a PITA between OSs. Some of us use IPSec over WiFi for this reason but that''s another thread. Cheers.> > Thanks for all the quick responses! > > Regards > > Bram > -- > # Mertens Bram "M8ram" <bram-mertens@linux.be> Linux User #349737 # > # debian testing kernel 2.6.8-1-686 i686 512MB RAM # > # 15:13:47 up 6 days, 19:00, 8 users, load average: 0.11, 0.38, 0.44 # > > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe:https://lists.shorewall.net/mailman/listinfo/shorewall-users> Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm >
My first mail required moderator approval due to its size, so I''ve uploaded the image to my server. Here is the URL. Cheers! http://www.netvity.net/~david/network.png David Choo wrote:> Dear All, > > My office is currently undergoing a IP Migration, and after much > convincing, I managed to get my bosses to go with Linux and IPTables. > Not a surprising change after we''re shifting most of our servers to > Linux for the past 6 months to good effect. > > However, I''m currently hitting some serious problems, and I''ve > searched for quite a while but was unable to get any info. Would like > your kind assistance. > > Attached to the email, is the completed network diagram, which will > show clearly how things are supposed to work. > > Problem 1. Routing Problems. > > At the present moment, none of my site offices can route to any of > these new IPs. Tests are as follows. > > 1. Connection from 3600 Router goes through everywhere beautifully. > the command "ip route 202.14.87.32 255.255.255.240 172.16.1.1" > was entered into the router. > 2. Connection from my remote offices, which goes through a local > leased line, don''t pass successfully. It will hit my 3600, and > die there. I was unable to even ping to 172.16.1.1 from any of > my remote offices. > 3. "service iptables restart" turns up nothing also (iptables -L > shows up allow everything). > 4. Connection from my local LAN however, 192.168.100.0/24 & > 192.168.100.254 works beautifully. > > As I''m currently doing // running, I can still afford to wait. At work > now, beautifully, is 2 Cisco PIX Firewalls. > > Problem 2. Persitent Connection Dies. > > When I tried to SSH to a machine behind the FW (for example, source > address is 192.168.100.99 -> dest address is 202.14.87.35), it works > perfectly. However, during the SSH, should I run certain commands that > will process certain amount of screen data, the SSH session will just > hang there. This will even seem to happen if I SSH from the firewall > itself. > > Again, I tried to to do a service iptables restart, and its exactly > the same. However, a connection from within the same segment will not > have any issue. Everything just work. > > All 3 cards are Intel EtherPro Adaptors. I''m was running Whitebox, and > is now "upgrading" to CentOS to see if it will help. > > I personally do not think that its got anything to do with Shorewall, > but as you guys are used to doing such stuff, posting on this list > might throw up something which might be helpful. Thanks! > > Regards > David > > > > ------------------------------------------------------------------------ > >
David Choo wrote:> My first mail required moderator approval due to its size, so I''ve > uploaded the image to my server. Here is the URL. Cheers! >David -- we also need the information requested in the support guide. Specifically, the output of "shorewall status" as an attachment is essential. -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
David Choo wrote:>> Problem 1. Routing Problems. >> >> At the present moment, none of my site offices can route to any of >> these new IPs. Tests are as follows. >> >> 1. Connection from 3600 Router goes through everywhere beautifully. >> the command "ip route 202.14.87.32 255.255.255.240 172.16.1.1" >> was entered into the router.That certainly sounds like a routing problem -- too bad you didn''t include any routing information.>> 2. Connection from my remote offices, which goes through a local >> leased line, don''t pass successfully. It will hit my 3600, and >> die there. I was unable to even ping to 172.16.1.1 from any of >> my remote offices. >> 3. "service iptables restart" turns up nothing also (iptables -L >> shows up allow everything).You shouldn''t be running either of those commands: a) Rather than "service iptables restart", you should run "shorewall restart". b) Rather than "iptables -L", you should use "shorewall status".>> 4. Connection from my local LAN however, 192.168.100.0/24 & >> 192.168.100.254 works beautifully. >> >> As I''m currently doing // running, I can still afford to wait. At work >> now, beautifully, is 2 Cisco PIX Firewalls.Without seeing how your routing is set up on the boxes involved, I don''t know how you expect us to help you.>> >> Problem 2. Persitent Connection Dies. >> >> When I tried to SSH to a machine behind the FW (for example, source >> address is 192.168.100.99 -> dest address is 202.14.87.35), it works >> perfectly. However, during the SSH, should I run certain commands that >> will process certain amount of screen data, the SSH session will just >> hang there. This will even seem to happen if I SSH from the firewall >> itself.This is not a Shorewall problem -- given that it happens from the firewall itself, I suspect a driver problem or problem with the physical links (especially if you can reproduce the problem after "shorewall clear").>> Again, I tried to to do a service iptables restart, and its exactly >> the same. However, a connection from within the same segment will not >> have any issue. Everything just work.I really think you need to carefully review the article "http://shorewall.net/starting_and_stopping_shorewall.htm". "iptables restart" has absolutely nothing to do with Shorewall -- in fact, once you are using Shorewall the ''iptables'' service should be disabled and never touched again.>> >> All 3 cards are Intel EtherPro Adaptors. I''m was running Whitebox, and >> is now "upgrading" to CentOS to see if it will help. >> >> I personally do not think that its got anything to do with Shorewall, >> but as you guys are used to doing such stuff, posting on this list >> might throw up something which might be helpful. Thanks! >>You need to provide more information if you want my help... -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
Dear Tom, Thanks for the assstance. I''m currently not in office and have no access to the machine. When I''m back, I''ll try it out and see how. Apologise for the inconvenience caused. Tom Eastep wrote:>David Choo wrote: > > > >>>Problem 1. Routing Problems. >>> >>>At the present moment, none of my site offices can route to any of >>>these new IPs. Tests are as follows. >>> >>> 1. Connection from 3600 Router goes through everywhere beautifully. >>> the command "ip route 202.14.87.32 255.255.255.240 172.16.1.1" >>> was entered into the router. >>> >>> > >That certainly sounds like a routing problem -- too bad you didn''t >include any routing information. > > > >>> 2. Connection from my remote offices, which goes through a local >>> leased line, don''t pass successfully. It will hit my 3600, and >>> die there. I was unable to even ping to 172.16.1.1 from any of >>> my remote offices. >>> 3. "service iptables restart" turns up nothing also (iptables -L >>> shows up allow everything). >>> >>> > >You shouldn''t be running either of those commands: > >a) Rather than "service iptables restart", you should run "shorewall >restart". > >b) Rather than "iptables -L", you should use "shorewall status". > > > >>> 4. Connection from my local LAN however, 192.168.100.0/24 & >>> 192.168.100.254 works beautifully. >>> >>>As I''m currently doing // running, I can still afford to wait. At work >>>now, beautifully, is 2 Cisco PIX Firewalls. >>> >>> > >Without seeing how your routing is set up on the boxes involved, I don''t >know how you expect us to help you. > > > >>>Problem 2. Persitent Connection Dies. >>> >>>When I tried to SSH to a machine behind the FW (for example, source >>>address is 192.168.100.99 -> dest address is 202.14.87.35), it works >>>perfectly. However, during the SSH, should I run certain commands that >>>will process certain amount of screen data, the SSH session will just >>>hang there. This will even seem to happen if I SSH from the firewall >>>itself. >>> >>> > >This is not a Shorewall problem -- given that it happens from the >firewall itself, I suspect a driver problem or problem with the physical >links (especially if you can reproduce the problem after "shorewall clear"). > > > >>>Again, I tried to to do a service iptables restart, and its exactly >>>the same. However, a connection from within the same segment will not >>>have any issue. Everything just work. >>> >>> > >I really think you need to carefully review the article >"http://shorewall.net/starting_and_stopping_shorewall.htm". "iptables >restart" has absolutely nothing to do with Shorewall -- in fact, once >you are using Shorewall the ''iptables'' service should be disabled and >never touched again. > > > >>>All 3 cards are Intel EtherPro Adaptors. I''m was running Whitebox, and >>>is now "upgrading" to CentOS to see if it will help. >>> >>>I personally do not think that its got anything to do with Shorewall, >>>but as you guys are used to doing such stuff, posting on this list >>>might throw up something which might be helpful. Thanks! >>> >>> >>> > >You need to provide more information if you want my help... > >-Tom > >
Dear Tom and the good people @ Shorewall, Thanks for your kind help. The error was indeed caused by a hardware error, I changed the NIC card and its now working perfectly. Looks like too many VLANs in 1 adaptor is a big headace also... Tom Eastep wrote:>David Choo wrote: > > > >>>Problem 1. Routing Problems. >>> >>>At the present moment, none of my site offices can route to any of >>>these new IPs. Tests are as follows. >>> >>> 1. Connection from 3600 Router goes through everywhere beautifully. >>> the command "ip route 202.14.87.32 255.255.255.240 172.16.1.1" >>> was entered into the router. >>> >>> > >That certainly sounds like a routing problem -- too bad you didn''t >include any routing information. > > > >>> 2. Connection from my remote offices, which goes through a local >>> leased line, don''t pass successfully. It will hit my 3600, and >>> die there. I was unable to even ping to 172.16.1.1 from any of >>> my remote offices. >>> 3. "service iptables restart" turns up nothing also (iptables -L >>> shows up allow everything). >>> >>> > >You shouldn''t be running either of those commands: > >a) Rather than "service iptables restart", you should run "shorewall >restart". > >b) Rather than "iptables -L", you should use "shorewall status". > > > >>> 4. Connection from my local LAN however, 192.168.100.0/24 & >>> 192.168.100.254 works beautifully. >>> >>>As I''m currently doing // running, I can still afford to wait. At work >>>now, beautifully, is 2 Cisco PIX Firewalls. >>> >>> > >Without seeing how your routing is set up on the boxes involved, I don''t >know how you expect us to help you. > > > >>>Problem 2. Persitent Connection Dies. >>> >>>When I tried to SSH to a machine behind the FW (for example, source >>>address is 192.168.100.99 -> dest address is 202.14.87.35), it works >>>perfectly. However, during the SSH, should I run certain commands that >>>will process certain amount of screen data, the SSH session will just >>>hang there. This will even seem to happen if I SSH from the firewall >>>itself. >>> >>> > >This is not a Shorewall problem -- given that it happens from the >firewall itself, I suspect a driver problem or problem with the physical >links (especially if you can reproduce the problem after "shorewall clear"). > > > >>>Again, I tried to to do a service iptables restart, and its exactly >>>the same. However, a connection from within the same segment will not >>>have any issue. Everything just work. >>> >>> > >I really think you need to carefully review the article >"http://shorewall.net/starting_and_stopping_shorewall.htm". "iptables >restart" has absolutely nothing to do with Shorewall -- in fact, once >you are using Shorewall the ''iptables'' service should be disabled and >never touched again. > > > >>>All 3 cards are Intel EtherPro Adaptors. I''m was running Whitebox, and >>>is now "upgrading" to CentOS to see if it will help. >>> >>>I personally do not think that its got anything to do with Shorewall, >>>but as you guys are used to doing such stuff, posting on this list >>>might throw up something which might be helpful. Thanks! >>> >>> >>> > >You need to provide more information if you want my help... > >-Tom > >