Andreï V. FOMITCHEV
2004-May-03 09:40 UTC
Re: Tr: Re: Shorewall and net2dmz communications
Hi, I am sorry to have been so short but the problem was a surprise: I try to configure a new firewall, when I was using the kernel 2.4.24, I did not have this problem of net2dmz communication, I replaced a version 2.4.24 of the Linux kernel by version 2.4.26 and the problem appeared brutally. a.v.fomitchev@netcourrier.com wrote:>>Date: Fri, 30 Apr 2004 11:31:52 -0700 >>De: Tom Eastep <teastep@shorewall.net> >>A: Mailing List for Shorewall Users <shorewall-users@lists.shorewall.net> >>Copie à: a.v.fomitchev@netcourrier.com >>Sujet: Re: [Shorewall-users] Shorewall and net2dmz communications >> >>Tom Eastep wrote: >> >> >>>Tom Eastep wrote: >>> >>> >>>>Tom Eastep wrote: >>>> >>>> >>>>>a.v.fomitchev@netcourrier.com wrote: >>>>> >>>>> >>>>>>Hi, >>>>>>I have a firewall: local net, DMZ (a http server and a mail server) >>>>>>and Internet. OS of this firewall is Debian Woody. I installed >>>>>>kernel 2.4.26 (patchs: grsecurity-2.0-2.4.26 and >>>>>>patch-o-matic-ng-20040302), iptables-1.2.9 and shorewall 2.0.1. >>>>>>I have a big problem: my dmz cannot communicate to Net and my dmz is >>>>>>not accessible from the Net (I do not have a problem of >>>>>>communication loc2net, loc2dmz and dmz2loc), example: ping from http >>>>>>server to www.google.fr: >>>>>>www:~# ping www.google.fr >>>>>>PING www.google.akadns.net (216.239.59.99): 56 data bytes >>>>>>(nothing) >>>>>>But, >>>>>>gate# tcpdump -i eth2 host 192.168.0.4 >>>>>>tcpdump: listening on eth2 >>>>>>17:49:57.506610 192.168.0.4 > 66.102.9.104: icmp: echo request >>>>>>17:49:58.506688 192.168.0.4 > 66.102.9.104: icmp: echo request >>>>>>17:49:59.506707 192.168.0.4 > 66.102.9.104: icmp: echo request >>>>>>(...) >>>>>>gate# tcpdump -i eth0 host aaa.bbb.ccc.163 >>>>>>tcpdump: listening on eth0 >>>>>>17:49:59.506747 aaa.bbb.ccc.163 > 66.102.9.104: icmp: echo request >>>>>>17:49:59.580811 66.102.9.104 > aaa.bbb.ccc.163: icmp: echo reply >>>>>>17:50:00.506781 aaa.bbb.ccc.163 > 66.102.9.104: icmp: echo request >>>>>>17:50:00.589703 66.102.9.104 > aaa.bbb.ccc.163: icmp: echo reply >>>>>>(...) >>>>>> >>>>>>In which part of shorewall do have I to seek the source of the problem? >>>>>> >>>>>> >>>>>> >>>>>You say that you have a dmz problem then you show us some tcpdump >>>>>output. >>>>>I thought that the results of the ping illustrate my problem: the ping query arrives on the firewall by the interface eth2 and its address is changed (correctly), then the query is sent on the Net by interface eth0; Then, the interface eth0 receives the answer but nothing... In the same way: the ping and other requests towards the http server do not succeed (they arrive until eth0 and nothing afterwards) However I have in the file ''rules'': (...) # ping ACCEPT net fw icmp 8 ACCEPT net dmz icmp 8 (...) # queries ACCEPT net dmz:192.168.0.4 tcp 80,20,21,443 (...) Ask me other information that you need because I do not know the source of the problem>>>>>So: >>>>> >>>>>a) Which interface goes to the internet? >>>>>b) Which interface goes to the dmz? >>>>>c) Which zone is 192.168.0.4 in (the dmz?)? >>>>> >>>>>I will *guess* that: >>>>> >>>>>1. eth0 goes to the internet. >>>>> >>>>>Exact>>>>>2. eth2 goes to the DMZ. >>>>> >>>>>Exact>>>>>3. 192.168.0.4 is in the DMZ. >>>>> >>>>>Yes, 192.168.0.4 is an http server>>>>>So what does a tcpdump on eth0 look like when 192.168.0.4 is pinging >>>>>66.102.9.104? >>>>> >>>>> >>>> >>>>Or is that what you showed us???? >>>> >>>> >>>If it *is* what you showed us, then can 192.168.0.4 ping the firewall? >>> >>> >>> >>Also, did the IP address 217.167.143.163 used to belong to another >>system (or at least another NIC)? If so, the upstream router may have a >>stale ARP cache as described in the One-to-one NAT and Proxy ARP >>documentation. Using the ''-e'' option on tcpdump when looking at eth0 >>will show if this is the case. >> >>I was obliged to replace the new firewall which has the problem by the old and before starting again, I need to know where to seek the source of the problem -- Andreï V. FOMITCHEV [Quand faut-il arrêter l''informatique] Software R&D Engineer [Lorsque, dans un kilo, on trouve 1024 grammes] Odixion SAS, FRANCE
Andreï V. FOMITCHEV wrote:> > I was obliged to replace the new firewall which has the problem by the > old and before starting again, I need to know where to seek the source > of the problem >So is this a new system that uses the same IP addresses as the old system? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Andreï V. FOMITCHEV
2004-May-04 08:36 UTC
Re: Tr: Re: Shorewall and net2dmz communications
Tom Eastep wrote:> Andreï V. FOMITCHEV wrote: > >> I was obliged to replace the new firewall which has the problem by >> the old and before starting again, I need to know where to seek the >> source of the problem > > So is this a new system that uses the same IP addresses as the old > system?yes, of course: the replacement of the firewall must be transparent for the users... I do not think that the problem is related to the addresses, during my first tests, I used the kernel 2.4.24, iptables-1.2.9 and shorewall-1.2.12 (woody stable) and the DMZ functioned correctly. I upgraded a kernel (2.4.26) and my DMZ cannot communicate with the Internet (communications from loc to fw, to DMZ and to Internet, from DMZ to fw and to loc, and from fw to Internet do not present a problem). After I noted the problem, I updated shorewall to 2.0.1, suspecting a problem of incompatibility but the problem is always there. In theory, the modules of the kernel 2.4.26 are the same ones as those of the 2.4.24 but perhaps, I forgot some...> -TomI am open to all ideas allowing me to locate the problem. Best regards, -- Andreï V. FOMITCHEV [Quand faut-il arrêter l''informatique] Software R&D Engineer [Lorsque, dans un kilo, on trouve 1024 grammes] Odixion SAS, FRANCE
Andreï V. FOMITCHEV wrote:> Tom Eastep wrote: > >> Andreï V. FOMITCHEV wrote: >> >>> I was obliged to replace the new firewall which has the problem by >>> the old and before starting again, I need to know where to seek the >>> source of the problem >> >> >> So is this a new system that uses the same IP addresses as the old >> system? > > > yes, of course: the replacement of the firewall must be transparent for > the users...So are you flushing the ARP cache of upstream router when you switch the boxes? If not, you can see *exact* symptoms that you have reported.> I do not think that the problem is related to the addresses, during my > first tests, I used the kernel 2.4.24, iptables-1.2.9 and > shorewall-1.2.12 (woody stable) and the DMZ functioned correctly. I > upgraded a kernel (2.4.26) and my DMZ cannot communicate with the > Internet (communications from loc to fw, to DMZ and to Internet, from > DMZ to fw and to loc, and from fw to Internet do not present a problem). > After I noted the problem, I updated shorewall to 2.0.1, suspecting a > problem of incompatibility but the problem is always there.Next time you swap in the new box, flush the ARP cache of the upstream router or use gratuitous ARP as described in the Shorewall one-to-one NAT and Proxy ARP documentation. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Andreï V. FOMITCHEV
2004-May-06 09:41 UTC
Re: Tr: Re: Shorewall and net2dmz communications
I read again the guide and other documentations available on the site and I decided to use Proxy-ARP instead of One-to-one NAT. My goal is a creation of a ''clean'' and protected DMZ containing a mail server and a HTTP server. Currently, HTTP server has two interfaces network (public and private), mail server has a private address and the current firewall use a NAT Then, if somebody can assure me that I am on good way, I thank it by advance: 1) How to guarantee the transparency of the servers in the dmz for the local users who use the old private addresses? I added the following rules in ''rules'' file: # transparency for mail server DNAT loc dmz:aaa.bbb.ccc.165 all - - 192.168.123.2 #transparency for http server DNAT loc dmz:aaa.bbb.ccc.163 all - - 192.168.123.4 I have a doubt: are these rules sufficient so that my servers of the DMZ, which has public addresses now, are accessible from the local network by their old addresses? Or must I add rules in the ''nat'' file? Tom Eastep wrote:> Andreï V. FOMITCHEV wrote: > >> (...) > > Next time you swap in the new box, flush the ARP cache of the upstream > router or use gratuitous ARP as described in the Shorewall one-to-one > NAT and Proxy ARP documentation.OK, I envisage the tests for Friday and I will flush ARP cache of router(I do not understand why first tests functioned). Thank you for your assistance. Best regards, -- Andreï V. FOMITCHEV [Quand faut-il arrêter l''informatique] Software R&D Engineer [Lorsque, dans un kilo, on trouve 1024 grammes] Odixion SAS, FRANCE