Date: Fri, 19 Feb 1999 15:06:43 -0600 From: Benjamin Gavin <gavinb@supranet.net> To: Chris Johnson <cjohnson@palomine.net> Cc: freebsd-stable@freebsd.org Subject: Re: Problems with ipfw/nat Message-ID: <4.1.19990219145943.00b8a6f0@mail.supranet.net> In-Reply-To: <19990219111310.A28779@palomine.net> References: <4.1.19990219084638.03665870@mail.supranet.net> <19990219102254.B28285@laissus.fr> <4.1.19990219084638.03665870@mail.supranet.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hey, Well I got a step further. I have traced the problem a little bit further. The firewall is not blocking any of the packets, and I am able to connect to another Apache server on the internal network using natd. However, when I try to connect to an IIS server, I get no such luck. The connection just hangs. I have included the tcpdump output from two runs, the first from the firewall to the web server, and the second from a machine outside the firewall to the web server. You can see the successful negotiation in the first place, and the unsuccessful negotiation in the second part. The IIS server is not responding at all to any requests coming through the firewall. The machine will respond, as I have tracerouted and pinged the internal server using a redirect_address instead of a redirect_port in the natd configuration. However, using redirect_address still doesn't get me access to the IIS server, so not only is it insecure, but it also doesn't work! Anyway, can anyone think of a reason that IIS wouldn't be responding to these packets? Is it something that natd is doing wrong? Thanks, Ben ---------------------------------------------------------------------------- -------------------------------------------------------- 14:37:36.982135 dragon.supranet.int.2640 > intranet.supranet.int.http: S 3278291297:3278291297(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]> (DF) 14:37:36.982811 arp who-has dragon.supranet.int tell rat.supranet.int 14:37:36.982913 arp reply dragon.supranet.int is-at 0:20:af:ba:c3:6e 14:37:36.983244 intranet.supranet.int.http > dragon.supranet.int.2640: S 139254:139254(0) ack 3278291298 win 8760 <mss 1460> (DF) 14:37:36.983367 dragon.supranet.int.2640 > intranet.supranet.int.http: . ack 1 win 17520 (DF) 14:37:36.985537 dragon.supranet.int.2640 > intranet.supranet.int.http: P 1:216(215) ack 1 win 17520 (DF) 14:37:36.990951 intranet.supranet.int.http > dragon.supranet.int.2640: P 1:800(799) ack 216 win 8545 (DF) 14:37:36.991037 intranet.supranet.int.http > dragon.supranet.int.2640: F 800:800(0) ack 216 win 8545 (DF) 14:37:36.991116 dragon.supranet.int.2640 > intranet.supranet.int.http: . ack 801 win 16721 (DF) 14:37:43.017219 dragon.supranet.int.2640 > intranet.supranet.int.http: F 216:216(0) ack 801 win 17520 (DF) 14:37:43.017767 intranet.supranet.int.http > dragon.supranet.int.2640: . ack 217 win 8545 (DF) 14:37:44.071242 dragon.supranet.int.2641 > intranet.supranet.int.http: S 3279726329:3279726329(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]> (DF) 14:37:44.071807 intranet.supranet.int.http > dragon.supranet.int.2641: S 139255:139255(0) ack 3279726330 win 8760 <mss 1460> (DF) 14:37:44.071956 dragon.supranet.int.2641 > intranet.supranet.int.http: . ack 1 win 17520 (DF) 14:37:55.402929 dragon.supranet.int.2641 > intranet.supranet.int.http: P 1:259(258) ack 1 win 17520 (DF) 14:37:55.412056 intranet.supranet.int.http > dragon.supranet.int.2641: P 1:200(199) ack 259 win 8502 (DF) 14:37:55.557251 dragon.supranet.int.2641 > intranet.supranet.int.http: . ack 200 win 17520 (DF) 14:37:55.558992 intranet.supranet.int.http > dragon.supranet.int.2641: P 200:901(701) ack 259 win 8502 (DF) 14:37:55.560051 intranet.supranet.int.http > dragon.supranet.int.2641: FP 901:1127(226) ack 259 win 8502 (DF) 14:37:55.560121 dragon.supranet.int.2641 > intranet.supranet.int.http: . ack 1128 win 16593 (DF) 14:37:58.338062 dragon.supranet.int.2641 > intranet.supranet.int.http: F 259:259(0) ack 1128 win 17520 (DF) 14:37:58.338621 intranet.supranet.int.http > dragon.supranet.int.2641: . ack 260 win 8502 (DF) ------------------------------------------------ 14:38:06.434520 ram.supranet.net.ies-lm > intranet.supranet.int.http: S 1368692374:1368692374(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]> (DF) 14:38:09.370220 ram.supranet.net.ies-lm > intranet.supranet.int.http: S 1368692374:1368692374(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]> (DF) 14:38:15.371182 ram.supranet.net.ies-lm > intranet.supranet.int.http: S 1368692374:1368692374(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]> (DF) 14:38:27.372069 ram.supranet.net.ies-lm > intranet.supranet.int.http: S 1368692374:1368692374(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]> (DF) 14:38:51.374253 ram.supranet.net.ies-lm > intranet.supranet.int.http: S 1368692374:1368692374(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]> (DF) At 11:13 AM 2/19/99 -0500, Chris Johnson wrote: >On Fri, Feb 19, 1999 at 08:53:26AM -0600, Benjamin Gavin wrote: >> Hi all, >> After much messing around, I am still unable to get this stuff to work. >> I just wanted to clear up one thing before I continue. In /etc/rc.conf you >> can specify a filename where your local firewall rules are located. (i.e. >> firewall_type="/etc/rc.firewall.local"). If you do it this way, ipfw will >> be called like "ipfw /etc/rc.firewall.local". This will run through the >> file and perform whatever commands you have listed there. I do it this way >> so as I don't have to directly modify /etc/rc.firewall. I believe this is >> a perfectly standard way to do it. Please correct me if I am wrong. >> >> Anyway, onto my real problem. I have been able to set up the firewall to >> allow access to internal POP3, and SMTP servers, but am still unable to get >> an answer from internal HTTP servers. Just going in and changing the >> relevant rules (i.e. changing port 25 to port 80) just doesn't work. Is >> there something intrinsicly different about the HTTP protocal that does not >> allow if to function correctly from the inside of a firewall?? Is it >> trying to reply on a different port or something? I mean that I can't even >> telnet through on port 80 and get a prompt. It just hangs there. However, >> like I said I can get through to SMTP and POP3 servers fine, _USING THE >> SAME MACHINE AND FIREWALL_!!! > >Ben, > >I don't have an answer to your question, but I can tell you that there's >nothing different about HTTP protocol-wise. It should work exactly like POP3 or >SMTP. You'd have problems with FTP, but not HTTP. > >Is it possible that this is a DNS problem? Do you have your httpd daemon set to >do reverse lookups on the addresses that are connecting to it, and is there >something broken DNS-wise over there? If this were the case, you would see >substantial delays while the DNS lookup times out, but if you wait long enough >(like maybe a minute) the connection should go through. > >HTTP really should (as you suspected) work exactly like SMTP, and it should be >enough to change 25 to 80 in your rules. > >Chris > >> >> Needless to say, I am mucho confused... Please does anyone out there >> have any ideas at all??? >> >> Thanks, >> Ben >> >> At 10:22 AM 2/19/99 +0100, Francois LAISSUS wrote: >> >Hi, >> >I'm trying to understand your question from your configuration : >> > >> >>_rc.conf.site_: >> >>gateway_enable="YES" >> >>firewall_enable="YES" >> >>firewall_type="/etc/rc.firewall.local" # Contains my local firewall rules >> > ^^^^^^^^^^^^^^^^^^^^^^ >> >It seems to me that here you should write the *name* of type >> >of rules finds in /etc/rc.firewall, not the file name. >> >It runs fine for me under 2.2.xx >> > >> >Hope that helps >> > >> >F.Laissus >> > >> >-- >> >____ Francois Laissus <Francois.Laissus@laissus.fr> >_________________________ >> >____ Cabinet d'Etudes Informatiques - Paris - France ____________________ >> >____ Tel 33 (0)1.43.31.54.75 - Fax 33 (0)1.43.31.54.85 _______________ >> >> /--------------------------------------------------------------------------/ >> Benjamin Gavin - Senior Consultant >> >> *********** NO SPAM!! ************ >> >> >> To Unsubscribe: send mail to majordomo@FreeBSD.org >> with "unsubscribe freebsd-stable" in the body of the message /--------------------------------------------------------------------------/ Benjamin Gavin - Senior Consultant *********** NO SPAM!! ************ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.1.19990219145943.00b8a6f0>