Hi all! I have set up an extra Shorewall box to service a new T1 at a customer. This box has three interfaces connecting to Internet, DMZ and the local LAN. The clients at the local LAN have problems accessing the servers in the new DMZ. I''m looking at cables, nic''s and switches, but I want to make sure I haven''t missed anything in the Shorewall setup. Here''s som info on the setup: FW1 is a RedHat8 with Shorewall 1.3.11a. It has the following interfaces: eth0 210.207.40.2/24 connected to the ISP''s router at 210.207.40.1/24. The interface has the proxyarp option set. eth1 210.207.40.3/25 with the proxyarp option. eth2 210.207.40.129/25 with the proxyarp option. eth3 192.168.1.1/24 no proxyarp option. There is a static route that points to the ISP router through eth0 (Thanks Tom!!) The clients are on the 192.168.1.0-network, with 192.168.1.1 as default gateway. This setup has worked like a charm for many months now, and everything is dandy. Now we have a second ISP router where I''ve set up a new Redhat9 with Shorewall 1.4.6a: eth0 213.200.98.124/29 connected to the router at 213.200.98.121/29. eth1 192.168.1.250/24 connected to the LAN switch. eth2 10.0.0.1/24 connected to a DMZ switch. We have some servers connected to the DMZ switch, with 10.0.0.x-addresses, with 10.0.0.1 as default gw. We have a block of addresses in the 213.115.211.0-network, and I''ve set up mappings in the nat file to do static nat on the outside interface. Accessing the servers from the outside works great, everything I set up in the rules file works just as expected - no probs. To let the clients on the LAN, with 192.168.1.1 as their gateway, access the servers at 10.0.0.x, I''ve set up a static route in the first FW that points to 192.168.1.250 through eth3. On the second fw I''ve set up a static route to the 210-network that points to 192.168.1.1 through eth1. So as you see, both firewalls have an interface connected to the local LAN. When a client pings a server on the new DMZ (10.0.0.x), there is no problem at all, but when we try http or smtp it works only some of the time!! I''m wondering if I need something in the hosts files to specify that there are other ''zones'' behind, for example, eth3 of the first firewall, ie that the 10.0.0.0-network is behind fw nr 2?? As that network isn''t directly connected, I thought the route entries would suffice. Sorry if the question is stupid, or if I''ve forgotten a thousand pieces of information, but my brains are fried right now... Oh, and the policies are ok - I''ve allowed access between the LAN and the DMZ and vice versa. Any input regarding this setup is greatly appreciated! TIA, ?rjan
On Sun, 17 Aug 2003, ?rjan Johansson wrote:> So as you see, both firewalls have an interface connected to the local > LAN. When a client pings a server on the new DMZ (10.0.0.x), there is no > problem at all, but when we try http or smtp it works only some of the > time!! I''m wondering if I need something in the hosts files to specify > that there are other ''zones'' behind, for example, eth3 of the first > firewall, ie that the 10.0.0.0-network is behind fw nr 2?? As that > network isn''t directly connected, I thought the route entries would > suffice.My first input is regarding your mailer -- PLEASE configure it to fold lines at column 76 or so and to post to this list in plain text. As it is now, each paragraph above is one long line which makes it so hard to read that I considered not responding at all. Luckily Pine has a nice facility for folding such long lines in a response. In general, your Shorewall configuration either works or it doesn''t -- there is no "Works sometime but not all of the time" possible with iptables rules. The only thing that I can think of is to be sure that NEWNOTSYN=Yes on the old firewall since that firewall will only be seeing half of the traffic between local clients and the new DMZ. Beyond that, Ethereal/tcpdump are your friends... -Tom Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
> -----Original Message----- > From: Tom Eastep [mailto:teastep@shorewall.net]> The only thing that I can think of is to be sure that > NEWNOTSYN=Yes on the > old firewall since that firewall will only be seeing half of > the traffic > between local clients and the new DMZ. Beyond that, > Ethereal/tcpdump are > your friends...Unfortunately NEWNOTSYN=Yes didn''t solve it. I''m going back tomorrow to do some tcpdumping. However, I do have two general questions: The ''routeback'' option isn''t in the first firewall (running Shorewall 1.3.11a). Is there another way to accomplish that? What I''m getting at is that local clients go to the first fw''s eth3 which is their gateway, and the route to the 10.0.0.0 network is back out that interface to the new fw. Could that be an issue for me? How does Linux handle icmp redirect? Sorry if it''s off topic, but I''ve started thinking that the first fw should probably send redirects to the local clients telling them that the 10.0.0.0 network is at the new firewall? Should I set up rules for this or am I way off here? As I said I''ll have a better picture tomorrow when I''ve captured some traffic, but since I think about this 24/7 I thought I''d throw these questions out there. Any input appreciated! Tia, ?rjan
On Mon, 2003-08-18 at 09:14, ?rjan Johansson wrote:> > -----Original Message----- > > From: Tom Eastep [mailto:teastep@shorewall.net] > > > The only thing that I can think of is to be sure that > > NEWNOTSYN=Yes on the > > old firewall since that firewall will only be seeing half of > > the traffic > > between local clients and the new DMZ. Beyond that, > > Ethereal/tcpdump are > > your friends... > > Unfortunately NEWNOTSYN=Yes didn''t solve it. I''m going back tomorrow to do > some tcpdumping. However, I do have two general questions: > > The ''routeback'' option isn''t in the first firewall (running Shorewall > 1.3.11a). Is there another way to accomplish that? What I''m getting at is > that local clients go to the first fw''s eth3 which is their gateway, and > the route to the 10.0.0.0 network is back out that interface to the new fw. > Could that be an issue for me?\Possibly -- IIRC you are running some ancient 1.3 version on that firewall and I don''t remember off-hand what is required. If you''re not getting Shorewall messages logged when you try to access the DMZ then you don''t need to do anything more; if you are getting messages, you should have told us that in your initial post. A "loc loc ACCEPT" policy should be sufficient for most of the later 1.3 versions.> > How does Linux handle icmp redirect? Sorry if it''s off topic, but I''ve > started thinking that the first fw should probably send redirects to the > local clients telling them that the 10.0.0.0 network is at the new > firewall? Should I set up rules for this or am I way off here?Shorewall doesn''t have anything to do with icmp redirect; you control that directly through /proc/sys/net/ipv4/conf/*. If you add the above policy, I don''t think you need any rules but again,"shorewall show log" is your friend. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Mon, 2003-08-18 at 09:22, Tom Eastep wrote:> > > > The ''routeback'' option isn''t in the first firewall (running Shorewall > > 1.3.11a). Is there another way to accomplish that?> Possibly -- IIRC you are running some ancient 1.3 version on that > firewallSorry -- I missed the fact that you mentioned the version (1.3.11a). Again, I think that a "loc loc ACCEPT" policy should be sufficient for that version. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
> -----Original Message----- > From: Tom Eastep [mailto:teastep@shorewall.net]> Sorry -- I missed the fact that you mentioned the version (1.3.11a). > Again, I think that a "loc loc ACCEPT" policy should be sufficient for > that version. >Thanks. Yes, I realize that there''s a lack of log information. I haven''t been able to be on site since friday, so there''s been a lot of just beating my brains and asking them to try certain things. It''s the first installation I''ve done of this complexity, and all sorts of ideas pop up. I''ll be back there tomorrow though to dig in again. However, I can''t overstate how cool Shorewall is because it actually encourages you to delve in to more intricate matters (being an old MS-guy), and the learning curve is amazing! :-) Thanks for the tip on /proc/sys/net/ipv4/config - yet another new piece of knowledge! I''ll get back with reports on my progress. Thanks again, ?rjan
> -----Original Message----- > From: Tom Eastep [mailto:teastep@shorewall.net] > Sorry -- I missed the fact that you mentioned the version (1.3.11a). > Again, I think that a "loc loc ACCEPT" policy should be sufficient for > that version.Thanks Tom!! You were right as always. The ''loc loc ACCEPT'' rule, combined with NEWNOTSYN=Yes seems to have done the trick, and my client tells me it''s working beautifully now. Can I FedEx you a sixpack of ice cold Sierra Nevada? :-) Cheers, ?rjan
On Tue, 2003-08-19 at 07:33, ?rjan Johansson wrote:> > You were right as always. The ''loc loc ACCEPT'' rule, combined with > NEWNOTSYN=Yes seems to have done the trick, and my client tells me it''s > working beautifully now.Great.> Can I FedEx you a sixpack of ice cold Sierra Nevada? :-)Not necessary at all; and as you can see by my pix on the web site, I *really* don''t need any more calories :-) -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net