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. Anyway, I can live with it. Thanks again. Vieri _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
