Gregory K. Ruiz-Ade
2003-Aug-19 19:29 UTC
[Shorewall-users] FTP problem with specific host?
Well, I''ve gotten the firewall up and running in production, but we''ve noticed that, for whatever reason, our client PC''s behind the firewall can''t access ftp.ucsd.edu anymore. Others I know who are also running shorewall don''t seem to have this problem. Also, ftp.ucsd.edu seems to be the only host we''ve found so far that we can''t get a connection to. Other ftp servers we use still work, so I know that shorewall''s thing is working. In the rules file, I have: ACCEPT l_pcs ext tcp ftp l_pcs being the zone defined for PC''s on the internal network, ext being the zone defined for the internet & external hosts. l_pcs is masqueraded to the internet (set up in masq file): eth4:!10.0.0.0/8 eth0 eth4 is the external interface, eth0 the lan interface. the !10.0.0.0/8 is there to make sure VPN traffic doesn''t get masqueraded. Given that, where do I look for the problem? Ident is rejected in the common chain, similar to a friend''s configuration that works. I can post tcpdump info if asked. TIA, Gregory -- Gregory K. Ruiz-Ade <gkade@bigbrother.net> OpenPGP Key ID: EAF4844B keyserver: pgpkeys.mit.edu
On Tue, 19 Aug 2003, Gregory K. Ruiz-Ade wrote:> > eth4 is the external interface, eth0 the lan interface. the !10.0.0.0/8 > is there to make sure VPN traffic doesn''t get masqueraded. >If you have unencapsulated VPN traffic going out of eth4, you have much worse problems than masquerading.> Given that, where do I look for the problem? Ident is rejected in the > common chain, similar to a friend''s configuration that works. >You have of course looked at FAQ 29 (FTP doesn''t work)? -Tom Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Gregory K. Ruiz-Ade
2003-Aug-20 14:28 UTC
[Shorewall-users] FTP problem with specific host?
On Tuesday 19 August 2003 07:46 pm, Tom Eastep wrote:> On Tue, 19 Aug 2003, Gregory K. Ruiz-Ade wrote: > > eth4 is the external interface, eth0 the lan interface. the > > !10.0.0.0/8 is there to make sure VPN traffic doesn''t get > > masqueraded. > > If you have unencapsulated VPN traffic going out of eth4, you have > much worse problems than masquerading.No, it''s all encapsulated. The negated address was "strongly suggested" by the FreeS/WAN people/docs, so I tacked that on there for the masquerading stuff. I''ve verified the chains that Shorewall creates & the routing that''s set up (and double-checked it with tcpdump outside the firewall), so that''s all well and good. Thanks for the reminder, though. :)> > Given that, where do I look for the problem? Ident is rejected in > > the common chain, similar to a friend''s configuration that works. > > You have of course looked at FAQ 29 (FTP doesn''t work)?Yeah, I read that last night before I sent the email, and almost had a "eureka" moment with the last couple paragraphs, when I realized that they were talking about incoming FTP from the Internet to DMZ hosts, which isn''t our case. I''ve tested everything I can think of, and it seems to be some oddity with ftp.ucsd.edu alone. Every other FTP host we commonly use (banks, clients, mirrors we commonly grab things from) works as it should. I did a tcpdump, and without doing the research to see what everything means (output from "tcpdump -i eth4 -ql host ftp.ucsd.edu"), the initial connect request is acknowledged (I get a "Connected to ftp.ucsd.edu" message from my client), but then four tcp/auth requests come from the server (which the firewall rejects via the "reject" chain, triggered from the "common" chain), then nothing for a few seconds, and then the FTP client terminates the connection due to a timeout. No user/login prompt ever comes up. My manager happens to be friends with one of the networking chiefs at UCSD, and will ask him tonight if there''s anything special happening on that ftp server. Perhaps I''ll have to set up a fakeident server & allow idents through instead of rejecting them. Gregory -- Gregory K. Ruiz-Ade <gkade@bigbrother.net> OpenPGP Key ID: EAF4844B keyserver: pgpkeys.mit.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://lists.shorewall.net/pipermail/shorewall-users/attachments/20030820/45ce60c4/attachment.bin
On Wed, 2003-08-20 at 14:27, Gregory K. Ruiz-Ade wrote:> I did a tcpdump, and without doing the research to see what everything > means (output from "tcpdump -i eth4 -ql host ftp.ucsd.edu"), the > initial connect request is acknowledged (I get a "Connected to > ftp.ucsd.edu" message from my client), but then four tcp/auth requests > come from the server (which the firewall rejects via the "reject" > chain, triggered from the "common" chain), then nothing for a few > seconds, and then the FTP client terminates the connection due to a > timeout. No user/login prompt ever comes up. >What distro and kernel are you running? -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Gregory K. Ruiz-Ade
2003-Aug-20 16:44 UTC
[Shorewall-users] FTP problem with specific host?
On Wednesday 20 August 2003 02:44 pm, Tom Eastep wrote:> On Wed, 2003-08-20 at 14:27, Gregory K. Ruiz-Ade wrote: > > I did a tcpdump, and without doing the research to see what > > everything means (output from "tcpdump -i eth4 -ql host > > ftp.ucsd.edu"), the initial connect request is acknowledged (I get > > a "Connected to ftp.ucsd.edu" message from my client), but then > > four tcp/auth requests come from the server (which the firewall > > rejects via the "reject" chain, triggered from the "common" chain), > > then nothing for a few seconds, and then the FTP client terminates > > the connection due to a timeout. No user/login prompt ever comes > > up. > > What distro and kernel are you running?Red Hat 9, kernel-2.4.20-18.9 RPM, shorewall-1.4.5-1 RPM (downloaded from shorewall site). -- Gregory K. Ruiz-Ade <gkade@bigbrother.net> OpenPGP Key ID: EAF4844B keyserver: pgpkeys.mit.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://lists.shorewall.net/pipermail/shorewall-users/attachments/20030820/0b80d0c9/attachment.bin
On Wed, 2003-08-20 at 16:43, Gregory K. Ruiz-Ade wrote:> > > > What distro and kernel are you running? > > Red Hat 9, kernel-2.4.20-18.9 RPM, shorewall-1.4.5-1 RPM (downloaded > from shorewall site).All current RedHat 9 kernels are buggy -- they treat "REJECT --reject-with tcp-reset" the same as "DROP". Attached is a patch. It''s also on RH Bugzilla as yours truly sent it to RH weeks ago... -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net -------------- next part -------------- --- linux-2.4.20-18.9/net/ipv4/netfilter/ipt_REJECT.c.save 2003-06-11 13:06:23.000000000 -0700 +++ linux-2.4.20-18.9/net/ipv4/netfilter/ipt_REJECT.c 2003-06-11 17:56:15.000000000 -0700 @@ -65,15 +65,14 @@ return; /* Routing: if not headed for us, route won''t like source */ - if (ip_route_output(&rt, oldskb->nh.iph->daddr, - local ? oldskb->nh.iph->saddr : 0, + if (ip_route_output(&rt, oldskb->nh.iph->saddr, + local ? oldskb->nh.iph->daddr : 0, RT_TOS(oldskb->nh.iph->tos) | RTO_CONN, 0) != 0) return; hh_len = (rt->u.dst.dev->hard_header_len + 15)&~15; - /* Copy skb (even if skb is about to be dropped, we can''t just clone it because there may be other things, such as tcpdump, interested in it). We also need to expand headroom in case
On Wed, 2003-08-20 at 17:20, Tom Eastep wrote:> > All current RedHat 9 kernels are buggy -- they treat "REJECT > --reject-with tcp-reset" the same as "DROP". > > Attached is a patch. It''s also on RH Bugzilla as yours truly sent it to > RH weeks ago...The bug is also fixed in kernel 2.4.21 which I run here. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Wed, 2003-08-20 at 17:20, Tom Eastep wrote:> On Wed, 2003-08-20 at 16:43, Gregory K. Ruiz-Ade wrote: >> > All current RedHat 9 kernels are buggy -- they treat "REJECT > --reject-with tcp-reset" the same as "DROP". > > Attached is a patch. It''s also on RH Bugzilla as yours truly sent it to > RH weeks ago... >As a work-around, add this rule and don''t run an ident daemon on your firewall. ACCEPT net fw tcp 113 -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net