I''m running Shorewall 1.3.2 on my firewall (RH 7.3/kernel 2.4.18), and masquerading an internal RFC1918 network. I''m seeing messages like this one fairly regularly: Jun 26 17:54:02 snowbird kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=X SRC=10.1.110.79 DST=10.2.96.10 LEN=58 TOS=0x00 PREC=0x00 TTL=242 ID=18599 DF PROTO=UDP SPT=53 DPT=1123 LEN=38 They usually come in bursts--anywhere from two to 50 or so at a time. The length varies a bit, but everything else is pretty much the same, and there aren''t any obvious timing patterns. I wouldn''t have worried about it, but I noticed that the SRC address is one of my ISP''s nameservers, and the source port is DNS--these look like DNS replies. I checked into it a bit more, and kept an eye on the connection tracking table, and the destination port is one generally used by my internal caching DNS server (running on Windows 2000), so these look like attempted responses to a query from my DNS server. My internal DNS server is generally able to look things up fine, so my firewall isn''t blocking all of these packets, just a few here and there. It''d be nice if I could figure out what''s going on and possibly even fix it. In the 2.2 kernel one could set masquerading timeouts, but that doesn''t appear to be an option with the netfilter code--presumably because it''s ''stateful'' and doesn''t need it. If that''s the case, why is netfilter removing the connection from the connection table before I''ve gotten back all of my replies? Is there anything I can do here, or should I just ignore it and move on? - Bradey
On Wed, 26 Jun 2002, Bradey Honsinger wrote:> > Jun 26 17:54:02 snowbird kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=X > SRC=10.1.110.79 DST=10.2.96.10 LEN=58 TOS=0x00 PREC=0x00 TTL=242 ID=18599 DF > PROTO=UDP SPT=53 DPT=1123 LEN=38 > > ... so these look like attempted responses to a query from my DNS > server. My internal DNS server is generally able to look things up fine, > so my firewall isn''t blocking all of these packets, just a few here and > there. >In the sample configuration ''common'' files and in my own /etc/shorewall/common, I include the following: run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP I recommend that you do the same. That having been said, I would invite you to look at the Netfilter message that you have posted above -- the source IP is an RFC 1918 address!!! So something else (source IP spoofing? NAT failure?) is going on in your case. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
Sorry--I should have said that I edited the log message to remove the MAC address (for brevity) and changed the first two bytes of the IP addresses (out of a misguided sense of security, I guess). The original addresses weren''t RFC1918. In any case, it sounds like I should choose the "just ignore it and move on" option--I''ll add that rule to my common. Thanks for the great product--not to mention the incredible support! - Bradey -----Original Message----- From: Tom Eastep [mailto:teastep@shorewall.net] Sent: Wednesday, June 26, 2002 9:23 PM To: Bradey Honsinger Cc: shorewall-users@shorewall.net Subject: Re: [Shorewall-users] Sporadic blocked DNS replies On Wed, 26 Jun 2002, Bradey Honsinger wrote:> > Jun 26 17:54:02 snowbird kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=X > SRC=10.1.110.79 DST=10.2.96.10 LEN=58 TOS=0x00 PREC=0x00 TTL=242 ID=18599DF> PROTO=UDP SPT=53 DPT=1123 LEN=38 > > ... so these look like attempted responses to a query from my DNS > server. My internal DNS server is generally able to look things up fine, > so my firewall isn''t blocking all of these packets, just a few here and > there. >In the sample configuration ''common'' files and in my own /etc/shorewall/common, I include the following: run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP I recommend that you do the same. That having been said, I would invite you to look at the Netfilter message that you have posted above -- the source IP is an RFC 1918 address!!! So something else (source IP spoofing? NAT failure?) is going on in your case. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net