Nachman Yaakov Ziskind
2003-Aug-19 07:50 UTC
[Shorewall-users] Strange packet dropping phenomenon
Shorewall version: 1.4.4b.
# ip addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:10:5a:e1:e3:8b brd ff:ff:ff:ff:ff:ff
inet 38.119.130.5/27 brd 38.119.130.31 scope global eth0
inet 38.119.130.2/27 brd 38.119.130.31 scope global secondary eth0
inet 38.119.130.3/27 brd 38.119.130.31 scope global secondary eth0
inet 38.119.130.4/27 brd 38.119.130.31 scope global secondary eth0
inet 38.119.130.6/27 brd 38.119.130.31 scope global secondary eth0
inet 38.119.130.7/27 brd 38.119.130.31 scope global secondary eth0
inet 38.119.130.8/27 brd 38.119.130.31 scope global secondary eth0
inet 38.119.130.9/27 brd 38.119.130.31 scope global secondary eth0
4: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:50:04:03:91:bc brd ff:ff:ff:ff:ff:ff
inet 10.1.1.200/24 brd 10.1.1.255 scope global eth1
5: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:a0:24:57:55:be brd ff:ff:ff:ff:ff:ff
inet 10.1.2.200/24 brd 10.1.2.200 scope global eth2
# ip route show
38.119.130.0/27 dev eth0 proto kernel scope link src 38.119.130.5
10.1.1.0/24 dev eth1 proto kernel scope link src 10.1.1.200
10.1.2.0/24 dev eth2 proto kernel scope link src 10.1.2.200
default via 38.119.130.1 dev eth0
/etc/shorewall/policy:
loc net ACCEPT
loc fw ACCEPT
fw loc ACCEPT
loc loc ACCEPT
dmz net ACCEPT
net dmz DROP info
dmz loc DROP info
loc dmz DROP info
dmz fw DROP info
fw dmz DROP info
fw net ACCEPT
net all DROP info
all all REJECT info
# grep 53 /etc/shorewall/rules
ACCEPT dmz loc:$ECO100 tcp 1024:65534
ACCEPT dmz net udp 53
ACCEPT dmz net tcp 53
ACCEPT dmz loc udp 53
ACCEPT dmz loc tcp 53
DNAT net loc:$SCO:1053 udp 53
DNAT net loc:$SCO:1053 tcp 53
REJECT:info net fw udp - 53
REJECT:info net loc udp - 53
ACCEPT loc:$SCO net udp 53
ACCEPT loc:$YANKEL net udp 53
ACCEPT loc net udp 53
ACCEPT loc net tcp 53
Some Shorewall logs:
Aug 17 10:00:19 yoreach kernel: Shorewall:FORWARD:REJECT:IN=eth0 OUT=eth0
SRC=193.254.18.42 DST=38.119.130.6 LEN=71 TOS=0x00 PREC=0x00 TTL=234 ID=42151
DF PROTO=UDP SPT=44412 DPT=53 LEN=51
Aug 17 10:00:20 yoreach kernel: Shorewall:FORWARD:REJECT:IN=eth0 OUT=eth0
SRC=202.101.103.55 DST=38.119.130.6 LEN=59 TOS=0x00 PREC=0x00 TTL=240 ID=58852
DF PROTO=UDP SPT=45256 DPT=53 LEN=39
Aug 17 10:00:21 yoreach kernel: Shorewall:FORWARD:REJECT:IN=eth0 OUT=eth0
SRC=216.137.73.70 DST=38.119.130.6 LEN=70 TOS=0x00 PREC=0x00 TTL=246 ID=36008
DF PROTO=UDP SPT=32768 DPT=53 LEN=50
Aug 17 10:00:25 yoreach kernel: Shorewall:net2all:DROP:IN=eth0
OUTMAC=00:10:5a:e1:e3:8b:00:0b:46:9d:a3:80:08:00 SRC=167.206.3.145
DST=38.119.130.6 LEN=82 TOS=0x00 PREC=0x00 TTL=241 ID=39486 DF PROTO=UDP
SPT=49343 DPT=53 LEN=62
Aug 17 10:00:25 yoreach kernel: Shorewall:net2all:DROP:IN=eth0
OUTMAC=00:10:5a:e1:e3:8b:00:0b:46:9d:a3:80:08:00 SRC=216.137.73.70
DST=38.119.130.6 LEN=60 TOS=0x00 PREC=0x00 TTL=247 ID=36011 DF PROTO=UDP
SPT=32768 DPT=53 LEN=40
Aug 17 10:00:25 yoreach kernel: Shorewall:net2all:DROP:IN=eth0
OUTMAC=00:10:5a:e1:e3:8b:00:0b:46:9d:a3:80:08:00 SRC=66.73.20.22
DST=38.119.130.6
LEN=71 TOS=0x00 PREC=0x00 TTL=239 ID=32762 DF PROTO=UDP SPT=19942 DPT=53 LEN=51
Aug 17 10:00:28 yoreach kernel: Shorewall:net2all:DROP:IN=eth0
OUTMAC=00:10:5a:e1:e3:8b:00:0b:46:9d:a3:80:08:00 SRC=24.217.0.3 DST=38.119.130.6
LEN=70 TOS=0x00 PREC=0x00 TTL=242 ID=21543 DF PROTO=UDP SPT=56142 DPT=53 LEN=50
Aug 17 10:00:29 yoreach kernel: Shorewall:net2all:DROP:IN=eth0
OUTMAC=00:10:5a:e1:e3:8b:00:0b:46:9d:a3:80:08:00 SRC=212.59.54.188
DST=38.119.130.6 LEN=71 TOS=0x00 PREC=0x00 TTL=235 ID=15556 DF PROTO=UDP
SPT=37051 DPT=53 LEN=51
Aug 17 10:00:33 yoreach kernel: Shorewall:net2fw:REJECT:IN=eth0
OUTMAC=00:10:5a:e1:e3:8b:00:0b:46:9d:a3:80:08:00 SRC=209.244.4.12
DST=38.119.130.6
LEN=60 TOS=0x00 PREC=0x00 TTL=245 ID=54153 DF PROTO=UDP SPT=53 DPT=53 LEN=40
Aug 17 10:00:33 yoreach kernel: Shorewall:net2all:DROP:IN=eth0
OUTMAC=00:10:5a:e1:e3:8b:00:0b:46:9d:a3:80:08:00 SRC=193.254.18.42
DST=38.119.130.6 LEN=71 TOS=0x00 PREC=0x00 TTL=235 ID=42153 DF PROTO=UDP
SPT=44412 DPT=53 LEN=51
Aug 17 10:00:34 yoreach kernel: Shorewall:net2all:DROP:IN=eth0
OUTMAC=00:10:5a:e1:e3:8b:00:0b:46:9d:a3:80:08:00 SRC=167.206.3.212
DST=38.119.130.6 LEN=82 TOS=0x00 PREC=0x00 TTL=242 ID=42372 DF PROTO=UDP
SPT=63084 DPT=53 LEN=62
Aug 17 10:00:36 yoreach kernel: Shorewall:net2all:DROP:IN=eth0
OUTMAC=00:10:5a:e1:e3:8b:00:0b:46:9d:a3:80:08:00 SRC=202.101.103.55
DST=38.119.130.6 LEN=60 TOS=0x00 PREC=0x00 TTL=241 ID=58858 DF PROTO=UDP
SPT=45256 DPT=53 LEN=40
These logs were produced first thing after restarting the firewall when we
recovered from the blackout. Shorewall was the last machine to be started,
hence the destination machine(s) were already up.
I don''t understand why these packets should be dropped, because:
a) The rules seem to accept them;
b) Later packets to the same port get through (feel free to test);
c) Some packets are rejected under different chains (is that the right word?)
at different times, e.g. 193.254.18.42 under FORWARD:REJECT, and, later, DROP.
The only thing that makes sense is that firewall had to "warm up", not
unlike
an old television. I don''t believe this, but I made absolutely NO
changes since
booting (this is a Bering floppy-based firewall).
The only other thing I notice is that, since 38.119.130.6 is NAT''ed,
Shorewall
translates them to the local IP address (here 10.1.1.1). But these messages
remain untranslated. I emphasize that this is not an ongoing problem;
everything works fine now (which is why I feel guilty posting this).
I suppose I''m missing something obvious (as usual). But what?
--
_________________________________________
Nachman Yaakov Ziskind, EA, LLM awacs@egps.com
Attorney and Counselor-at-Law http://yankel.com
Economic Group Pension Services http://egps.com
Actuaries and Employee Benefit Consultants
On Tue, 2003-08-19 at 07:50, Nachman Yaakov Ziskind wrote:> > The only thing that makes sense is that firewall had to "warm up", not unlike > an old television. I don''t believe this, but I made absolutely NO changes since > booting (this is a Bering floppy-based firewall). > > The only other thing I notice is that, since 38.119.130.6 is NAT''ed, Shorewall > translates them to the local IP address (here 10.1.1.1). But these messages > remain untranslated. I emphasize that this is not an ongoing problem; > everything works fine now (which is why I feel guilty posting this). > > I suppose I''m missing something obvious (as usual). But what?You are missing the fact that there is no atomic way to create a Netfilter ruleset. The consequence is that if there is lots of traffic being aimed at your firewall then during [re]start you will see a flurry of messages until the firewall is completely up and configured. You should ignore all logged messages occurring around the time of a [re]start. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Tue, 2003-08-19 at 07:57, Tom Eastep wrote:> You are missing the fact that there is no atomic way to create a > Netfilter ruleset. The consequence is that if there is lots of traffic > being aimed at your firewall then during [re]start you will see a flurry > of messages until the firewall is completely up and configured. You > should ignore all logged messages occurring around the time of a > [re]start.You should also know that kernel messages are timestamped when they are logged by klogd rather than when they are created. So during times of heavy system activity, these messages can appear to be logged over a longer period of time than is actually the case. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Nachman Yaakov Ziskind
2003-Aug-19 08:19 UTC
[Shorewall-users] Re: Strange packet dropping phenomenon
shorewall-users-request@lists.shorewall.net wrote (on Tue, Aug 19, 2003 at> > I suppose I''m missing something obvious (as usual). But what? > > You are missing the fact that there is no atomic way to create a > Netfilter ruleset. The consequence is that if there is lots of traffic > being aimed at your firewall then during [re]start you will see a flurry > of messages until the firewall is completely up and configured. You > should ignore all logged messages occurring around the time of a > [re]start. > > You should also know that kernel messages are timestamped when they are > logged by klogd rather than when they are created. So during times of > heavy system activity, these messages can appear to be logged over a > longer period of time than is actually the case.> -Tom > -- > Tom Eastep \ Shorewall - iptables made easy > Shoreline, \ http://shorewall.net > Washington USA \ teastep@shorewall.netI didn''t realize either of these things. Thank you for making this clear to me. (I feel happy that my own surmise was [kinda] correct) :-) NYZ -- _________________________________________ Nachman Yaakov Ziskind, EA, LLM awacs@egps.com Attorney and Counselor-at-Law http://yankel.com Economic Group Pension Services http://egps.com Actuaries and Employee Benefit Consultants
On Tue, 2003-08-19 at 08:19, Nachman Yaakov Ziskind wrote:> shorewall-users-request@lists.shorewall.net wrote (on Tue, Aug 19, 2003 at > > > > I suppose I''m missing something obvious (as usual). But what? > > > > You are missing the fact that there is no atomic way to create a > > Netfilter ruleset. The consequence is that if there is lots of traffic > > being aimed at your firewall then during [re]start you will see a flurry > > of messages until the firewall is completely up and configured. You > > should ignore all logged messages occurring around the time of a > > [re]start. > > > > You should also know that kernel messages are timestamped when they are > > logged by klogd rather than when they are created. So during times of > > heavy system activity, these messages can appear to be logged over a > > longer period of time than is actually the case. > > I didn''t realize either of these things. Thank you for making this clear to > me. >This is not to say that Shorewall couldn''t do a better job of message suppression during startup but that''s a project that hasn''t popped to the top of my stack yet. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net