I''m seeing connections broken almost exclusively when connecting with eBay=20 using a browser (Mozilla 1.1). I''ve got a three nic/zone setup, and this affects the inside users going out through the (Shorewall 1.3.7c) firewall. My inside IPs are 192.168.x.x, so=20 they are RFC1918 compliant. Basically, I see the packet comes in on the external interface, but it gets=20 rejected by Shorewall as a badpkt. It''s like it''s forgetting the NAT for=20 packets coming back from the eBay webservers. The end result is that Mozilla=20 dies instantly. Rather annoying. Is there a problem in connection tracking? Is eBay doing some weird load balancing on their end? Can I fix it in Shorewall? Or the kernel? The packet logs look like the following: Sep 7 02:06:18 fw0 kernel: Shorewall:badpkt:DROP:IN=3Deth0 OUT=3Deth1=20 SRC=3D216.33.156.119 DST=3D192.168.1.2 LEN=3D40 TOS=3D0x00 PREC=3D0x00 TTL=3D112 ID=3D35361=20 PROTO=3DTCP SPT=3D80 DPT=3D1797 WINDOW=3D0 RES=3D0x00 ACK URGP=3D0 I know they''re eBay packets because of the source IP and source port. But=20 there''s no way that eBay should "know" about my destination IP, as it should=20 be NATed. How do I sniff this thing? I would think that running tcpdump on the firewall=20 isn''t going to work or will it? I''m thinking I''ll have to get a different=20 machine on the external connection to sniff the traffic to watch for these=20 packets and see what''s really going on, right? Here''s my masq file: eth0 192.168.1.0/24 A.B.C.D # My IP My zones: net Net Internet loc Local Local networks wap WAP Wireless Access Point My policy: loc net ACCEPT loc wap ACCEPT net all DROP info 10/sec:40 all all REJECT info Mike808/ --=20 () Join the ASCII ribbon campaign against HTML email and Microsoft-specific /\ attachments. If I wanted to read HTML, I would have visited your website! Support open standards.
> -----Original Message----- > From: mike808 > Sent: Sunday, September 08, 2002 10:03 PM > To: shorewall-users@shorewall.net > Subject: [Shorewall-users] Weid NAT failures with eBay > > > I''m seeing connections broken almost exclusively when > connecting with eBay using a browser (Mozilla 1.1). > > I''ve got a three nic/zone setup, and this affects the inside > users going out through the (Shorewall 1.3.7c) firewall. My > inside IPs are 192.168.x.x, so they are RFC1918 compliant. > > Basically, I see the packet comes in on the external > interface, but it gets rejected by Shorewall as a badpkt. > It''s like it''s forgetting the NAT for packets coming back > from the eBay webservers. The end result is that Mozilla > dies instantly. Rather annoying. > > Is there a problem in connection tracking? > Is eBay doing some weird load balancing on their end? > Can I fix it in Shorewall? Or the kernel? > > The packet logs look like the following: > Sep 7 02:06:18 fw0 kernel: Shorewall:badpkt:DROP:IN=eth0 OUT=eth1 > SRC=216.33.156.119 DST=192.168.1.2 LEN=40 TOS=0x00 PREC=0x00 > TTL=112 ID=35361 PROTO=TCP SPT=80 DPT=1797 WINDOW=0 RES=0x00 > ACK URGP=0 > > I know they''re eBay packets because of the source IP and source > port. But there''s no way that eBay should "know" about my > destination IP, as it should be NATed. > > How do I sniff this thing? I would think that running tcpdump > on the firewall isn''t going to work or will it? I''m thinking > I''ll have to get a different machine on the external connection > to sniff the traffic to watch for these packets and see what''s > really going on, right? > > Here''s my masq file:<snip> I have a very similar setup to yours at this end and see the same problem being logged when I access eBay (see below). Although I can continue to browse eBay without any problems. Sep 9 06:49:31 firewall kernel: Shorewall:logpkt:LOG:IN=eth0 OUT=eth1 SRC=216.32.120.133 DST=192.168.9.3 LEN=40 TOS=0x00 PREC=0x00 TTL=108 ID=41028 PROTO=TCP SPT=80 DPT=37445 WINDOW=0 RES=0x00 ACK URGP=0 I don''t fully understand why these packets are being logged, but if you have not done so already (you did not include the contents of your interfaces file), I would try setting your external interface to logunclean instead of dropunclean and see if you can''t continue your session with eBay. Example:>From my /etc/shorewall/interface file...net eth0 detect norfc1918,logunclean,routefilter,blacklist loc eth1 detect routestopped dmz eth2 detect routestopped FWIW: I have run ethereal/tcpdump on my firewall to try and find some kind of correlation on why these packets are occurring. So far, the only thing I can spot are these log entries seem to come from specific ip addresses/ranges (like specific ISP''s) and they seem to be packet fragments. In fact, sometimes I can access eBay without generating any logpkt type log entries. Also, I see these types of log entries on some inbound e-mails (specifically the mysql list server) and when some folks access my web server (my site is one of the shorewall mirrors). So these log entries do not seem to be limited to just "outbound" NAT failures from my "loc->net" zone. Since I only see about 30-40 of these log entries a week, I have not been to concerned. YMMV though Good Luck Steve Cowles
>> The packet logs look like the following: >> Sep 7 02:06:18 fw0 kernel: Shorewall:badpkt:DROP:IN=eth0 OUT=eth1 >> SRC=216.33.156.119 DST=192.168.1.2 LEN=40 TOS=0x00 PREC=0x00 >> TTL=112 ID=35361 PROTO=TCP SPT=80 DPT=1797 WINDOW=0 RES=0x00 >> ACK URGP=0 >> >> I know they''re eBay packets because of the source IP and source >> port. But there''s no way that eBay should "know" about my >> destination IP, as it should be NATed. >>FYI - eBay doesn''t know about your internal address. MASQ is done PREROUTING, which means that the addresses are already converted by the time they are logged. tcpdump or ethereal on the external interface should show you the actual packets - and they should be addressed to the masq box. Not that this fixes the problem, but it explains why the DST is the 192.168.1.2 address, not the IP of your shorewall box. It does tell you that the problem is not with MASQ but with something else... The other reply about unclean packets is probably on the right track, eBay must have some setup that causes oddly formatted packets. Hope this helps, ~Jonathan
On Mon, 9 Sep 2002, Jonathan Manning wrote:> > >> The packet logs look like the following: > >> Sep 7 02:06:18 fw0 kernel: Shorewall:badpkt:DROP:IN=eth0 OUT=eth1 > >> SRC=216.33.156.119 DST=192.168.1.2 LEN=40 TOS=0x00 PREC=0x00 > >> TTL=112 ID=35361 PROTO=TCP SPT=80 DPT=1797 WINDOW=0 RES=0x00 > >> ACK URGP=0 > >>This is what one gets for setting ''dropunclean'' on the external interface -- I recommend against it because it results in this sort of problem.> >> I know they''re eBay packets because of the source IP and source > >> port. But there''s no way that eBay should "know" about my > >> destination IP, as it should be NATed. > >> > > FYI - eBay doesn''t know about your internal address. MASQ is done > PREROUTING, which means that the addresses are already converted by the > time they are logged. >Correct-> tcpdump or ethereal on the external interface should show you the actual > packets - and they should be addressed to the masq box. >Ethereal may or may not show the original dest address. I haven''t followed the progress the netfilter group may have made toward making that work correctly -- the first patch had bugs and was withdrawn. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net