Re: [Shorewall-users] shorewall VLANs and network ranges
On Fri, Nov 16, 2018 at 6:50 PM Tom Eastep wrote: > > 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/00.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. A huge thanks for this explanation! It's really great to know what happens under the hood. Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall VLANs and network ranges
On 11/16/18 4:34 AM, Vieri Di Paola wrote: > On Thu, Nov 15, 2018 at 8:48 PM Tom Eastep 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/00.0.0.0/0 ctstate RELATED,ESTABLISHED Since there was a ping
Re: [Shorewall-users] shorewall VLANs and network ranges
On Thu, Nov 15, 2018 at 8:48 PM Tom Eastep 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
Re: [Shorewall-users] shorewall VLANs and network ranges
On 11/15/18 9:47 AM, Simon Matter wrote: >> OK, I'm seeing a very odd behavior here, but at least I can now easily >> reproduce the issue. >> >> I have a test host with IP address 192.168.215.200 pinging continously >> the Shorewall FW at 192.168.215.1. >> At first, I connect it to Switch Port with VLAN ID 11 Untagged (enp8s5 >> on the FW is connected to Switch Port VLAN 11 tagged + 12 tagged + 1 >> tagged). It gets the ICMP replies just fine, as expected according to >> my Shorewall rules. >> >> I've captured dumps and traces while this was happening (I can see >> traffic on VLAN 11, nothing on VLAN 12 which is OK): >> >> SW DUMP: >> https://drive.google.com/open?id=1_wLPvrowWGE4CPFYMQSzqxz0_FvZXm4q >> SW TRACE: >> https://drive.google.com/open?id=1AXzSDhBTN62veUPYjzVxgddPEBdY1Amy >> >> I then disconnected the test host's ethernet cable from the Switch and >> plugged it into another port on the same Switch but with VLAN ID 12 >> Untagged. >> The test host keeps pinging FW at 192.168.215.1 successfully when it >> SHOULDN'T because of my Shorewall rules and policies. >> A tcpdump on the enp8s5_12 interface shows VLAN 12 traffic and ICMP >> requests/replies. >> A tcpdump on the enp8s5_11 interface shows that there's no more VLAN 11 >> traffic. >> >> I grabbed a SW dump, SW trace and a tcpdump: >> >> TCPDUMP on enp8s5_12: >> https://drive.google.com/open?id=1JVSOMNsXmPA1gKaVhYguZr0VmKzwSOER >> TCPDUMP on enp8s5: >> https://drive.google.com/open?id=1pxyuMP6lynquB_BEks56HzjPqeWg-J6U >> SW DUMP: >> https://drive.google.com/open?id=1donyBraZpwKSyNG4w75LGkfPvlwgf3B9 >> SW TRACE: >> https://drive.google.com/open?id=1eFYjF9HPi144uzl2Y_oDZxtMCDq4fSog >> >> The test host is a Windows 10 laptop. Disconnecting its ethernet cable >> and putting it back in did not change anything. However, I noticed >> that if I put the laptop in sleep mode and woke it up again after AT >> LEAST 30 seconds, traffic behavior would finally be "as expected", ie. >> the test host would fail pinging the FW. > > I can't follow you here with all the details and dumps... > > It just sounds to me like it has something to do with ARP caches, on a > switch, on a host, on a router? > > Or even more fun, host routes generated through ICMP redirect messages? > 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. -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
Re: [Shorewall-users] shorewall VLANs and network ranges
> OK, I'm seeing a very odd behavior here, but at least I can now easily > reproduce the issue. > > I have a test host with IP address 192.168.215.200 pinging continously > the Shorewall FW at 192.168.215.1. > At first, I connect it to Switch Port with VLAN ID 11 Untagged (enp8s5 > on the FW is connected to Switch Port VLAN 11 tagged + 12 tagged + 1 > tagged). It gets the ICMP replies just fine, as expected according to > my Shorewall rules. > > I've captured dumps and traces while this was happening (I can see > traffic on VLAN 11, nothing on VLAN 12 which is OK): > > SW DUMP: > https://drive.google.com/open?id=1_wLPvrowWGE4CPFYMQSzqxz0_FvZXm4q > SW TRACE: > https://drive.google.com/open?id=1AXzSDhBTN62veUPYjzVxgddPEBdY1Amy > > I then disconnected the test host's ethernet cable from the Switch and > plugged it into another port on the same Switch but with VLAN ID 12 > Untagged. > The test host keeps pinging FW at 192.168.215.1 successfully when it > SHOULDN'T because of my Shorewall rules and policies. > A tcpdump on the enp8s5_12 interface shows VLAN 12 traffic and ICMP > requests/replies. > A tcpdump on the enp8s5_11 interface shows that there's no more VLAN 11 > traffic. > > I grabbed a SW dump, SW trace and a tcpdump: > > TCPDUMP on enp8s5_12: > https://drive.google.com/open?id=1JVSOMNsXmPA1gKaVhYguZr0VmKzwSOER > TCPDUMP on enp8s5: > https://drive.google.com/open?id=1pxyuMP6lynquB_BEks56HzjPqeWg-J6U > SW DUMP: > https://drive.google.com/open?id=1donyBraZpwKSyNG4w75LGkfPvlwgf3B9 > SW TRACE: > https://drive.google.com/open?id=1eFYjF9HPi144uzl2Y_oDZxtMCDq4fSog > > The test host is a Windows 10 laptop. Disconnecting its ethernet cable > and putting it back in did not change anything. However, I noticed > that if I put the laptop in sleep mode and woke it up again after AT > LEAST 30 seconds, traffic behavior would finally be "as expected", ie. > the test host would fail pinging the FW. I can't follow you here with all the details and dumps... It just sounds to me like it has something to do with ARP caches, on a switch, on a host, on a router? Or even more fun, host routes generated through ICMP redirect messages? Regards, Simon ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall VLANs and network ranges
OK, I'm seeing a very odd behavior here, but at least I can now easily reproduce the issue. I have a test host with IP address 192.168.215.200 pinging continously the Shorewall FW at 192.168.215.1. At first, I connect it to Switch Port with VLAN ID 11 Untagged (enp8s5 on the FW is connected to Switch Port VLAN 11 tagged + 12 tagged + 1 tagged). It gets the ICMP replies just fine, as expected according to my Shorewall rules. I've captured dumps and traces while this was happening (I can see traffic on VLAN 11, nothing on VLAN 12 which is OK): SW DUMP: https://drive.google.com/open?id=1_wLPvrowWGE4CPFYMQSzqxz0_FvZXm4q SW TRACE: https://drive.google.com/open?id=1AXzSDhBTN62veUPYjzVxgddPEBdY1Amy I then disconnected the test host's ethernet cable from the Switch and plugged it into another port on the same Switch but with VLAN ID 12 Untagged. The test host keeps pinging FW at 192.168.215.1 successfully when it SHOULDN'T because of my Shorewall rules and policies. A tcpdump on the enp8s5_12 interface shows VLAN 12 traffic and ICMP requests/replies. A tcpdump on the enp8s5_11 interface shows that there's no more VLAN 11 traffic. I grabbed a SW dump, SW trace and a tcpdump: TCPDUMP on enp8s5_12: https://drive.google.com/open?id=1JVSOMNsXmPA1gKaVhYguZr0VmKzwSOER TCPDUMP on enp8s5: https://drive.google.com/open?id=1pxyuMP6lynquB_BEks56HzjPqeWg-J6U SW DUMP: https://drive.google.com/open?id=1donyBraZpwKSyNG4w75LGkfPvlwgf3B9 SW TRACE: https://drive.google.com/open?id=1eFYjF9HPi144uzl2Y_oDZxtMCDq4fSog The test host is a Windows 10 laptop. Disconnecting its ethernet cable and putting it back in did not change anything. However, I noticed that if I put the laptop in sleep mode and woke it up again after AT LEAST 30 seconds, traffic behavior would finally be "as expected", ie. the test host would fail pinging the FW. I grabbed tcpdumps during this last phase: TCPDUMP on enp8s5_12: https://drive.google.com/open?id=1N7nFuCIDrEnTMjmL-licXQdWNl1-zVpi TCPDUMP on enp8s5: https://drive.google.com/open?id=1nv3VRelC6WicJauQTXqAWffb-HV5l5DL If I compare the SW traces, I don't see anything strange at first glance. Before moving the network cable, traffic was filtered through dmz11-fw. Afterwards, it was filtered through dmz12-fw. So it "sounds" right. Any thoughts? Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall VLANs and network ranges
On Wed, Nov 14, 2018 at 6:14 PM Tom Eastep wrote: > > No -- I was apparently confusing enp8s5 with enp5s0 (I hate this new NIC > naming convention). > > It appears that *no* traffic entered via enp5s0 during the period of > time covered by the dump: hmm,,, you mean enp8s5, right? ;-) > Or, at least, none made it as far as the filter table. So I suggest > analyzing the packet flow with 'shorewall iptrace -s 192.168.215.201 -d > 192.168.215.1' so we can see how netfilter is processing the echo > request packets'. I'll do an iptrace asap. In the meantime, I've noticed something really weird. After a "while" (not quantifiable yet), the traffic seems to flow "as expected", and the Shorewall rules/policies are being "applied", finally. However, I've also noticed the following *after everything seemed to be working OK*: 1) one host was connected to Switch Port with VLAN 11 Untagged (host1) 2) another host to Switch Port VLAN 12 Untagged (host2) 3) the Shorewall br0 config now includes vlans 1, 11, 12 and is working "fine", apparently. For instance, according to my new rules, vlan 11 hosts can only ping dst_host1, vlan 12 hosts can only ping dst_host2. So, host1 can ping dst_host1, host2 can ping dst_host2. All's fine until I switch the cables of both host1 and host2, ie. I connect host1 to Switch Port with VLAN 12 Untagged, and host2 to Switch Port VLAN 11 Untagged. I was expecting to see DROPped packets on both hosts. Instead, they were pinging just fine. 4) tcpdump -i enp8s5 -n -e vlan showed that the ICMP packets from host1 were marked with "vlan 12", packets from host2 were marked with "vlan 11" (it was the other way around before switching the cables on the Switch). So everything "seems" to be OK, but the SW rules/policies are not honored. 5) finally, if I wait a "while", the packets are suddenly "DROPped", according to my SW rules. I do not do anything at all on the Shorewall system -- not even a reload. 6) it also seems that restarting the Switch fixes these issues... Again, I have NOT touched the switch's configuration. Also, the above tcpdump (-e vlan) seems to reflect the right VLAN IDs each time. In any case, I haven't done this so often as to confirm that restarting the switch actually "fixes things". So at this point it could be anything. I'll perform an iptrace and post the results asap. Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall VLANs and network ranges
On 11/14/18 12:29 AM, Vieri Di Paola wrote: > On Wed, Nov 14, 2018 at 12:53 AM Tom Eastep wrote: >> Because you have given interface enp8s5 an IP address and have assigned >> it to the dmz zone, and your rules allow ping from dmz -> fw. The bridge >> configuration never comes into play. In a valid bridge configuration, >> the bridge port interfaces have no IP configuration and are only defined >> to Shorewall as bport interfaces. > You lost me there. > > As far as I can tell, I haven't set any IP address to enp8s5 or > assigned it to the dmz zone. > Here's what I have in my interfaces file: > > dmz enp5s0 routeback,dhcp,proxyarp=1 > dmzxbr0 bridge,dhcp,proxyarp=1 > dmz0br0:enp8s5 routeback > dmz1br0:enp8s5_1routeback > dmz11 br0:enp8s5_11 routeback > > Also, this is my network configuration which is the same as the one > reported in the SW dump: > > # ip addr show enp8s5 > 8: enp8s5: mtu 1500 qdisc fq_codel > master br0 state UP group default qlen 1000 > link/ether 00:e3:c0:5f:81:5d brd ff:ff:ff:ff:ff:ff > inet6 fe80::2e3:c0ff:fe5f:815d/64 scope link >valid_lft forever preferred_lft forever > # ip addr show enp8s5_1 > 60: enp8s5_1@enp8s5: mtu 1500 qdisc > noqueue master br0 state UP group default qlen 1000 > link/ether 00:e3:c0:5f:81:5d brd ff:ff:ff:ff:ff:ff > inet6 fe80::2e3:c0ff:fe5f:815d/64 scope link >valid_lft forever preferred_lft forever > # ip addr show enp8s5_11 > 61: enp8s5_11@enp8s5: mtu 1500 qdisc > noqueue master br0 state UP group default qlen 1000 > link/ether 00:e3:c0:5f:81:5d brd ff:ff:ff:ff:ff:ff > inet6 fe80::2e3:c0ff:fe5f:815d/64 scope link >valid_lft forever preferred_lft forever > # ip addr show br0 > 62: br0: mtu 1500 qdisc > noqueue state UP group default qlen 1000 > link/ether 00:e3:c0:5f:81:5d brd ff:ff:ff:ff:ff:ff > inet 192.168.215.1/24 brd 192.168.215.255 scope global br0 >valid_lft forever preferred_lft forever > inet6 fe80::2e3:c0ff:fe5f:815d/64 scope link >valid_lft forever preferred_lft forever > # ip addr show enp5s0 > 2: enp5s0: mtu 1500 qdisc pfifo_fast > state UP group default qlen 1000 > link/ether 68:05:ca:11:64:30 brd ff:ff:ff:ff:ff:ff > inet 192.168.210.1/23 brd 192.168.211.255 scope global enp5s0 >valid_lft forever preferred_lft forever > inet 192.168.212.1/24 brd 192.168.212.255 scope global enp5s0 >valid_lft forever preferred_lft forever > inet6 fe80::6a05:caff:fe11:6430/64 scope link >valid_lft forever preferred_lft forever > > As you can see from the above, enp8s5 does not have an IP address > configured. Only br0 has a management IP address which I need anyway. > Also, br0 only covers enp8s5, enp8s5_1 and enp8s5_11, not enp5s0. > > The traffic's source address reported in this dump is not in the dmz > zone but in dmz1, ie. the traffic flow is through the br0 bridge. > > Have I overlooked something? > No -- I was apparently confusing enp8s5 with enp5s0 (I hate this new NIC naming convention). It appears that *no* traffic entered via enp5s0 during the period of time covered by the dump: Chain br0_fwd (1 references) pkts bytes target prot opt in out source destination 0 0 dmz0_frwd all -- * * 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in enp8s5 policy match dir in pol none < 25 4464 dmz1_frwd all -- * * 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in enp8s5_1 policy match dir in pol none 0 0 dmz11_frwd all -- * * 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in enp8s5_11 policy match dir in pol none 0 0 dmzx_frwd all -- * * 0.0.0.0/00.0.0.0/0 policy match dir in pol none Chain br0_in (1 references) pkts bytes target prot opt in out source destination 0 0 dmz0-fwall -- * * 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in enp8s5 policy match dir in pol none <=== 49 4424 dmz1-fwall -- * * 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in enp8s5_1 policy match dir in pol none 0 0 dmz11-fw all -- * * 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in enp8s5_11 policy match dir in pol none 0 0 dmzx-fwall -- * * 0.0.0.0/00.0.0.0/0 policy match dir in pol none Or, at least, none made it as far as the filter table. So I suggest analyzing the packet flow with 'shorewall iptrace -s 192.168.215.201 -d 192.168.215.1' so we can see how netfilter is processing the echo request packets'. -Tom -- Tom Eastep\ Q: What do you get when you cross a mobster with Shoreline, \ an international standard? Washington, USA \ A:
Re: [Shorewall-users] shorewall VLANs and network ranges
On Wed, Nov 14, 2018 at 12:53 AM Tom Eastep wrote: > > Because you have given interface enp8s5 an IP address and have assigned > it to the dmz zone, and your rules allow ping from dmz -> fw. The bridge > configuration never comes into play. In a valid bridge configuration, > the bridge port interfaces have no IP configuration and are only defined > to Shorewall as bport interfaces. You lost me there. As far as I can tell, I haven't set any IP address to enp8s5 or assigned it to the dmz zone. Here's what I have in my interfaces file: dmz enp5s0 routeback,dhcp,proxyarp=1 dmzxbr0 bridge,dhcp,proxyarp=1 dmz0br0:enp8s5 routeback dmz1br0:enp8s5_1routeback dmz11 br0:enp8s5_11 routeback Also, this is my network configuration which is the same as the one reported in the SW dump: # ip addr show enp8s5 8: enp8s5: mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000 link/ether 00:e3:c0:5f:81:5d brd ff:ff:ff:ff:ff:ff inet6 fe80::2e3:c0ff:fe5f:815d/64 scope link valid_lft forever preferred_lft forever # ip addr show enp8s5_1 60: enp8s5_1@enp8s5: mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000 link/ether 00:e3:c0:5f:81:5d brd ff:ff:ff:ff:ff:ff inet6 fe80::2e3:c0ff:fe5f:815d/64 scope link valid_lft forever preferred_lft forever # ip addr show enp8s5_11 61: enp8s5_11@enp8s5: mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000 link/ether 00:e3:c0:5f:81:5d brd ff:ff:ff:ff:ff:ff inet6 fe80::2e3:c0ff:fe5f:815d/64 scope link valid_lft forever preferred_lft forever # ip addr show br0 62: br0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:e3:c0:5f:81:5d brd ff:ff:ff:ff:ff:ff inet 192.168.215.1/24 brd 192.168.215.255 scope global br0 valid_lft forever preferred_lft forever inet6 fe80::2e3:c0ff:fe5f:815d/64 scope link valid_lft forever preferred_lft forever # ip addr show enp5s0 2: enp5s0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 68:05:ca:11:64:30 brd ff:ff:ff:ff:ff:ff inet 192.168.210.1/23 brd 192.168.211.255 scope global enp5s0 valid_lft forever preferred_lft forever inet 192.168.212.1/24 brd 192.168.212.255 scope global enp5s0 valid_lft forever preferred_lft forever inet6 fe80::6a05:caff:fe11:6430/64 scope link valid_lft forever preferred_lft forever As you can see from the above, enp8s5 does not have an IP address configured. Only br0 has a management IP address which I need anyway. Also, br0 only covers enp8s5, enp8s5_1 and enp8s5_11, not enp5s0. The traffic's source address reported in this dump is not in the dmz zone but in dmz1, ie. the traffic flow is through the br0 bridge. Have I overlooked something? Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall VLANs and network ranges
On 11/13/18 6:09 AM, Vieri Di Paola wrote: > Here's another shorewall dump while pinging from a host with IP > address 192.168.215.201 connected to a VLAN 1 Untagged switch port to > the $FW's IP address 192.168.210.1 whose ethernet interface is > connected to a VLAN 1 Tagged switch port (it is also Tagged VLAN 11). > > https://drive.google.com/open?id=1Yir0pYxF4FfrfnE8THFQa09kaDPD6CsZ > > I'm expecting DROPs because of my policy. The only ACCEPT rule I have is: > > Ping/ACCEPT:infodmz11 $FW > > However, the ICMP requests/replies are flowing. > > # tcpdump -n -i enp8s5 -e > dropped privs to tcpdump > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on enp8s5, link-type EN10MB (Ethernet), capture size 262144 bytes > 15:00:41.249573 00:24:54:d9:cb:e4 > 00:e3:c0:5f:81:5d, ethertype > 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, > 192.168.215.201 > 192.168.215.1: ICMP echo request, id 1, seq 11488, > length 40 > 15:00:41.249643 00:e3:c0:5f:81:5d > 00:24:54:d9:cb:e4, ethertype > 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.1 >> 192.168.215.201: ICMP echo reply, id 1, seq 11488, length 40 > 15:00:42.252547 00:24:54:d9:cb:e4 > 00:e3:c0:5f:81:5d, ethertype > 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, > 192.168.215.201 > 192.168.215.1: ICMP echo request, id 1, seq 11489, > length 40 > 15:00:42.252594 00:e3:c0:5f:81:5d > 00:24:54:d9:cb:e4, ethertype > 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.1 >> 192.168.215.201: ICMP echo reply, id 1, seq 11489, length 40 > 15:00:43.255624 00:24:54:d9:cb:e4 > 00:e3:c0:5f:81:5d, ethertype > 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, > 192.168.215.201 > 192.168.215.1: ICMP echo request, id 1, seq 11490, > length 40 > 15:00:43.255683 00:e3:c0:5f:81:5d > 00:24:54:d9:cb:e4, ethertype > 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.1 >> 192.168.215.201: ICMP echo reply, id 1, seq 11490, length 40 > 15:00:44.259597 00:24:54:d9:cb:e4 > 00:e3:c0:5f:81:5d, ethertype > 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, > 192.168.215.201 > 192.168.215.1: ICMP echo request, id 1, seq 11491, > length 40 > 15:00:44.259666 00:e3:c0:5f:81:5d > 00:24:54:d9:cb:e4, ethertype > 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.1 >> 192.168.215.201: ICMP echo reply, id 1, seq 11491, length 40 > 15:00:45.262619 00:24:54:d9:cb:e4 > 00:e3:c0:5f:81:5d, ethertype > 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, > 192.168.215.201 > 192.168.215.1: ICMP echo request, id 1, seq 11492, > length 40 > 15:00:45.262671 00:e3:c0:5f:81:5d > 00:24:54:d9:cb:e4, ethertype > 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.1 >> 192.168.215.201: ICMP echo reply, id 1, seq 11492, length 40 > 15:00:46.265721 00:24:54:d9:cb:e4 > 00:e3:c0:5f:81:5d, ethertype > 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, > 192.168.215.201 > 192.168.215.1: ICMP echo request, id 1, seq 11493, > length 40 > 15:00:46.265779 00:e3:c0:5f:81:5d > 00:24:54:d9:cb:e4, ethertype > 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.1 >> 192.168.215.201: ICMP echo reply, id 1, seq 11493, length 40 > 15:00:46.697949 48:ee:0c:37:8e:2e > 01:80:c2:00:00:0e, ethertype LLDP > (0x88cc), length 60: LLDP, length 46 > 15:00:47.268733 00:24:54:d9:cb:e4 > 00:e3:c0:5f:81:5d, ethertype > 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, > 192.168.215.201 > 192.168.215.1: ICMP echo request, id 1, seq 11494, > length 40 > 15:00:47.268814 00:e3:c0:5f:81:5d > 00:24:54:d9:cb:e4, ethertype > 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.1 >> 192.168.215.201: ICMP echo reply, id 1, seq 11494, length 40 > 15:00:48.272706 00:24:54:d9:cb:e4 > 00:e3:c0:5f:81:5d, ethertype > 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, > 192.168.215.201 > 192.168.215.1: ICMP echo request, id 1, seq 11495, > length 40 > 15:00:48.272752 00:e3:c0:5f:81:5d > 00:24:54:d9:cb:e4, ethertype > 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.1 >> 192.168.215.201: ICMP echo reply, id 1, seq 11495, length 40 > 15:00:49.120878 fc:ec:da:a0:40:a5 > ff:ff:ff:ff:ff:ff, ethertype > 802.1Q (0x8100), length 192: vlan 1, p 0, ethertype IPv4, > 192.168.210.48.50227 > 255.255.255.255.10001: UDP, length 146 > 15:00:49.121759 fc:ec:da:a0:40:a5 > 33:33:00:00:00:01, ethertype > 802.1Q (0x8100), length 212: vlan 1, p 0, ethertype IPv6, > fe80::feec:daff:fea0:40a5.43336 > ff02::1.10001: UDP, length 146 > 15:00:49.121950 fc:ec:da:a0:3d:a7 > ff:ff:ff:ff:ff:ff, ethertype > 802.1Q (0x8100), length 192: vlan 1, p 0, ethertype IPv4, > 192.168.210.49.57553 > 255.255.255.255.10001: UDP, length 146 > 15:00:49.275777 00:24:54:d9:cb:e4 > 00:e3:c0:5f:81:5d, ethertype > 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, > 192.168.215.201 > 192.168.215.1: ICMP echo request, id 1, seq 11496, > length 40 > 15:00:49.2758
[Shorewall-users] shorewall VLANs and network ranges
Here's another shorewall dump while pinging from a host with IP address 192.168.215.201 connected to a VLAN 1 Untagged switch port to the $FW's IP address 192.168.210.1 whose ethernet interface is connected to a VLAN 1 Tagged switch port (it is also Tagged VLAN 11). https://drive.google.com/open?id=1Yir0pYxF4FfrfnE8THFQa09kaDPD6CsZ I'm expecting DROPs because of my policy. The only ACCEPT rule I have is: Ping/ACCEPT:infodmz11 $FW However, the ICMP requests/replies are flowing. # tcpdump -n -i enp8s5 -e dropped privs to tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on enp8s5, link-type EN10MB (Ethernet), capture size 262144 bytes 15:00:41.249573 00:24:54:d9:cb:e4 > 00:e3:c0:5f:81:5d, ethertype 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.201 > 192.168.215.1: ICMP echo request, id 1, seq 11488, length 40 15:00:41.249643 00:e3:c0:5f:81:5d > 00:24:54:d9:cb:e4, ethertype 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.1 > 192.168.215.201: ICMP echo reply, id 1, seq 11488, length 40 15:00:42.252547 00:24:54:d9:cb:e4 > 00:e3:c0:5f:81:5d, ethertype 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.201 > 192.168.215.1: ICMP echo request, id 1, seq 11489, length 40 15:00:42.252594 00:e3:c0:5f:81:5d > 00:24:54:d9:cb:e4, ethertype 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.1 > 192.168.215.201: ICMP echo reply, id 1, seq 11489, length 40 15:00:43.255624 00:24:54:d9:cb:e4 > 00:e3:c0:5f:81:5d, ethertype 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.201 > 192.168.215.1: ICMP echo request, id 1, seq 11490, length 40 15:00:43.255683 00:e3:c0:5f:81:5d > 00:24:54:d9:cb:e4, ethertype 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.1 > 192.168.215.201: ICMP echo reply, id 1, seq 11490, length 40 15:00:44.259597 00:24:54:d9:cb:e4 > 00:e3:c0:5f:81:5d, ethertype 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.201 > 192.168.215.1: ICMP echo request, id 1, seq 11491, length 40 15:00:44.259666 00:e3:c0:5f:81:5d > 00:24:54:d9:cb:e4, ethertype 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.1 > 192.168.215.201: ICMP echo reply, id 1, seq 11491, length 40 15:00:45.262619 00:24:54:d9:cb:e4 > 00:e3:c0:5f:81:5d, ethertype 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.201 > 192.168.215.1: ICMP echo request, id 1, seq 11492, length 40 15:00:45.262671 00:e3:c0:5f:81:5d > 00:24:54:d9:cb:e4, ethertype 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.1 > 192.168.215.201: ICMP echo reply, id 1, seq 11492, length 40 15:00:46.265721 00:24:54:d9:cb:e4 > 00:e3:c0:5f:81:5d, ethertype 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.201 > 192.168.215.1: ICMP echo request, id 1, seq 11493, length 40 15:00:46.265779 00:e3:c0:5f:81:5d > 00:24:54:d9:cb:e4, ethertype 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.1 > 192.168.215.201: ICMP echo reply, id 1, seq 11493, length 40 15:00:46.697949 48:ee:0c:37:8e:2e > 01:80:c2:00:00:0e, ethertype LLDP (0x88cc), length 60: LLDP, length 46 15:00:47.268733 00:24:54:d9:cb:e4 > 00:e3:c0:5f:81:5d, ethertype 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.201 > 192.168.215.1: ICMP echo request, id 1, seq 11494, length 40 15:00:47.268814 00:e3:c0:5f:81:5d > 00:24:54:d9:cb:e4, ethertype 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.1 > 192.168.215.201: ICMP echo reply, id 1, seq 11494, length 40 15:00:48.272706 00:24:54:d9:cb:e4 > 00:e3:c0:5f:81:5d, ethertype 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.201 > 192.168.215.1: ICMP echo request, id 1, seq 11495, length 40 15:00:48.272752 00:e3:c0:5f:81:5d > 00:24:54:d9:cb:e4, ethertype 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.1 > 192.168.215.201: ICMP echo reply, id 1, seq 11495, length 40 15:00:49.120878 fc:ec:da:a0:40:a5 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 192: vlan 1, p 0, ethertype IPv4, 192.168.210.48.50227 > 255.255.255.255.10001: UDP, length 146 15:00:49.121759 fc:ec:da:a0:40:a5 > 33:33:00:00:00:01, ethertype 802.1Q (0x8100), length 212: vlan 1, p 0, ethertype IPv6, fe80::feec:daff:fea0:40a5.43336 > ff02::1.10001: UDP, length 146 15:00:49.121950 fc:ec:da:a0:3d:a7 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 192: vlan 1, p 0, ethertype IPv4, 192.168.210.49.57553 > 255.255.255.255.10001: UDP, length 146 15:00:49.275777 00:24:54:d9:cb:e4 > 00:e3:c0:5f:81:5d, ethertype 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.201 > 192.168.215.1: ICMP echo request, id 1, seq 11496, length 40 15:00:49.275830 00:e3:c0:5f:81:5d > 00:24:54:d9:cb:e4, ethertype 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.1 > 192.168.215.201: ICMP echo reply, id 1, seq 11496, length 40 15:00:50.278810 00:24:54:d9
[Shorewall-users] shorewall VLANs and network ranges
-- Forwarded message - From: Vieri Di Paola Date: Tue, Nov 13, 2018 at 11:34 AM Subject: Re: [Shorewall-users] shorewall VLANs and network ranges To: > > Here's the shorewall dump when I try to ping $FW (192.168.215.1) from > a host in "dmz0" with IP address 192.168.215.200: > > https://drive.google.com/open?id=1ldm7DZvTEgaMqtt7Rt_PydWGd-XcSwWd > > The dmz0 host gets ICMP replies from the Firewall. Why? > How can I properly reject this traffic? Well, oddly enough, the ICMP traffic started to be rejected AFTER quite a while... Still though, I'm expecting to see a REJECT message on a regular basis in Shorewall's log because the host at 192.168.215.200 is pinging 192.168.210.1 continuously. Instead, here's the log: Nov 13 11:43:50 inf-fw2 kernel: Shorewall:dmz0-fw:REJECT:IN=br0 OUT= PHYSIN=enp8s5 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=32297 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=7884 Nov 13 11:43:51 inf-fw2 kernel: Shorewall:dmz0-fw:REJECT:IN=br0 OUT= PHYSIN=enp8s5 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=32298 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=7885 Nov 13 11:43:52 inf-fw2 kernel: Shorewall:dmz0-fw:REJECT:IN=br0 OUT= PHYSIN=enp8s5 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=32299 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=7886 Nov 13 11:43:53 inf-fw2 kernel: Shorewall:dmz0-fw:REJECT:IN=br0 OUT= PHYSIN=enp8s5 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=32302 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=7887 Nov 13 11:43:58 inf-fw2 kernel: Shorewall:dmz0-fw:REJECT:IN=br0 OUT= PHYSIN=enp8s5 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=32305 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=7888 Nov 13 11:43:59 inf-fw2 kernel: Shorewall:dmz0-fw:REJECT:IN=br0 OUT= PHYSIN=enp8s5 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=32310 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=7889 Nov 13 11:44:00 inf-fw2 kernel: Shorewall:dmz0-fw:REJECT:IN=br0 OUT= PHYSIN=enp8s5 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=32311 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=7890 Nov 13 11:44:01 inf-fw2 kernel: Shorewall:dmz0-fw:REJECT:IN=br0 OUT= PHYSIN=enp8s5 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=32313 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=7891 Nov 13 11:44:02 inf-fw2 kernel: Shorewall:dmz0-fw:REJECT:IN=br0 OUT= PHYSIN=enp8s5 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=32314 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=7892 Nov 13 11:44:03 inf-fw2 kernel: Shorewall:dmz0-fw:REJECT:IN=br0 OUT= PHYSIN=enp8s5 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=32315 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=7893 Nov 13 11:44:04 inf-fw2 kernel: Shorewall:dmz0-fw:REJECT:IN=br0 OUT= PHYSIN=enp8s5 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=32316 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=7894 Nov 13 11:44:05 inf-fw2 kernel: Shorewall:dmz0-fw:REJECT:IN=br0 OUT= PHYSIN=enp8s5 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=32318 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=7895 Nov 13 11:44:06 inf-fw2 kernel: Shorewall:dmz0-fw:REJECT:IN=br0 OUT= PHYSIN=enp8s5 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=32319 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=7896 Nov 13 11:44:07 inf-fw2 kernel: Shorewall:dmz0-fw:REJECT:IN=br0 OUT= PHYSIN=enp8s5 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=32320 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=7897 Nov 13 11:44:08 inf-fw2 kernel: Shorewall:dmz0-fw:REJECT:IN=br0 OUT= PHYSIN=enp8s5 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=32321 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=7898 Nov 13 11:44:09 inf-fw2 kernel: Shorewall:dmz0-fw:REJECT:IN=br0 OUT= PHYSIN=enp8s5 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=32326 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=7899 Nov 13 11:44:10 inf-fw2 kernel: Shorewall:dmz0-fw:REJECT:IN=br0 OUT= PHYSIN=enp8s5 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=32329 PROT
Re: [Shorewall-users] shorewall VLANs and network ranges
On Thu, Nov 8, 2018 at 5:49 PM Tom Eastep wrote: > > I was also trying to configure a bridge, > > There is *nothing* unique about VLAN interfaces, as far as Shorewall is > concerned. Treat them just as you would non-VLAN ethernet devices. OK, so I went for a bridge config. It seems to be working as I expect it to. However, there's one case where things don't seem to add up. The switch the Shorewall firewall is connecting to has: ports 1-10,13-44 Untagged VLAN 1 ports 45-48 Tagged VLAN 1 + Tagged VLAN 11 + TAGGED VLAN 12 port 11 Untagged VLAN 1 port 12 Untagged VLAN 12 When I connect the Shorewall Firewall to any one of the ports 45-48, it seems that my Shorewall rules/policy are as I expect them to be. However, if I connect my Shorewall interface to any one of the ports 1-10,13-44, I am expecting to REJECT packets according to my policy here below (last line): dmz11 lan ACCEPT info dmz11 $FW ACCEPT info dmz1lan ACCEPT info dmz1$FW ACCEPT info dmz0lan REJECT info dmz0$FW REJECT info Here's the shorewall dump when I try to ping $FW (192.168.215.1) from a host in "dmz0" with IP address 192.168.215.200: https://drive.google.com/open?id=1ldm7DZvTEgaMqtt7Rt_PydWGd-XcSwWd The dmz0 host gets ICMP replies from the Firewall. Why? How can I properly reject this traffic? On the Shorewall system I can see the following: # tcpdump -n -i enp8s5 host 192.168.215.200 dropped privs to tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on enp8s5, link-type EN10MB (Ethernet), capture size 262144 bytes 11:25:44.376991 IP 192.168.215.200 > 192.168.215.1: ICMP echo request, id 1, seq 7163, length 40 11:25:44.377038 IP 192.168.215.1 > 192.168.215.200: ICMP echo reply, id 1, seq 7163, length 40 11:25:45.394745 IP 192.168.215.200 > 192.168.215.1: ICMP echo request, id 1, seq 7164, length 40 11:25:45.394805 IP 192.168.215.1 > 192.168.215.200: ICMP echo reply, id 1, seq 7164, length 40 11:25:46.410132 IP 192.168.215.200 > 192.168.215.1: ICMP echo request, id 1, seq 7165, length 40 11:25:46.410172 IP 192.168.215.1 > 192.168.215.200: ICMP echo reply, id 1, seq 7165, length 40 ^C 6 packets captured 6 packets received by filter 0 packets dropped by kernel # tcpdump -n -i enp8s5_1 host 192.168.215.200 dropped privs to tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on enp8s5_1, link-type EN10MB (Ethernet), capture size 262144 bytes ^C 0 packets captured 0 packets received by filter 0 packets dropped by kernel # tcpdump -n -i enp8s5_11 host 192.168.215.200 dropped privs to tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on enp8s5_11, link-type EN10MB (Ethernet), capture size 262144 bytes ^C 0 packets captured 0 packets received by filter 0 packets dropped by kernel Any ideas? Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall VLANs and network ranges
On 11/8/18 4:56 AM, Vieri Di Paola wrote: > Hi, > > I'd like to describe my goal here to see if someone can guide me to > the "best solution". > > A Shorewall server has several ethernet interfaces, and one of them > (say, eth0) is configured with VLAN IDs 1, 11, 12 (eth0.1, eth0.11, > eth0.12). > > So eth0 is then connected to a "trunk" port on a managed switch > (untagged VLAN 1, tagged VLAN 11, tagged VLAN 12). > > The eth0 IP addr. configuration on the Shorewall system is something > like 192.168.210.1/24, and the hosts in this LAN segment are within > this IP addr. range with static IP addresses. > It is REQUIRED that all hosts in this network have IP addresses within > this range, and that the Shorewall server use the least IP addresses > as possible (ie. 1). > > As a simplified practical example, suppose I have the following: > > - 1 host in VLAN 11 with IP address 192.168.210.10/24, default gw > 192.168.210.1 > - 2 hosts in VLAN 1 with IP addresses 192.168.210.20-21/24, default gw > 192.168.210.1 > - 1 host in VLAN 12 with IP address 192.168.210.30/24, default gw > 192.168.210.1 > > I need Shorewall to manage traffic between these VLANs > (allow/drop/reject...). eg. I want only $FW to access VLAN 1 hosts, > VLAN 11 hosts can access specific ports on $FW only, VLAN 12 hosts can > access selected ports on VLAN 1 hosts. > > The usual way to configure VLANs is to use non-overlapping IP ranges > for each virtual interface. > However, I cannot do that here. > > I was thinking of using "parallel zones", but I'm not sure that would > work (I cannot specify eth0.1, eth0.11 or eth0.12 in the Shorewall > Interfaces file). Of course you can!!! > > I was also trying to configure a bridge, but I don't know if and how I > can bridge a VLAN with the interface, and then set Shorewall > BPORT-based rules. > Something like bridging eth0.1, eth0.11 and eth0.12, setting a > management IP address 192.168.210.1/24, and then defining bridge zones > and BPORT rules. > > Can anyone please give me some hints and pointers? > There is *nothing* unique about VLAN interfaces, as far as Shorewall is concerned. Treat them just as you would non-VLAN ethernet devices. -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
[Shorewall-users] shorewall VLANs and network ranges
Hi, I'd like to describe my goal here to see if someone can guide me to the "best solution". A Shorewall server has several ethernet interfaces, and one of them (say, eth0) is configured with VLAN IDs 1, 11, 12 (eth0.1, eth0.11, eth0.12). So eth0 is then connected to a "trunk" port on a managed switch (untagged VLAN 1, tagged VLAN 11, tagged VLAN 12). The eth0 IP addr. configuration on the Shorewall system is something like 192.168.210.1/24, and the hosts in this LAN segment are within this IP addr. range with static IP addresses. It is REQUIRED that all hosts in this network have IP addresses within this range, and that the Shorewall server use the least IP addresses as possible (ie. 1). As a simplified practical example, suppose I have the following: - 1 host in VLAN 11 with IP address 192.168.210.10/24, default gw 192.168.210.1 - 2 hosts in VLAN 1 with IP addresses 192.168.210.20-21/24, default gw 192.168.210.1 - 1 host in VLAN 12 with IP address 192.168.210.30/24, default gw 192.168.210.1 I need Shorewall to manage traffic between these VLANs (allow/drop/reject...). eg. I want only $FW to access VLAN 1 hosts, VLAN 11 hosts can access specific ports on $FW only, VLAN 12 hosts can access selected ports on VLAN 1 hosts. The usual way to configure VLANs is to use non-overlapping IP ranges for each virtual interface. However, I cannot do that here. I was thinking of using "parallel zones", but I'm not sure that would work (I cannot specify eth0.1, eth0.11 or eth0.12 in the Shorewall Interfaces file). I was also trying to configure a bridge, but I don't know if and how I can bridge a VLAN with the interface, and then set Shorewall BPORT-based rules. Something like bridging eth0.1, eth0.11 and eth0.12, setting a management IP address 192.168.210.1/24, and then defining bridge zones and BPORT rules. Can anyone please give me some hints and pointers? Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
