Hi all: I''m running a public ntp server (member of the ntp.org pool) behind my Shorewall box. The ntp server is up and running and I see on my status page on ntp.org that all is well with my ntp server. However a few hosts are filling my firewall logs with packets that looks to be ntp packets. Proto=udp and dpt=123. But shorewall is dropping these packets but allowing regular ntp since I have a rule allowing ntp (DNAT to an internal machine). The log entries looks like this: #################### Jul 2 09:01:04 munin Shorewall:net2fw:DROP: IN=eth0 OUT= MAC=48:5b:39:ac:1b:5e: 00:12:da:a4:14:bf:08:00 SRC=62.92.61.52 DST=x.x.x.x LEN=76 TOS=00 PREC=0x00 TTL=53 ID=30170 PROTO=UDP SPT=455 DPT=123 LEN=56 MARK=0 Jul 2 09:01:07 munin Shorewall:net2fw:DROP: IN=eth0 OUT= MAC=48:5b:39:ac:1b:5e: 00:12:da:a4:14:bf:08:00 SRC=62.92.61.52 DST=x.x.x.x LEN=76 TOS=00 PREC=0x00 TTL=53 ID=30171 PROTO=UDP SPT=455 DPT=123 LEN=56 MARK=0 Jul 2 09:01:09 munin Shorewall:net2fw:DROP: IN=eth0 OUT= MAC=48:5b:39:ac:1b:5e: 00:12:da:a4:14:bf:08:00 SRC=62.92.61.52 DST=x.x.x.x LEN=76 TOS=00 PREC=0x00 TTL=53 ID=30172 PROTO=UDP SPT=455 DPT=123 LEN=56 MARK=0 Jul 2 09:01:12 munin Shorewall:net2fw:DROP: IN=eth0 OUT= MAC=48:5b:39:ac:1b:5e: 00:12:da:a4:14:bf:08:00 SRC=62.92.61.52 DST=x.x.x.x LEN=76 TOS=00 PREC=0x00 TTL=53 ID=30173 PROTO=UDP SPT=455 DPT=123 LEN=56 MARK=0 Jul 2 09:01:13 munin Shorewall:net2fw:DROP: IN=eth0 OUT= MAC=48:5b:39:ac:1b:5e: 00:12:da:a4:14:bf:08:00 SRC=62.92.61.52 DST=x.x.x.x LEN=76 TOS=00 PREC=0x00 TTL=53 ID=30174 PROTO=UDP SPT=455 DPT=123 LEN=56 MARK=0 #################### I removed DST IP since that is not relevant. I hope that somebody on this list can explain what''s going on. Currently I''m dropping all traffic from this IP to prevent it from cluttering my log even more. Thanks - Øyvind ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev
> Hi all: > > I''m running a public ntp server (member of the ntp.org pool) behind my > Shorewall box. > > The ntp server is up and running and I see on my status page on ntp.org > that all is well with my ntp server. > > However a few hosts are filling my firewall logs with packets that looks > to be ntp packets. > > Proto=udp and dpt=123. > > But shorewall is dropping these packets but allowing regular ntp since I > have a rule allowing ntp (DNAT to an internal machine).But why are they dropped? Because of SPT != 123? Simon> > The log entries looks like this: > > #################### > > Jul 2 09:01:04 munin Shorewall:net2fw:DROP: IN=eth0 OUT> MAC=48:5b:39:ac:1b:5e: > 00:12:da:a4:14:bf:08:00 SRC=62.92.61.52 DST=x.x.x.x LEN=76 TOS=00 > PREC=0x00 > TTL=53 ID=30170 PROTO=UDP SPT=455 DPT=123 LEN=56 MARK=0 > Jul 2 09:01:07 munin Shorewall:net2fw:DROP: IN=eth0 OUT> MAC=48:5b:39:ac:1b:5e: > 00:12:da:a4:14:bf:08:00 SRC=62.92.61.52 DST=x.x.x.x LEN=76 TOS=00 > PREC=0x00 > TTL=53 ID=30171 PROTO=UDP SPT=455 DPT=123 LEN=56 MARK=0 > Jul 2 09:01:09 munin Shorewall:net2fw:DROP: IN=eth0 OUT> MAC=48:5b:39:ac:1b:5e: > 00:12:da:a4:14:bf:08:00 SRC=62.92.61.52 DST=x.x.x.x LEN=76 TOS=00 > PREC=0x00 > TTL=53 ID=30172 PROTO=UDP SPT=455 DPT=123 LEN=56 MARK=0 > Jul 2 09:01:12 munin Shorewall:net2fw:DROP: IN=eth0 OUT> MAC=48:5b:39:ac:1b:5e: > 00:12:da:a4:14:bf:08:00 SRC=62.92.61.52 DST=x.x.x.x LEN=76 TOS=00 > PREC=0x00 > TTL=53 ID=30173 PROTO=UDP SPT=455 DPT=123 LEN=56 MARK=0 > Jul 2 09:01:13 munin Shorewall:net2fw:DROP: IN=eth0 OUT> MAC=48:5b:39:ac:1b:5e: > 00:12:da:a4:14:bf:08:00 SRC=62.92.61.52 DST=x.x.x.x LEN=76 TOS=00 > PREC=0x00 > TTL=53 ID=30174 PROTO=UDP SPT=455 DPT=123 LEN=56 MARK=0 > > #################### > > I removed DST IP since that is not relevant. > > I hope that somebody on this list can explain what''s going on. > > Currently I''m dropping all traffic from this IP to prevent it from > cluttering my log even more. > > Thanks > > - Øyvind > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev
>But why are they dropped? Because of SPT != 123?I don''t know. But that is exactly what I''m trying to find out. The only rule I have regarding ntp is: NTP(DNAT) net loc:192.168.1.2 192.168.1.2 is my internal box running ntpd. All works well but Shorewall is dropping the packets I pasted in my previous message. ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev
> NTP(DNAT) net loc:192.168.1.2It appears to me that these should not be getting blocked. Do you have another interface these packets are arriving on perhaps - that is not in the NET zone? - Bob ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev
On Jul 2, 2013, at 2:02 AM, Øyvind Lode <oyvind@lode.is> wrote:>> But why are they dropped? Because of SPT != 123? > > I don''t know. > > But that is exactly what I''m trying to find out. > > The only rule I have regarding ntp is: > > NTP(DNAT) net loc:192.168.1.2 > > 192.168.1.2 is my internal box running ntpd. > > All works well but Shorewall is dropping the packets I pasted in my previous message.Shorewall is not dropping them; your kernel is. Shorewall is a configuration tool; it doesn''t do any packet filtering itself. I suspect that these hosts were sending packets prior to the firewall starting (before the DNAT rule was in place). We often see a similar problem with SIP. A un-NATTed connection tracking table entry gets created for them, and all subsequent packets are handled based on that entry. You can install the ''conntrack'' utility and use it to remove the (un-NATTed) conntrack entries for these hosts; or simply ''shorewall restart -p''. Note that the latter command deletes *all* conntrack entries, which may cause some connections to be dropped. This problem can usually be prevented by installing and configuring Shorewall-init. -Tom Tom Eastep \ Nothing is foolproof to a Shoreline, \ sufficiently talented fool Washington, USA \ http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev
From: Tom Eastep [mailto:teastep@shorewall.net] Sent: 2. juli 2013 15:04>I suspect that these hosts were sending packets prior to the firewall starting (before the DNAT rule was in place). We often see a similar problem with SIP. A un-NATTed connection tracking table >entry gets created for them, and all subsequent packets are handled based on that entry.>You can install the ''conntrack'' utility and use it to remove the (un-NATTed) conntrack entries for these hosts; or simply ''shorewall restart -p''. Note that the latter command deletes *all* conntrack >entries, which may cause some connections to be dropped.That did the trick. Thanks.>This problem can usually be prevented by installing and configuring Shorewall-init.I''m looking into shorewall-init now. Thanks again. ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev