On 11/16/18 4:34 AM, Vieri Di Paola wrote: > On Thu, Nov 15, 2018 at 8:48 PM Tom Eastep <teas...@shorewall.net> wrote: >> That's what I believe also. >> >> Vieri - Do I understand correctly that after you physically reconfigure, >> things settle down after some period of time and work properly (and stay >> working properly)? If so, I don't believe that there is anything here to >> worry about. > Simon and Tom, thank you for looking into this. > > I've noticed that it doesn't really matter if I put the Windows 10 > host to sleep for 30 seconds. It happens with any host (Linux, etc.), > and the easy way to "make things work" is to simply disconnect the > host cable from the switch (port with VLAN ID 11 Untagged, in my > case), wait *at least* 30 seconds, and finally connect the cable to > another switch port (VLAN ID 12 Untagged, in my case). If I honor this > time lag, everything behaves "as expected". In my previous tests, I > would move the cable from one port to another on the switch in way > less than 30 seconds. > > I haven't found any ARP timeout setting on this particular switch, > even though I've seen this option somewhere on another brand or model. > > Anyway, yes, once the physical connections are settled, everything > seems to work fine. However, I have to keep in mind that any change in > the wiring requires to keep the switch port down for at least 30 > seconds. > > I'm really curious though, so I took another look at the logs. > The shorewall iptrace below was taken from my previous post at > https://drive.google.com/open?id=1eFYjF9HPi144uzl2Y_oDZxtMCDq4fSog > .That's when things were "not working right". According to the trace, > the packets are actually entering chain dmz12-fw. They should be > dropped, but they are apparently not according to what I see on the > client host itself. > > Nov 15 09:36:40 inf-fw2 kernel: TRACE: raw:PREROUTING:policy:13 IN=br0 > OUT= PHYSIN=enp8s5_12 MAC=00:e3:c0:5f:81:5d:f4:39:09:d9:14:c8:08:00 > SRC=192.168.215.200 DST=192.168.215.1 LEN=60 TOS=0x00 PREC=0x00 > TTL=128 ID=9994 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=16395 > Nov 15 09:36:40 inf-fw2 kernel: TRACE: mangle:PREROUTING:rule:1 IN=br0 > OUT= PHYSIN=enp8s5_12 MAC=00:e3:c0:5f:81:5d:f4:39:09:d9:14:c8:08:00 > SRC=192.168.215.200 DST=192.168.215.1 LEN=60 TOS=0x00 PREC=0x00 > TTL=128 ID=9994 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=16395 > Nov 15 09:36:40 inf-fw2 kernel: TRACE: mangle:PREROUTING:policy:9 > IN=br0 OUT= PHYSIN=enp8s5_12 > MAC=00:e3:c0:5f:81:5d:f4:39:09:d9:14:c8:08:00 SRC=192.168.215.200 > DST=192.168.215.1 LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=9994 PROTO=ICMP > TYPE=8 CODE=0 ID=1 SEQ=16395 > Nov 15 09:36:40 inf-fw2 kernel: TRACE: mangle:INPUT:policy:1 IN=br0 > OUT= PHYSIN=enp8s5_12 MAC=00:e3:c0:5f:81:5d:f4:39:09:d9:14:c8:08:00 > SRC=192.168.215.200 DST=192.168.215.1 LEN=60 TOS=0x00 PREC=0x00 > TTL=128 ID=9994 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=16395 > Nov 15 09:36:40 inf-fw2 kernel: TRACE: filter:INPUT:rule:6 IN=br0 OUT= > PHYSIN=enp8s5_12 MAC=00:e3:c0:5f:81:5d:f4:39:09:d9:14:c8:08:00 > SRC=192.168.215.200 DST=192.168.215.1 LEN=60 TOS=0x00 PREC=0x00 > TTL=128 ID=9994 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=16395 > Nov 15 09:36:40 inf-fw2 kernel: TRACE: filter:br0_in:rule:4 IN=br0 > OUT= PHYSIN=enp8s5_12 MAC=00:e3:c0:5f:81:5d:f4:39:09:d9:14:c8:08:00 > SRC=192.168.215.200 DST=192.168.215.1 LEN=60 TOS=0x00 PREC=0x00 > TTL=128 ID=9994 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=16395 > Nov 15 09:36:40 inf-fw2 kernel: TRACE: filter:dmz12-fw:rule:4 IN=br0 > OUT= PHYSIN=enp8s5_12 MAC=00:e3:c0:5f:81:5d:f4:39:09:d9:14:c8:08:00 > SRC=192.168.215.200 DST=192.168.215.1 LEN=60 TOS=0x00 PREC=0x00 > TTL=128 ID=9994 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=16395 > > So I then searched the shorewall log and found this: > > Nov 15 09:36:40 inf-fw2 kernel: Shorewall:dmz12-fw:DROP:IN=br0 OUT= > PHYSIN=enp8s5_12 MAC=00:e3:c0:5f:81:5d:f4:39:09:d9:14:c8:08:00 > SRC=192.168.215.200 DST=192.168.215.1 LEN=62 TOS=0x00 PREC=0x00 > TTL=128 ID=9995 PROTO=UDP SPT=50892 DPT=53 LEN=42 > > There's nothing regarding ICMP. > I would have expected something like: > > Nov 16 09:36:40 inf-fw2 kernel: Shorewall:dmz12-fw:DROP:IN=br0 OUT= > PHYSIN=enp8s5_12 MAC=00:e3:c0:5f:81:5d:f4:39:09:d9:14:c8:08:00 > SRC=192.168.215.200 DST=192.168.215.1 LEN=60 TOS=0x00 PREC=0x00 > TTL=128 ID=19982 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=22595 > (this line was taken today from a "working environment") > > Basically, what puzzles me most is that the "iptrace" shows that the > dmz12-fw filter is being applied to the ICMP message, but nothing is > logged regarding ICMP in syslog. > I'm wondering if this behavior is ICMP-specific. I haven't tried other > protocols and ports.
You would see the same thing with other protocols. If you look at the
last entry in the iptrace output that you posted, you will see that the
last rule matched is rule #4 in the chain dmz12-fw which is:
10 600 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
ctstate RELATED,ESTABLISHED
Since there was a ping flow established before you swapped the cable,
there was an entry in the conntrack table for that flow:
icmp 1 29 src=192.168.215.200 dst=192.168.215.1 type=8 code=0 id=1
packets=117 bytes=7020 src=192.168.215.1 dst=192.168.215.200 type=0 code=0 id=1
packets=117 bytes=7020 mark=0 use=1
As long as that entry hasn't timed out (and at the time of the dump, it
wouldn't time out for another 29 seconds), packets matching that entry
will be accepted by rule 4.
If you had simply stopped pinging for 30 seconds then started pinging
again, those later echo-request packets would have been dropped.
-Tom
--
Tom Eastep \ Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \ understand
\_______________________________________________
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
