[Shorewall-users] route rules
Hi, My question isn't really shorewall-specific, but I thought it could be of interest to the mailing list. I use shorewall's rtrules file to route to different providers. I also do the same on the command line with: ip rule del pref 11400 ip rule add pref 11400 from 10.215.144.7 to 10.0.0.0/8 lookup PROVIDER1 ip route flush cache then I run the following to remove a route rule: ip rule del pref 11400 ip route flush cache The problem I'm seeing is the following: a) on a Linux host with IP addr. 10.215.144.7 a command such as "tracepath 10.1.2.3" works *immediately* as expected in both of the cases described above b) on a Windows machine with IP addr. 10.215.144.7 a command such as "tracert -d 10.1.2.3" works *sometimes* immediately, but at times I need to wait at least 20 seconds or so. On occasions I might also need to wait almost a full minute. On the Shorewall gateway/router I do *nothing* after the last "ip route flush cache" command. Why are these clients behaving differently? As I said before, Linux clients always behave as expected so there must be something I'm unaware of on other systems. Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] DNAT, ACCEPT, ADD in rules
On Tuesday, October 16, 2018, 5:24:41 PM GMT+2, Tom Eastep wrote: >>> ADD(POL_BL:src):info:polbl,add2polbl net1,net2,net3:!+POL_BL,+GLOBAL_WL >>> all tcp,udp - !443,80,25,3389 > > Because you are excluding SOURCE ports, not DESTINATION ports... Absolutely right. Thanks for seeing that! Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] DNAT, ACCEPT, ADD in rules
On Tuesday, October 16, 2018, 12:08:35 AM GMT+2, Vieri Di Paola via Shorewall-users wrote: >>> DNAT net2:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL loc:10.215.145.81 >>> tcp 80,443 - - 30/min:35 >>> [...] >>> ADD(POL_BL:src):info:polbl,add2polbl net1,net2,net3:!+POL_BL,+GLOBAL_WL >>> all tcp,udp - !443,80,25,3389 >> >> >> If the connection rate to ports 80 and 443 from the net exceeds the >> LIMIT on the DNAT rule, then those connections exceeding the rate will >> be added to the ipset. > > Interesting. So, if I want to make sure the SRC IP addr. is not added to my > POL_BL ipset then I should either remove rate limiting or use something else > in between. Come to think of it, I don't understand why the connections exceeding the rate will be added to the ipset if the ADD() action excludes dst ports 80 and 443 (!443,80). Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] DNAT, ACCEPT, ADD in rules
On Monday, October 15, 2018, 5:22:59 PM GMT+2, Tom Eastep wrote: >> >> DNAT net2:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL loc:10.215.145.81 >> tcp 80,443 - - 30/min:35 >> [...] >> ADD(POL_BL:src):info:polbl,add2polbl net1,net2,net3:!+POL_BL,+GLOBAL_WL >> all tcp,udp - !443,80,25,3389 > > > If the connection rate to ports 80 and 443 from the net exceeds the > LIMIT on the DNAT rule, then those connections exceeding the rate will > be added to the ipset. Interesting. So, if I want to make sure the SRC IP addr. is not added to my POL_BL ipset then I should either remove rate limiting or use something else in between. What about the following ruleset? DNAT net2:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL loc:10.215.145.81 tcp 80,443 - - 30/min:35 TARPIT(tarpit):info:polbl,limit net2 $FW tcp 80,443 [...] ADD(POL_BL:src):info:polbl,add2polbl net1,net2,net3:!+POL_BL,+GLOBAL_WL all tcp,udp - !443,80,25,3389 Or maybe just use the DROP action instead of TARPIT. So, I understand that those connections that exceed the rate limit will either be DROP'ped or TARPIT'ted but not ADD'ed to the ipset, right? Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] DNAT, ACCEPT, ADD in rules
Hi, I have the following in my rules file: DNAT net2:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL loc:10.215.145.81 tcp 80,443 - - 30/min:35 [...] ADD(POL_BL:src):info:polbl,add2polbl net1,net2,net3:!+POL_BL,+GLOBAL_WL all tcp,udp - !443,80,25,3389 Suppose host at x.x.x.x tries to access via port 80 through shorewall, I understand the connection should have been DNAT'ed, right? In no case should it had been added to the POL_BL ipset, right? However, in shorewall's log I can see the following line: Oct 15 10:48:09 Shorewall:polbl:add2polbl:IN=ppp2 OUT= MAC= SRC=x.x.x.x DST=y.y.y.y LEN=52 TOS=0x00 PREC=0x00 TTL=116 ID=13247 DF PROTO=TCP SPT=52576 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0 MARK=0x2 Any clues? Do you need a dump? Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall multi-isp snat with 3 ppp interfaces
Actually, this would be enough, and it would also be easily parseable: # shorewall reload FATAL ERROR: found another process with PID $PID ... and the exit code would be non-zero. Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall multi-isp snat with 3 ppp interfaces
On Wednesday, October 10, 2018, 12:23:20 PM GMT+2, Vieri Di Paola via Shorewall-users wrote: > > So in the end, the guilty party seems to be the pppd daemon, or the way I > configure it. > > A simple solution would be to run "shorewall reload" within an ip-up.d > script. However, I'm not sure how to do this automatically if the ppp > "persist" option doesn't work in my setup (or at least not when I reboot my > modems). Anyway, it's not a shorewall issue anymore. Just in case someone else has the same issue, here's a "solution/hack". First of all, you should specify both lcp-echo-interval and lcp-echo-failure in the ppp options, along with "persist" and "maxfail 0". Personally, I have the following: pppd_ppp3="noauth persist holdoff 3 maxfail 0 child-timeout 60 lcp-echo-interval 15 lcp-echo-failure 3 noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp " So now, each time my modem reboots, pppd detects link failure due to LCP reply errors. Still, you need to tell shorewall to reload. I'm doing it with a ppp "up" script. Basically, I have a custom script in /etc/ppp/ip-up.d which calls "shorewall reload". I've noticed that sometimes shorewall "hangs" when there's another shorewall process running (eg. fired up by a cron job, a monitoring script, another admin user, or whatever). Sure, I could change my ip-up.d script as well as all the other scripts to first check if shorewall is already running before executing "shorewall reload", but I can't be sure an admin user will do so if logged in via ssh and running it manually. Is there a config option in Shorewall to tell it to exit immediately if it finds another running process? Something like: # shorewall reload FATAL ERROR: found at least another process. PID1 PID2 PID3 ... and the exit code would be non-zero. Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall multi-isp snat with 3 ppp interfaces
On Tuesday, October 9, 2018, 11:23:40 PM GMT+2, Tom Eastep wrote: > > * If the modem is rebooted, things don't work until the ppp script is run. > * If the ppp script is run, routing is changed behind Shorewall's back > so that, at least in some cases, only a 'reload' can put things back > together again. Thanks for your help, Tom. So in the end, the guilty party seems to be the pppd daemon, or the way I configure it. A simple solution would be to run "shorewall reload" within an ip-up.d script. However, I'm not sure how to do this automatically if the ppp "persist" option doesn't work in my setup (or at least not when I reboot my modems). Anyway, it's not a shorewall issue anymore. Thanks again, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall multi-isp snat with 3 ppp interfaces
On Tuesday, October 9, 2018, 11:12:32 AM GMT+2, Vieri Di Paola via Shorewall-users wrote: > > Still don't quite get why I'm getting the "Network is unreachable" message > before reenabling in the last test. I forgot to add this info: --- routing_after_ppp3_restart 2018-10-09 10:58:34.035935264 +0200 +++ routing_after_ppp3_restart_and_sw_reenable 2018-10-09 11:19:17.626697503 +0200 @@ -1,4 +1,4 @@ -Shorewall 5.2.0.5 Routing at inf-gw1 - Tue Oct 9 10:58:34 CEST 2018 +Shorewall 5.2.0.5 Routing at inf-gw1 - Tue Oct 9 11:19:17 CEST 2018 Routing Rules @@ -24,9 +24,11 @@ Table ISP3: +default dev ppp3 scope link Table balance: +default dev ppp3 Table default: ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall multi-isp snat with 3 ppp interfaces
On Monday, October 8, 2018, 7:30:45 PM GMT+2, Tom Eastep
wrote:
>
> default via 192.168.144.1 dev ppp3 metric 4009
>
> 'reenable' does not delete that route, but 'restart' and 'reload' do
> delete the route.
>
> This issue will be corrected by omitting 'defaultroute' from your
> ppp configuration.
I removed that option. Now my ppp options are as follows:
noauth
persist
holdoff 0
maxfail 0
noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp
Restarting both the ppp links and shorewall works as expected (this contradicts
one of my previous findings that I required the default route, but at this
point it's better to just look forward).
So let's move on to the test. Just to make things a tad more exciting, I found
out that my pppoe links do not re-sync at all after rebooting my modems, ie.,
nothing in syslog indicates that pppd has tried to reconnect to my providers. I
don't know if it's due to the "UNKNOWN state" of all my ppp links, or if I'm
not setting up my ppp options appropriately. In any case, I am required to
manually restart my ppp script each time I reboot a modem... So here's the
script I ran today:
ping -c 5 -n -I ppp3 8.8.8.8
shorewall show routing > routing0
echo "Reboot modem (ISP3), and wait until it's back up again (check ppp ip-up.d
script), then press ENTER"
read
shorewall show routing > routing1
shorewall disable ppp3
shorewall show routing > routing2
shorewall enable ppp3
shorewall show routing > routing3
ping -c 5 -n -I ppp3 8.8.8.8
echo "Press ENTER if ping fails"
read
shorewall reload
ping -c 5 -n -I ppp3 8.8.8.8
shorewall show routing > routing4
echo "Press ENTER if ping fails again"
read
/etc/init.d/net.ppp3 restart
echo "Check ppp ip-up.d script and press ENTER"
read
shorewall show routing > routing1b
shorewall disable ppp3
shorewall show routing > routing2b
shorewall enable ppp3
shorewall show routing > routing3b
ping -c 5 -n -I ppp3 8.8.8.8
echo "Press ENTER if ping fails"
read
shorewall reload
ping -c 5 -n -I ppp3 8.8.8.8
shorewall show routing > routing4b
The ping test above starts working ONLY after the last shorewall reload -- so
routing4b is the working config (routing0 too, of course).
In the link below you will find the routing* files and a custom ppp ip-up.d
script (99-custom.sh) with the related output in ppp_up_data which was obtained
only after restarting the net.ppp3 init script.
https://drive.google.com/open?id=1Ly445Qzx9RXICMeC5UdQ9YK5Hcgywtf2
The only difference between the dump after reenabling ppp3 (routing3b) and
reloading shorewall (routing4b) is:
-default dev ppp3
+default nexthop dev ppp1 weight 1 nexthop dev ppp2 weight 1 nexthop dev ppp3
weight 1
Just one last test... I decided to restart the ppp3 init script without
rebooting the modem or restarting shorewall.
# ping -n -I ppp3 8.8.8.8
64 bytes from 8.8.8.8: icmp_seq=1 ttl=121 time=14.0 ms
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
^C
Please find the routing data here:
https://drive.google.com/open?id=1K8DB5Xs05MuMG1botQ3htLlsh3MrPB4F
In this case "shorewall reenable ppp3" DOES restore proper traffic through
ppp3.
Please note that when I reboot the modem the local public ppp-assigned IP
address may have changed. It was the case in my routing{1-4}{,b} test above,
but not in this one.
Still don't quite get why I'm getting the "Network is unreachable" message
before reenabling in the last test.
Vieri
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall multi-isp snat with 3 ppp interfaces
On Friday, October 5, 2018, 6:42:46 PM GMT+2, Tom Eastep wrote: >> >> However, all 3 providers are up and running, ie., I can successfully ping to >> a remote host through their interfaces. >> I need to manually run "shorewall enable INTERFACE" and restart shorewall. >> No issues from this point onwards. >> So why is Shorewall complaining about the interfaces? How does it decide if >> it's "usable"? > > You can read the code for yourself. It is contained in the shell > function interface_is_usable(). Note that with the standard > /etc/shorewall/isusable script, once a persistent interface is > determined to be unusable, the only way to make it usable again is to > use the 'enable' (or reenable) command. By the way, here's what I've noticed: # ip -4 link list dev ppp3 11: ppp3: mtu 1492 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 3 link/ppp # ip -4 link list dev ppp2 8: ppp2: mtu 1492 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 3 link/ppp # ip -4 link list dev ppp1 7: ppp1: mtu 1492 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 3 link/ppp The "state" is UNKNOWN instead of UP, but the links are "really up"... Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall multi-isp snat with 3 ppp interfaces
On Friday, October 5, 2018, 6:51:04 PM GMT+2, Tom Eastep wrote: >> >> Finally, a shorewall restart (full stop and start) actually DID solve the >> issue. I magically got my ppp3 link working again. >> So, of course, I'm worried that if there's a power outage or if someone >> reboots the modems then the gateway might get cut off from the Internet if >> shorewall doesn't restart. > > I can't comment without seeing the difference between the ruleset after '> reenable' and the ruleset after 'restart'. Here's the dump after "reenable ppp3" (no traffic through provider): https://drive.google.com/open?id=13MOhqHX7Im6uu8khr5DQTNuMypxQG8U3 And here's the dump after "restart" (traffic OK through provider): https://drive.google.com/open?id=1GKOjtcEzc8H7JLI1V7hgPwMe3n6ECiXg >>> 10003: enp6s0: mtu 1500 qdisc tbf state >>> UP group default qlen >> 3: enp6s0: mtu 1500 qdisc fq_codel state >> UP group default qlen 1000 >> I still don't know why some interfaces are set to use pfifo_fast, or if it's >> recommended or not for a gateway/router. > > Which has nothing to do with Shorewall... OK, I was just asking because the tbf qdisc is set by Shorewall when enabling traffic shaping. Also , /usr/share/shorewall/Shorewall/Tc.pm seems to deal with fq_codel, and there's documentation referencing fq_codel here: http://shorewall.net/manpages4/manpages/shorewall-tcclasses.html http://shorewall.org/traffic_shaping.htm Anyway, I'll study that later on if time permits. Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall multi-isp snat with 3 ppp interfaces
I finally got it working, but I still have a few doubts (see below). On Thursday, October 4, 2018, 12:25:05 PM GMT+2, Vieri Di Paola via Shorewall-users wrote: > > If I were to move to my 3-ppp setup, I guess I would need to specify the ppp > option "defaultroute" for each ppp interface, right? Setting up the "defaultroute" option on all three ppp interfaces did the trick. > Also, when starting or restarting shorewall for the first time, I get this > message: > WARNING: Interface enp7s0 is not usable -- Provider ISP1 (1) not Started > (same thing for the other 2 providers) > This also happened when I used the pppoe links instead of ethernet. > However, all 3 providers are up and running, ie., I can successfully ping to > a remote host through their interfaces. > I need to manually run "shorewall enable INTERFACE" and restart shorewall. No > issues from this point onwards. > So why is Shorewall complaining about the interfaces? How does it decide if > it's "usable"? This can still happen, but it's not always reproducible. However, there's one more awkward situation I've noticed today. In my fully working 3-pppoe gateway setup, I decided to physically shut down one of my 3 provider modems and boot it back up again to see what happened (say, ppp3). I was unable to access Internet via ppp3 even after a long while (to allow it to sync). My ppp options are as follows: noauth defaultroute persist holdoff 0 maxfail 0 noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp I still haven't found the time to fully check what went wrong, but here's what I did to bring the link back up: First, I manually restarted the ppp3 interface and waited for full sync. I checked the logs and confirmed that it was all up and running (authenticated, etc.). However, I still didn't have connectivity through this pppoe link. I then issued "shorewall reenable ppp3", and SW reported that it had first "stopped" the ppp3 provider and then "started" it (which means that shorewall didn't automatically disable it while the modem was rebooting). I still had no connectivity through this pppoe link. Finally, a shorewall restart (full stop and start) actually DID solve the issue. I magically got my ppp3 link working again. So, of course, I'm worried that if there's a power outage or if someone reboots the modems then the gateway might get cut off from the Internet if shorewall doesn't restart. > I have the following: > # sysctl net.core.default_qdisc > net.core.default_qdisc = fq_codel > # sysctl net.ipv4.tcp_congestion_control > net.ipv4.tcp_congestion_control = cdg > # ip addr show | grep qdisc > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group > default qlen > 10002: enp5s0: mtu 1500 qdisc pfifo_fast > state UP group default qlen > 10003: enp6s0: mtu 1500 qdisc tbf state UP > group default qlen > 10004: enp7s0: mtu 1500 qdisc tbf state UP > group default qlen > 10005: enp8s5: mtu 1500 qdisc tbf state UP > group default qlen > 10006: enp10s0: mtu 1500 qdisc pfifo_fast > state UP group default qlen 1000 > Why do I see pfifo_fast and tbf instead of fq_codel? OK, I think I got this one. I had TC_ENABLED=Simple. Disabling it activates fq_codel on all "outer interfaces", but not on the "inner" eth interfaces. # ip addr show | grep qdisc 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 2: enp5s0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 3: enp6s0: mtu 1500 qdisc fq_codel state UP group default qlen 1000 4: enp7s0: mtu 1500 qdisc fq_codel state UP group default qlen 1000 5: enp8s5: mtu 1500 qdisc fq_codel state UP group default qlen 1000 6: enp10s0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 7: ppp1: mtu 1492 qdisc fq_codel state UNKNOWN group default qlen 3 8: ppp2: mtu 1492 qdisc fq_codel state UNKNOWN group default qlen 3 10: ppp3: mtu 1492 qdisc fq_codel state UNKNOWN group default qlen 3 I still don't know why some interfaces are set to use pfifo_fast, or if it's recommended or not for a gateway/router. Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall multi-isp snat with 3 ppp interfaces
On Wednesday, October 3, 2018, 11:55:30 PM GMT+2, Tom Eastep wrote: > > Looks to me like an issue with whatever program you are runninq to > service NFQUEUE... Please note that I have the "bypass" option set for NFQUEUE. In any case, I removed NFQUEUE from my Shorewall configuration to see if it had any effect, but it didn't. I still witnessed the same behavior. So it occurred to me that it could be a basic routing issue. Now, I don't know how everything got fixed, but it did. Here's exactly what I did after reenabling NFQUEUE in my shorewall config: I set up my OS to add default gw entries for each interface linked to my providers (3). So, for enp7s0 I set "default gw 192.168.92.1", for enp6s0 "default gw 192.168.100.1", for enp8s5 "default gw 192.168.101.1". After restarting shorewall, lo and behold, everything was working again. What puzzles me is that the only 2 differences with my old failing setup (the one which I already sent a dump file for) are: 1) previously I only had one default gw for enp8s5 "192.168.101.1" 2) I had an older shorewall version (5.1.11.1) So I still haven't figured out why it "worked before" with an older shorewall, but not afterwards. I posted another shorewall dump below to see if it can be compared with the one posted yesterday: This dump was taken when traffic was not working properly: https://drive.google.com/open?id=1swkElhpnoUenHP_oBAzhvv4edGxmYtm3 This other dump was taken today with everything working fine: https://drive.google.com/open?id=13hGLyHAISIawJIWc5YYhNVzXn_Hj4Qy6 It's not really important at this point, but it would be nice to know what went wrong just so I don't fall into the same trap in the future. I still have a few questions though before I start fiddling again with my system. If I were to move to my 3-ppp setup, I guess I would need to specify the ppp option "defaultroute" for each ppp interface, right? Also, when starting or restarting shorewall for the first time, I get this message: WARNING: Interface enp7s0 is not usable -- Provider ISP1 (1) not Started (same thing for the other 2 providers) This also happened when I used the pppoe links instead of ethernet. However, all 3 providers are up and running, ie., I can successfully ping to a remote host through their interfaces. I need to manually run "shorewall enable INTERFACE" and restart shorewall. No issues from this point onwards. So why is Shorewall complaining about the interfaces? How does it decide if it's "usable"? Finally, my last question is broader and doesn't really depend on shorewall. I have the following: # sysctl net.core.default_qdisc net.core.default_qdisc = fq_codel # sysctl net.ipv4.tcp_congestion_control net.ipv4.tcp_congestion_control = cdg # ip addr show | grep qdisc1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 10002: enp5s0: mtu 1500 qdisc pfifo_fast state UP group default qlen 10003: enp6s0: mtu 1500 qdisc tbf state UP group default qlen 10004: enp7s0: mtu 1500 qdisc tbf state UP group default qlen 10005: enp8s5: mtu 1500 qdisc tbf state UP group default qlen 10006: enp10s0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 Why do I see pfifo_fast and tbf instead of fq_codel? Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall multi-isp snat with 3 ppp interfaces
I finally managed to reconnect to my shorewall gateway. Here are two dump files: The 3 ISPs are accessed via 3 pppoe links, and I'm trying to ping a remote host on any one of these links with something like: # ping -n -I ppp1 8.8.8.8 First ICMP request is succesfully replied. Subsequent requests fail to get a reply. I can repeat the test as may times as I want. Only the first piong request gets a reply. https://drive.google.com/open?id=1gGD6AQuN15VeC-KD_cPi8pn1b6kcVNja The second dump was taken after I restored my eth-only setup to access my 3 providers (no pppoe links). That's when I set CLAMPMSS back to No. I was still getting the same awkward ping results (ie. first request/reply OK, subsequent fail). https://drive.google.com/open?id=1swkElhpnoUenHP_oBAzhvv4edGxmYtm3 In the case of course I was doing something like this on the gateway: # ping -n -I enpxsy 8.8.8.8 Any thoughts? Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall multi-isp snat with 3 ppp interfaces
On Tuesday, October 2, 2018, 4:46:34 PM GMT+2, Tom Eastep wrote: > > As I pointed out in my response to your later post, those rules won't > make any difference even if correct code was generated. What I suspect > is that you are running into a PMTU problem that will be corrected if > you set CLAMPMSS=Yes in shorewall.conf. You have switched from using > Ethernet interfaces to your ISPs to PPPoE interfaces which have an MTU > of 1492 versus 1500 for Ethernet. I thought it could be due to PMTU, so I followed your suggestion and set CLAMPMSS=Yes. After restarting shorewall the following command would get only 1 packet reply (the first one). Everything else would be left unanswered. ping -n -I $IF_ISP1 8.8.8.8 (run on the shorewall gateway) So I also tried to set CLAMPMSS=4012 or whichever value I had in the ppp links. I would still get the same ping results. Also, if I did a "shorewall clear" the same ping tests would succeed. I did a shorewall dump during these tests. Unfortunately, I got cut off later so I can't access the dump file just yet. I'll send it asap. I finally tried to revert to my eth-only setup, moved back to CLAMPMSS=No. However, I'd still get the same erroneous ping results even after rebooting the shorewall gateway. I still have to find out how to undo what CLAMPMSS=Yes did. Anyway, I'll send the dump asap. Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall multi-isp snat with 3 ppp interfaces
On Monday, October 1, 2018, 5:50:59 PM GMT+2, Tom Eastep wrote: > For this type of error, I really need to see the .start file itself. I'll copy the .start file ASAP. In the meantime, I removed the following lines from the snat file: SNAT($IF_ISP3_IP) $IF_LAN $IF_ISP3 SNAT($IF_ISP2_IP) $IF_LAN $IF_ISP2 SNAT($IF_ISP1_IP) $IF_LAN $IF_ISP1 SNAT($IF_ISP3_IP) $IF_DMZ $IF_ISP3 SNAT($IF_ISP2_IP) $IF_DMZ $IF_ISP2 SNAT($IF_ISP1_IP) $IF_DMZ $IF_ISP1 I don't get any errors, and I see that most traffic is working as expected. However, there are some issues. For instance, I'm trying to access 87.248.114.11 on port 443 from LAN host with IP addr. 10.215.144.48. I can see the traffic going out and in through ppp2, but the browser client in the LAN host cannot view the data (it seems to try to receive data all the time). Other sites work fine. I tested the failing site with other means at the same time and several times. It always "works". So there's something wrong with the way I configured shorewall. Here's the shorewall dump while making the connection: https://drive.google.com/file/d/1R0smnmOIL_RthEQtcAp79zWMklu8MAaM/view?usp=sharing Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] shorewall multi-isp snat with 3 ppp interfaces
Hi, I'm having trouble with my new multi-ISP setup with 3 pppoe links to my internet providers. I have no previous knowledge of the IP addresses the providers will assign nor the gateway I should use. It's automatically configured when dialing in with ppp. So in my shorewall config I have the following: # cat params IF_LAN=enp10s0 IF_DMZ=enp5s0 IF_ISP1=ppp1 IF_ISP2=ppp2 IF_ISP3=ppp3 IF_ISP1_IP=detect IF_ISP2_IP=detect IF_ISP3_IP=detect IF_ISP1_GW=- IF_ISP2_GW=- IF_ISP3_GW=- IF_LAN_MASQ_ADDRESS=10.215.144.92 IF_LAN_MASQ_SOURCE=172.16.0.2 Now, the trouble I have is trying to set up masquerading. If this is the content of my snat file: SNAT($IF_ISP3_IP) 0.0.0.0/0 $IF_ISP3 SNAT($IF_ISP2_IP) 0.0.0.0/0 $IF_ISP2 SNAT($IF_ISP1_IP) 0.0.0.0/0 $IF_ISP1 SNAT($IF_ISP3_IP) $IF_LAN $IF_ISP3 SNAT($IF_ISP2_IP) $IF_LAN $IF_ISP2 SNAT($IF_ISP1_IP) $IF_LAN $IF_ISP1 SNAT($IF_ISP3_IP) $IF_DMZ $IF_ISP3 SNAT($IF_ISP2_IP) $IF_DMZ $IF_ISP2 SNAT($IF_ISP1_IP) $IF_DMZ $IF_ISP1 SNAT($IF_LAN_MASQ_ADDRESS) $IF_LAN_MASQ_SOURCE $IF_LAN then this is shorewall's error message at startup: /var/lib/shorewall/.start: line 3126: syntax error near unexpected token `fi' /var/lib/shorewall/.start: line 3126: ` fi' * ERROR: shorewall failed to start The .start script seems to have an empty "if" clause, hence the error. # cat providers ISP1 1 1 - $IF_ISP1 $IF_ISP1_GW track,balance=3,persistent ISP2 2 2 - $IF_ISP2 $IF_ISP2_GW track,balance=2,persistent ISP3 3 3 - $IF_ISP3 $IF_ISP3_GW track,balance=1,persistent I'm sorry I couldn't grab all the info required as described in http://shorewall.org/support.htm, but I had to put the system back up in production with another configuration. As soon as I can I will try to get a trace. In the meantime, maybe someone here can already suggest I try something as it must surely be a dumb configuration error on my behalf. Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Packet loss when changing mangle rule
Hi, I've tried fiddling around with the following parameters, but it seems to make no difference: net.core.default_qdisc = pfifo_fast net.ipv4.tcp_congestion_control = cubic net.ipv4.tcp_available_congestion_control = cubic reno bbr cdg The above values are default in my system. I tried the following: # sysctl -w net.core.default_qdisc=fq_codel # sysctl -w net.ipv4.tcp_congestion_control=cdg I restarted shorewall, but not the OS. I'm still seeing the same packet loss behavior after a while. Can anyone with more experience please tell me if I should revert to defaults (qdisc, congestion control) for "shorewall router" purposes. I mean that maybe fq_codel and cdg "won't hurt" as they seem to be unrelated to my packet loss issue. Thanks, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Packet loss when changing mangle rule
On Wednesday, August 15, 2018, 12:40:29 AM GMT+2, Tom Eastep
wrote:
> The only thing that I see is heavy upload traffic to port 80 at IP
> address 31.216.144.11.
>
> There are no ARP packets in the entire pcap file, so it isn't a problem
> of the upstream router not being able to determine the L2 address of
> your gateway. Given that the echo-request packets are being sent, that
> is about the only thing that your gateway could be involved in that
> would result in dropped incoming echo-reply packets.
>
> There are also some retransmissions of TCP packets going on, but that
> isn't all that unusual.
>
> I think that the next step I would take would be to pick a destination
> "closer" to your gateway; use 'traceroute' to determine the IP address
> of the router that is a couple of hops from your gateway and ping that.
> If you don't see packet loss in those pings, then the problem is likely
> beyond that router.
Thanks for helping out.
I noticed that whichever interface I use to run "traceroute" (enp9s4 for ISP1,
enp9s5 for ISP2, enp9s6 for ISP3) I always get an unknown and unpingable
private IP address at hop #2 (192.168.144.1):
# traceroute -n -i enp9s6 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 192.168.101.1 0.378 ms 0.521 ms 0.657 ms
2 192.168.144.1 5.366 ms 5.435 ms 5.437 ms
[...]
The modem/router's LAN IPv4 address is 192.168.101.1, and is pingable from the
Shorewall gateway.
I checked the modem/router's configuration for anything related to
192.168.144.*, but found nothing.
I ran this on the gateway:
# nmap -vv -Pn -e enp9s6 192.168.144.1
Starting Nmap 7.40 ( https://nmap.org ) at 2018-08-16 09:02 CEST
Initiating Parallel DNS resolution of 1 host. at 09:02
Completed Parallel DNS resolution of 1 host. at 09:02, 13.04s elapsed
Initiating SYN Stealth Scan at 09:02
Scanning 192.168.144.1 [1000 ports]
SYN Stealth Scan Timing: About 15.45% done; ETC: 09:05 (0:02:50 remaining)
SYN Stealth Scan Timing: About 30.00% done; ETC: 09:05 (0:02:22 remaining)
SYN Stealth Scan Timing: About 44.55% done; ETC: 09:05 (0:01:53 remaining)
SYN Stealth Scan Timing: About 59.55% done; ETC: 09:05 (0:01:22 remaining)
SYN Stealth Scan Timing: About 74.65% done; ETC: 09:05 (0:00:51 remaining)
Completed SYN Stealth Scan at 09:05, 202.83s elapsed (1000 total ports)
Nmap scan report for 192.168.144.1
Host is up, received user-set.
All 1000 scanned ports on 192.168.144.1 are filtered because of 1000
no-responses
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 216.03 seconds
Raw packets sent: 2000 (88.000KB) | Rcvd: 2 (484B)
Anyway, the hops after the second one are usually different when I run
"traceroute" several times.
For instance, if I run "traceroute -n -i enp9s6 www.shorewall.net" several
times I get different IP addresses from hop #3 onwards until I reach
63.135.54.24.
Same thing for www.fltk.org or www.gentoo.org. Somehow, whenever I run
"traceroute -n -i enp9s6 8.8.8.8" I always get the same IP addresses at least
for hops #3 and #4 (out of a total of 10). In any case, none of these hosts
with these IP addresses reply to ping requests ("ping -n -I enp9s6
HOP_IP_ADDR"). In other words, when trying to access Google's primary DNS
server at 8.8.8.8, the only pingable IP addresses in the path are 8.8.8.8
itself and the modem/router's LAN IP addr. at 192.168.101.1.
I guess I need to ask my ISP to allow ICMP traffic for these intermediate
routers.
Looking back at the traceroute results for shorewall.net, I notice that hop #6
is the first pingable IP address even though it's not always the same. I can
also confirm by geoIP db lookup that it belongs to my ISP.
So I wrote it down and waited until I detected another packet loss event.
When it happened, I pinged that host to find out that it behaved just like in
my previous trace to 8.8.8.8 (ie. echo requests leave the shorewall gateway but
there are missing replies).
Also, this is what happens when I run a traceroute to shorewall:
# traceroute -n -i enp9s6 www.shorewall.net (63.135.54.24), 30 hops max, 60
byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
Another try shortly after shows this:
# traceroute -n -i enp9s6 www.shorewall.net (63.135.54.24), 30 hops max, 60
byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * 4.35.175.6 198.850 ms
12 206.130.130.241 197.610 ms * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
# ping -n -I enp9s6 192.168.101.1
shows no packet loss (modem/router's
Re: [Shorewall-users] Packet loss when changing mangle rule
On Saturday, August 11, 2018, 8:07:36 PM GMT+2, Tom Eastep wrote: > My suggestion for debugging this further is to use a packet sniffer to > see what is happening on the wire during the period of loss: > > a) Are the echo-request packets being sent? > b) If not, is there unsuccessful ARPing occurring? The echo requests are being sent as seen below. # tcpdump -i enp9s6 host 8.8.8.8 dropped privs to tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on enp9s6, link-type EN10MB (Ethernet), capture size 262144 bytes 08:12:18.603636 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo request, id 4825, seq 1, length 64 08:12:19.642887 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo request, id 4825, seq 2, length 64 08:12:20.682810 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo request, id 4825, seq 3, length 64 08:12:21.721237 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo request, id 4825, seq 4, length 64 08:12:22.762528 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo request, id 4825, seq 5, length 64 08:12:23.802597 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo request, id 4825, seq 6, length 64 08:12:24.841126 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo request, id 4825, seq 7, length 64 08:12:25.881195 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo request, id 4825, seq 8, length 64 08:12:26.922607 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo request, id 4825, seq 9, length 64 08:12:27.962655 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo request, id 4825, seq 10, length 64 08:12:29.001091 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo request, id 4825, seq 11, length 64 08:12:30.042569 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo request, id 4825, seq 12, length 64 08:12:31.082581 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo request, id 4825, seq 13, length 64 08:12:32.122591 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo request, id 4825, seq 14, length 64 08:12:33.162544 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo request, id 4825, seq 15, length 64 08:12:33.177647 IP google-public-dns-a.google.com > 192.168.101.2: ICMP echo reply, id 4825, seq 15, length 64 08:12:34.171027 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo request, id 4825, seq 16, length 64 08:12:34.186632 IP google-public-dns-a.google.com > 192.168.101.2: ICMP echo reply, id 4825, seq 16, length 64 08:12:35.180972 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo request, id 4825, seq 17, length 64 08:12:35.196782 IP google-public-dns-a.google.com > 192.168.101.2: ICMP echo reply, id 4825, seq 17, length 64 08:12:36.191086 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo request, id 4825, seq 18, length 64 08:12:36.206656 IP google-public-dns-a.google.com > 192.168.101.2: ICMP echo reply, id 4825, seq 18, length 64 08:12:37.201017 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo request, id 4825, seq 19, length 64 08:12:37.216632 IP google-public-dns-a.google.com > 192.168.101.2: ICMP echo reply, id 4825, seq 19, length 64 08:12:38.210990 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo request, id 4825, seq 20, length 64 08:12:38.226712 IP google-public-dns-a.google.com > 192.168.101.2: ICMP echo reply, id 4825, seq 20, length 64 08:12:39.219069 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo request, id 4825, seq 21, length 64 08:12:39.234713 IP google-public-dns-a.google.com > 192.168.101.2: ICMP echo reply, id 4825, seq 21, length 64 08:12:40.229018 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo request, id 4825, seq 22, length 64 08:12:40.244660 IP google-public-dns-a.google.com > 192.168.101.2: ICMP echo reply, id 4825, seq 22, length 64 08:12:41.230962 IP 192.168.101.2 > google-public-dns-a.google.com: ICMP echo request, id 4825, seq 23, length 64 08:12:41.246677 IP google-public-dns-a.google.com > 192.168.101.2: ICMP echo reply, id 4825, seq 23, length 64 The pattern of echo replies failing to arrive is variable. At times, there's no packet loss, but I frequently get a 10-20-40% packet loss (sometimes even as high as 65%). I also noticed (but it's just an impression) that right after rebooting the modem/router I get no packet loss whatsoever for several hours. The shorewall gateway's enp9s6 interface is 100Mbps full duplex, and is connected to the modem/router which has a built-in 4-port Gbps switch with an ethernet cable. If I connect a test laptop to that mini switch while I'm experiencing the packet loss issues on the shorewall box, I can see the same problems there too. Disconnecting the shorewall gateway ethernet cable from that 4-port switch, hence making my test laptop the only client device in the network makes the packet loss is
[Shorewall-users] Packet loss when changing mangle rule
Hi,
I've encountered a weird issue.
I have 3 ISP links (WAN) connected to a shorewall gateway, each on their own
NIC.
After about 24 hours working with apparently no issues, I start to get network
issues on only one of the three.
A simple test from the shorewall gateway shows the following packet loss when
pinging from the NIC that's connected to the failing ISP:
# shorewall reset ; ping -n -I enp9s6 8.8.8.8 ; shorewall dump >
/home/vieri/swdump
Shorewall Counters Reset
PING 8.8.8.8 (8.8.8.8) from 192.168.101.2 enp9s6: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=12 ttl=120 time=11.1 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=120 time=11.1 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=120 time=11.1 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=120 time=10.9 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=120 time=11.0 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=120 time=11.0 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=120 time=11.2 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=120 time=11.1 ms
64 bytes from 8.8.8.8: icmp_seq=20 ttl=120 time=11.3 ms
64 bytes from 8.8.8.8: icmp_seq=21 ttl=120 time=11.1 ms
64 bytes from 8.8.8.8: icmp_seq=22 ttl=120 time=11.1 ms
64 bytes from 8.8.8.8: icmp_seq=23 ttl=120 time=11.2 ms
64 bytes from 8.8.8.8: icmp_seq=24 ttl=120 time=11.2 ms
64 bytes from 8.8.8.8: icmp_seq=25 ttl=120 time=11.2 ms
64 bytes from 8.8.8.8: icmp_seq=26 ttl=120 time=11.3 ms
64 bytes from 8.8.8.8: icmp_seq=27 ttl=120 time=11.2 ms
64 bytes from 8.8.8.8: icmp_seq=28 ttl=120 time=11.2 ms
64 bytes from 8.8.8.8: icmp_seq=29 ttl=120 time=11.3 ms
64 bytes from 8.8.8.8: icmp_seq=30 ttl=120 time=11.4 ms
64 bytes from 8.8.8.8: icmp_seq=31 ttl=120 time=11.3 ms
64 bytes from 8.8.8.8: icmp_seq=32 ttl=120 time=11.2 ms
64 bytes from 8.8.8.8: icmp_seq=33 ttl=120 time=11.3 ms
64 bytes from 8.8.8.8: icmp_seq=34 ttl=120 time=11.5 ms
64 bytes from 8.8.8.8: icmp_seq=35 ttl=120 time=11.3 ms
64 bytes from 8.8.8.8: icmp_seq=36 ttl=120 time=11.3 ms
64 bytes from 8.8.8.8: icmp_seq=37 ttl=120 time=11.4 ms
64 bytes from 8.8.8.8: icmp_seq=38 ttl=120 time=11.3 ms
64 bytes from 8.8.8.8: icmp_seq=39 ttl=120 time=11.3 ms
64 bytes from 8.8.8.8: icmp_seq=40 ttl=120 time=11.8 ms
64 bytes from 8.8.8.8: icmp_seq=41 ttl=120 time=11.6 ms
64 bytes from 8.8.8.8: icmp_seq=42 ttl=120 time=11.4 ms
^C
--- 8.8.8.8 ping statistics ---
42 packets transmitted, 31 received, 26% packet loss, time 41698ms
rtt min/avg/max/mdev = 10.981/11.303/11.890/0.212 ms
The same test on the other 2 ISP links are OK.
Hence, if ISP3 is the failing link and ISP1, ISP2 are OK, I try to move some
traffic from ISP3 to ISP2 like so in the mangle file:
MARK(2):P ${HMAN_EXTRA_CORP_NETWORKS}
(2: ISP2, 3: ISP3, HMAN_EXTRA_CORP_NETWORKS="192.168.210.0/23,192.168.212.0/24")
Now, the same ping test from the NIC that's connected to ISP2 starts showing
the same packet loss stats while the test on the NIC connected to ISP3 has 0%
packet loss.
Wherever I move the traffic with this line in the mangle file, I get ICMP
packet loss, ie., moving it back to MARK(3) (ISP3) shows packet loss again only
on that line.
The shorewall dump taken during the test above is here:
https://drive.google.com/open?id=1a6RlQhi2w_JJF9ZuFt6aI9G-JAQbFC9n
Finally, to top it all off, if I reboot the modem/router on the ISP3 link,
all's well again (no packet loss whatsoever, no matter which rule I use in the
mangle file). Until the next day...
So, how can I go about this to determine what's causing this issue? My Internet
Provider has already passed the buck and thinks that it's an issue with my
shorewall gateway...
Help appreciated.
Thanks,
Vieri
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] blacklisting
On Tuesday, July 31, 2018, 4:26:29 AM GMT+2, Tom Eastep wrote: > No - blacklist checking occurs before the connection request is passed > to any rules. The redirect of port 80 to 6 (a custom HTTP service) is to inform legit users of their mistake when trying to connect. So I removed calls to the BLACKLIST action or policy, and started using ADD and REDIRECT again within the rules file like this: [Placed almost at the top of the rules file, right after several static REJECTs or DROPs] REDIRECT:info:,blsredir net1,net2,net3:+IPS_BL,+POL_BL!+GLOBAL_WL 6 tcp 80 DROP:info:,blsseen net1,net2,net3:+IPS_BL,+POL_BL!+GLOBAL_WL all [...list of ACCEPT / DNAT rules...] ADD(POL_BL:src):info:polbl,add2polbl net1,net2,net3:!+POL_BL,+GLOBAL_WL all tcp,udp - !443,80,25 [EOF] With this method I won't be updating the ipset timeout (!+POL_BL in ADD), I will be specifying the ipset name within the rules file, and I will allow early redirects for requests to port 80 to go to a custom HTTP service on port 6. The only drawback is that I need to maintain a list of ports/protocols to exclude from the ADD action (in my case, allowed traffic for now would be on ports 443,80,25). A bit ugly and error-prone. Anyway, I also noticed that I had to remove my ipset definition from DYNAMIC_BLACKLIST (I set to DYNAMIC_BLACKLIST=Yes or No) even though I never referenced BLACKLIST anywhere else in Shorewall (neither in policy nor in rule).Otherwise, the remote host's IP address would be added to the ipset each time it was seen, thus partially invalidating the purpose of my three lines in the rules file and updating the ipset member timeout when not wanted. Why was this triggered? This was the only occurrence of BLACKLIST in my shorewall files: # grep BLACKLIST /etc/shorewall/* /etc/shorewall/shorewall.conf:BLACKLIST_LOG_LEVEL= /etc/shorewall/shorewall.conf:BLACKLIST_DEFAULT="Broadcast(DROP),Multicast(DROP),dropNotSyn:$LOG_LEVEL,dropInvalid:$LOG_LEVEL,DropDNSrep:$LOG_LEVEL" /etc/shorewall/shorewall.conf:BLACKLIST="NEW,INVALID,UNTRACKED" /etc/shorewall/shorewall.conf:DYNAMIC_BLACKLIST=ipset,timeout=172800:POL_BL:info:add2polbl /etc/shorewall/shorewall.conf:BLACKLIST_DISPOSITION=DROP Thanks, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] blacklisting
When using the BLACKLIST policy in a policy file (and defining an ipset in DYNAMIC_BLACKLIST), is it possible to redirect future connection attempts form src hosts in the BL ipset only if made to port 80 to another port port, say 6000?ie. if a blacklisted host tries to connect to port 80 via HTTP, redirect traffic to port tcp 6000 on the shorewall firewall? How and where can I do this? Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] blacklisting
When using the BLACKLIST policy in a policy file (and defining an ipset in DYNAMIC_BLACKLIST), is it possible to add the src IP address ONLY if it doesn't already exist in the set? No point in adding an ip address to an ipset if it's already there unless you want to update the timeout, if any. I have a set timeout for each entry, but I'd rather not update it. Thanks, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] blacklisting
Hi, I've been blacklisting hosts that try to access unpublished ports by simply adding the following to the very end of my rules file: ADD(POL_BL:src):info:polbl,add2polbl net1,net2,net3:!+POL_BL,+GLOBAL_WL all tcp,udp - !443,80,25 I'd rather not use the BLACKLIST policy and defining an ipset in DYNAMIC_BLACKLIST because I may have more than one ADD rule with different ipsets and parameters. So I like the ADD rule I mentioned above except that if I remove the trailing "tcp,udp - !443,80,25" then I get unwanted results such as: Shorewall:polbl:add2polbl:IN=enp9s6 [...] PROTO=TCP SPT=443 DPT=33046 WINDOW=249 RES=0x00 ACK PSH URGP=0 MARK=0x3 Shorewall:polbl:add2polbl:IN=enp9s5 [...] PROTO=TCP SPT=443 DPT=53763 WINDOW=252 RES=0x00 ACK URGP=0 MARK=0x2 Shorewall:polbl:add2polbl:IN=enp9s5 [...] PROTO=TCP SPT=443 DPT=43729 WINDOW=0 RES=0x00 RST URGP=0 MARK=0x2 Shorewall:polbl:add2polbl:IN=enp9s4 [...] PROTO=TCP SPT=25 DPT=42208 WINDOW=0 RES=0x00 RST URGP=0 MARK=0x1 I need to allow ACK and RST packets. Is there a better way to write this (instead of explicitly specifying "!443,80,25")? Thanks, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] ARP
From: Tom Eastep >> >> Can I avoid replying ARP requests for 192.168.200.0/24 only? >> > Yes -- add a DROP entry in /etc/shorewall/arprules. Thanks. However, I don't understand why the ARP replies were generated even if I set "arp_filter=1" for that interface ($IF_LAN in my example). This interface does not have any IP address configured within 192.168.200.0/24. Thanks, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] ARP
Hi, In my LAN I have two networks on the same physical infrastructure (no VLAN): 10.215.0.0/16 and 192.168.200.0/24 The LAN interface on Shorewall firewall/gateway has proxy_arp enabled for some cases, but it seems to be initerfering with ARP requests. This is what I see on the Shorewall box when two hosts in 192.168.200.0 try to ping each other: 12:16:54.954199 ARP, Request who-has 192.168.200.21 (30:85:a9:8e:b9:a0) tell 192.168.200.249, length 46 12:16:54.954219 ARP, Reply 192.168.200.21 is-at 30:85:a9:8e:b9:a0, length 28 The problem is that 30:85:a9:8e:b9:a0 is Shorewall's LAN interface MAC, not the MAC of the host at 192.168.200.21. I tried to add static ARP entries for the LAN interface on the Shorewall system (arp -i ... -s ...), but the "is-at" replies were still the same. Removing proxy_arp on Shorewall's LAN interface solves the issue but opens others. What can I try? Can I avoid replying ARP requests for 192.168.200.0/24 only? # ip addr show 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 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 valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 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 3: enp6s0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 68:05:ca:10:c3:b7 brd ff:ff:ff:ff:ff:ff inet 172.16.0.1/28 brd 172.16.0.15 scope global enp6s0 valid_lft forever preferred_lft forever inet6 fe80::6a05:caff:fe10:c3b7/64 scope link valid_lft forever preferred_lft forever 4: enp7s0f0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether e8:ea:6a:0c:4c:1c brd ff:ff:ff:ff:ff:ff 5: enp7s0f1: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether e8:ea:6a:0c:4c:1d brd ff:ff:ff:ff:ff:ff 6: enp7s0f2: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether e8:ea:6a:0c:4c:1e brd ff:ff:ff:ff:ff:ff inet 172.28.17.105/29 brd 172.28.17.111 scope global enp7s0f2 valid_lft forever preferred_lft forever inet6 fe80::eaea:6aff:fe0c:4c1e/64 scope link valid_lft forever preferred_lft forever 7: enp7s0f3: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether e8:ea:6a:0c:4c:1f brd ff:ff:ff:ff:ff:ff inet 172.20.11.62/28 brd 172.20.11.63 scope global enp7s0f3 valid_lft forever preferred_lft forever inet6 fe80::eaea:6aff:fe0c:4c1f/64 scope link valid_lft forever preferred_lft forever 8: enp8s5: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:e3:c0:5f:81:5d brd ff:ff:ff:ff:ff:ff 9: enp10s0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 30:85:a9:8e:b9:a0 brd ff:ff:ff:ff:ff:ff inet 10.215.144.91/32 scope global enp10s0 valid_lft forever preferred_lft forever inet 10.215.144.6/32 scope global enp10s0 valid_lft forever preferred_lft forever inet 10.215.246.91/32 scope global enp10s0 valid_lft forever preferred_lft forever inet 192.168.144.91/24 brd 192.168.144.255 scope global enp10s0 valid_lft forever preferred_lft forever inet 10.215.145.241/32 scope global enp10s0 valid_lft forever preferred_lft forever inet 10.215.145.242/32 scope global enp10s0 valid_lft forever preferred_lft forever inet 10.215.145.81/32 scope global enp10s0 valid_lft forever preferred_lft forever inet6 fe80::3285:a9ff:fe8e:b9a0/64 scope link valid_lft forever preferred_lft forever 26: tun148: mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100 link/none inet 192.168.148.1/22 brd 192.168.151.255 scope global tun148 valid_lft forever preferred_lft forever inet6 fe80::e00e:1aef:f904:bc06/64 scope link flags 800 valid_lft forever preferred_lft forever 27: tun146: mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100 link/none inet 192.168.146.1/24 brd 192.168.146.255 scope global tun146 valid_lft forever preferred_lft forever inet6 fe80::2cb6:e903:de8f:e12a/64 scope link flags 800 valid_lft forever preferred_lft forever 28: tun147: mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100 link/none inet 192.168.147.1/27 brd 192.168.147.31 scope global tun147 valid_lft forever preferred_lft forever inet6 fe80::ac5f:bf46:8407:a3d7/64 scope link flags 800 valid_lft forever preferred_lft forever Thanks, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-
[Shorewall-users] DNAT and ADD in rules
Hi, Here's a snippet of my rules file: DNATnet1loc:10.215.145.120:443 tcp 30443 DNATnet1loc:10.215.144.95:80tcp 30080 # ACCEPTnet1$FW tcp 30443,30080 ADD(POL_BL:src):info:polbl,add2polblnet1,net2,net3,net4:!+POL_BL,+GLOBAL_WL all I'd like ADD() to be "executed", but only if traffic has not been ACCEPT'ed or DNAT'ed. The above lines "run" ADD() even when there's a match for the DNAT rules. If I uncomment the 3rd line then ADD() is not reached, as expected. However, I'd rather not use the 3rd line. How can I configure the rules file so that ADD() is not reached when a DNAT entry like the ones above is matched? Thanks, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] tcpflags
Hi, By default, Shorewall sets tcpflags to 1 for each interface, ie. it checks for invalid combinations of TCP flags. Recently, I saw the following DROP lines in my log: Shorewall:logflags:DROP:IN=enp10s0 OUT=enp7s0f2 MAC=30:85:a9:8e:b9:a0:00:50:60:80:6a:ba:08:00 SRC=10.215.144.98 DST=10.215.219.228 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=9197 PROTO=TCP SPT= DPT=3230 WINDOW=0 RES=0x00 RST FIN URGP=0 TCP/3230 is used for video conferencing, and it should be allowed according to my rules. I could set tcpflags=0 for interface enp7s0f2, but I'd rather not. Is there a way to "force-ACCEPT", or to disable tcpflag checking on a per-rule basis? Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] dynamic blacklist
From: Tom Eastep >> Am I required to use a custom DROP action instead of DYNAMIC_BLACKLIST? > > Yes. The Shorewall dynamic blacklisting implementation currently does > not allow for such exceptions. OK, thanks. Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] dynamic blacklist
Hi, I want to dynamically blacklist the IP addresses of hosts that try to connect to unadvertized ports. I do this by setting the following in shorewall.conf: DYNAMIC_BLACKLIST=ipset,timeout=172800:POL_BL:info:polbl I also set the BLACKLIST policy: net4 $FW BLACKLIST net4 loc BLACKLIST net4 dmz BLACKLIST net4 net3 BLACKLIST net4 net2 BLACKLIST net4 net1 BLACKLIST net4 all BLACKLIST net3 $FW BLACKLIST net3 loc BLACKLIST net3 dmz BLACKLIST net3 net4 BLACKLIST net3 net2 BLACKLIST net3 net1 BLACKLIST net3 all BLACKLIST net2 $FW BLACKLIST net2 loc BLACKLIST net2 dmz BLACKLIST net2 net4 BLACKLIST net2 net3 BLACKLIST net2 net1 BLACKLIST net2 all BLACKLIST net1 $FW BLACKLIST net1 loc BLACKLIST net1 dmz BLACKLIST net1 net4 BLACKLIST net1 net3 BLACKLIST net1 net2 BLACKLIST net1 all BLACKLIST However, after blacklisting the hosts' IP addresses I'd also like to redirect and allow ONLY traffic to port 62000 on the $FW IF the original destination port was 80. In other words, if a listed client were to connect to http://myserver then it would be redirected to TCP 62000. No other traffic allowed for that source IP addr. I have this in rules almost at the top: REDIRECT:info:blsinit net1,net2,net3,net4:+IPS_BL,+POL_BL!+GLOBAL_WL 62000 tcp 80 However, I get this in the log: Shorewall:blsinit:REDIRECT:IN=enp9s4 OUT= MAC= SRC= DST=192.168.92.2 LEN=52 TOS=0x00 PREC=0x00 TTL=122 ID=20594 DF PROTO=TCP SPT=30142 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0 MARK=0x1 Shorewall:polbl:DROP:IN=enp9s4 OUT= MAC= SRC= DST=192.168.92.2 LEN=52 TOS=0x00 PREC=0x00 TTL=122 ID=20594 DF PROTO=TCP SPT=30142 DPT=62000 WINDOW=8192 RES=0x00 SYN URGP=0 MARK=0x1 Here, "polbl" refers to the setting in DYNAMIC_BLACKLIST. I guess it's expected, so I don't know if posting a shorewall dump to this list would help. I'd like to know how to change my shorewall configuration in order to only accept connections to 62000 for blacklisted hosts. Adding an explicit ACCEPT rule before or after REDIRECT does not seem to "work". Am I required to use a custom DROP action instead of DYNAMIC_BLACKLIST? Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] ipsets in traffic shaping
Hi, I was wondering if it's impossible to use ipsets in the ADDRESS column in tcpri. Thanks, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] mangle and network mask
From: Tom Eastep > > I just released 5.1.7.2 which correctly handles your rule. I've seen the release notice. Once again, thank you very much, Tom. Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] mangle and network mask
From: Bill Shirley > Two observations Thanks for that, Bill. I allow DNS queries only from dedicated DNS servers on the LAN. I don't REDIRECT. Any client misbehaving DNS-wise won't be able to lookup IP addresses. Point 2 taken. Thanks again, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] mangle and network mask
From: Tom Eastep > > It is the *next to the last* rule that is causing the problem. OK, so my problem is that I wrote the following in my mangle file: MARK(1-3):P 0.0.0.0/0 0.0.0.0/0 tcp,udp 53 and it translated to: Chain tcpre [...] 7784 6738K MARK all -- * * 0.0.0.0/00.0.0.0/0 statistic mode nth every 3 MARK xset 0x1/0xff 7783 6764K MARK all -- * * 0.0.0.0/00.0.0.0/0 statistic mode nth every 3 packet 1 MARK xset 0x2/0xff 7783 6623K MARK all -- * * 0.0.0.0/00.0.0.0/0 statistic mode nth every 3 packet 2 MARK xset 0x3/0xff I erroneously thought that I could "balance" DNS traffic among the first 3 providers. It can't be done here, right? -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] mangle and network mask
From: Norman Henderson > > MARK(25)10.0.69.2 - tcp smtp > MARK(25)- 10.0.69.2 tcp smtp > > 10.0.69.2 - cem09 128025 Could you please share the relevant part of your providers file? > rtrules 10.0.69.2 - cem09 1281 In my specific example I could very well use policy based routing in rtrules without marks. However, there are other cases where I require to use MARK. Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] mangle and network mask
From: Tom Eastep > > Remember that MARK is not a terminating target -- so the *last* MARK > rule to match the packet is the one that assigns the mark. I was aware of that when I wrote the rules. My providers file is: ISP11 1 - $IF_ISP1$IF_ISP1_GW track,balance=3,persistent ISP22 2 - $IF_ISP2$IF_ISP2_GW track,balance=2,persistent ISP33 3 - $IF_ISP3$IF_ISP3_GW track,balance=1,persistent ISP44 4 - $IF_ISP4$IF_ISP4_GW track,balance=1,persistent ...and the *last* line of my mangle file is: MARK(3):P - 193.104.0.136 > Your> statistical MARK rules are overwriting your intended mark values most of > the time. If by "statistical" you mean the marks produced by "balance" in the providers file then am I mistaken to think that the last mangle rule defined overwrites previous marks? > You need to populate the TEST column of your route marking> rules to stop > this unintended overwriting of previously assigned marks. The TEST column in the mangle file? Not quite sure which value to use for a MARK rule on the last line of that file. Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] mangle and network mask
Hi again, It seems that I'm getting mixed results. According to the dump I'm posting in the link below, shouldn't a host accessing 193.104.0.136 on port 443 go out provider marked as 3? The dump was taken while trying to open https site at 193.104.0.136 from 10.215.144.48. https://drive.google.com/open?id=0B-tpkY1LkI67X0FzWnRMSFRYd1E I had mixed results. Sometimes traffic is going out provider 3, and at times it's going out another provider. So my previous posts are probably "wrong" in that the netmask has nothing to do with the issue I'm seeing. Even if I balance traffic in the providers file, I require traffic to 193.104.0.136 to *always* go out provider 3. Regards, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] mangle and network mask
Sorry for the noise, but it doesn't seem to be related to what I put in mangle's PROTO column. When I use this address in SOURCE (192.168.210.0/23) traffic is not sent out provider 4. Using either 192.168.210.0/24,192.168.211.0/24 or 192.168.210.1-192.168.211.254 does send traffic out provider 4. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] mangle and network mask
Actually, it's not a netmask issue. After another test, I noticed that this fails (better yet, it doesn't do what I want): MARK(4):P 192.168.210.0/23,192.168.212.0/24 0.0.0.0/0 all whereas this other is what I want: MARK(4):P 192.168.210.0/23,192.168.212.0/24 0.0.0.0/0 What's the difference? -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] mangle and network mask
Hi, I've come up with an issue with the mangle file. I'm not sure if I'm making a mistake, or if there's a real issue here. Anyway, here are my findings. I noticed that the following is not honored: MARK(4):P 192.168.210.0/230.0.0.0/0 all whereas this other line IS: MARK(4):P 192.168.210.0/24,192.168.211.0/24 0.0.0.0/0 all I've come to this conclusion by watching traffic from a host with IP addr. 192.168.211.199 out my providers. When using the /23 netmask, this host was going out the wrong provider. When using /24, the host's traffic is correctly going through the provider marked as 4. iptables-1.4.21 shorewall-5.1.5 kernel 4.9.34 I guess I can live with that workaround, unless I'm only seeing a side effect. Has anyone noticed this? Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] TCP congestion control
From: Paul Gear > > There is no point deploying BBR on routers; Thanks Paul. Has anyone tried the following on a shorewall router (without traffic shaping, just in case)? sysctl -w net.core.default_qdisc=fq_codel sysctl -w net.ipv4.tcp_congestion_control=cdg -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] TCP congestion control
Hi, My system has these values by default: # sysctl net.ipv4.tcp_available_congestion_control net.ipv4.tcp_available_congestion_control = cubic reno htcp bbr cdg # sysctl net.core.default_qdisc net.core.default_qdisc = pfifo_fast # sysctl net.ipv4.tcp_congestion_control net.ipv4.tcp_congestion_control = cubic Some suggest to switch to either bbr or cdg. Would the following settings make any difference performance-wise on a shorewall router? # sysctl net.core.default_qdisc=fq # sysctl net.ipv4.tcp_congestion_control=bbr Should shorewall traffic shaping be configured and enabled with TC_ENABLED=Simple and at least one interface in shorewall-tcinterfaces? Or does the bbr tcp congestion control have nothing to do with traffic shaping per se? Thanks, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Shorewall 5.1.6
From: Norman Henderson > > I have a couple of remotely located systems with the Ubuntu-packaged > shorewall 5.0.4 and would like to > move to building the current release 5.1.6 instead. On Gentoo, you can use slotted packages. I don't know about Ubuntu - I don't use it. In any case, I guess you can run "dpkg-query -L shorewall" to get a full list of the installed 5.0 files, back them up with all your custom config files. I'd create and run in the background an auto-reverting script while doing the upgrade to 5.1 from a remote location. If all goes well, kill the script once you ssh into the firewall again. If it fails, just wait until the script removes 5.1, restores the backed-up files, and restarts shorewall 5.0. Before doing so, make sure you also handle dependencies that may be pulled in, or not. Just a thought. Good luck. Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload / restart
From: Tom Eastep > > So why don't you simply leave that route in place all of the time? Just > define it in your distribution's networking config. I'm used to using rtrules, routes, and providers with shorewall. I share those files with other members of the IT staff, and sometimes we need to change which provider provides a given subnet. Of course, all the routing (tables and rules) could be done by the OS, but it is more convenient for me to have it all within shorewall. > The 'reload' command already supports the -n option. If "reload -n" will NOT flush rules and tables previously created by "start" or "restart" then I guess I could use that, and move out the code I have in the files "stopped" and "started". > 'reload' and 'start' are basically the same command. ..."-n" meaning "leave the routing alone". In my case, I'd always use reload -n, except when making changes to "rtrules", "routes", and "providers". Also, when shorewall "updates the routing tables/rules", it actually flushes everything and creates anew, right? It doesn't really "update", or is it possible to do so? Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload / restart
From: Tom Eastep > > The stopped state is NOT longer in 5.1. The compilation step is longer, > but the time to run the script once it is compiled should be very close > to the same. OK, I don't know why I was previously getting such a long connection outage while shorewall 5.1 was restarting, and I can't seem to reproduce this today. I also realize now (or correct me if I'm wrong) that the access rules and routing tables are "still there" when shorewall is compiling and optimizing rules. They are flushed afterwards, and there should be no big difference between 5.0 and 5.1. However, I must say that I've reproduced the following behavior several times now. If I *only* have stoppedrules defined as: ACCEPT $IF_LAN $IF_CAIB (and no custom routing during the stopped state) then I'm still seeing messages like this one (during the time frame when shorewall has flushed the routing tables): >From 172.16.0.2 icmp_seq=7 Time to live exceeded This happens whether I "restart" or "reload" (tested on 5.1, and yes, also 5.0, as you said should behave similarly). Of course, the ping statistics show that there were lost packets: 721 packets transmitted, 680 received, +2 errors, 5% packet loss Some corporate applications are either very sensitive or poorly programmed, and do not tolerate packet loss. Now, if I also add the following routes as in this example: [ "stopped" file contains ] route add -net 10.215.0.0/17 gw $ADDR_GW_CAIB [ "start" file contains ] route del -net 10.215.0.0/17 return 0 I can then test continuous pings to the CAIB zone from the LAN zone while I restart/reload shorewall several times, and I am unable to reproduce the "Time to live exceeded" issue. In other words, I am not losing a single ping (5.1 and 5.0). I don't know if this is mere randomness, but I've tried it once and again. BTW, I noticed that the shorewall start command has the -n option which avoids updating the routing tables. Would it make sense for future shorewall releases to include a similar -n option for the stop command so Shorewall does not flush the routing tables during the stopped phase or when reloading? Maybe additional -n0 and -0n options could be passed to the restart commands so that: 1) -n is equivalent to shorewall stop && shorewall start -n 2) -0n is the same (equivalent to shorewall stop && shorewall start -n) 3) -n0 is equivalent to shorewall stop -n && shorewall start 4) -nn is equivalent to shorewall stop -n && shorewall start -n The command "stop -n" should not flush "ip route" or "ip rule". The reload command could also use the -n0, -0n, -nn options for the same purpose. I would also like to know if the INCLUDE directive is available in the following files, and if the variables defined in the params file are also available: 1) start 2) started 3) stopped Thanks, Vieri P.S.: the 5.1 system I'm configuring was installed ex-novo. I am NOT "shorewall upgrading" from 5.0 to 5.1. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload / restart
From: Tom Eastep > In both 'restart' and 'reload', the provider routing tables and rules> are > purged then reloaded. But they were purged and reloaded on 5.0 as well. OK, but since 5.0 had OPTIMIZE=0 the "cut" was almost gone unnoticed. I'd like to keep OPTIMIZE=All in 5.1. So, since the stopped state is way longer, how do I allow lan-caib and lan-ibs traffic? This alone in stoppedrules isn't enough: ACCEPT $IF_LAN$IF_IBS ACCEPT $IF_LAN$IF_CAIB Please correct me if I'm wrong, but I need to build the appropriate routing table as soon as shorewall is in the stop state. Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] traffic issues through firewall router
From: Vieri Di Paola via Shorewall-users > > lan $IF_LAN routeback,arp_filter=1 > wan $IF_WAN routeback,arp_filter=1 > caib$IF_CAIBarp_filter=1 > ibs $IF_IBS arp_filter=1 > dmz $IF_DMZ routeback,dhcp > - lo - > > I unsuccessfully tried adding proxyarp=1 to IF_IBS, but not IF_LAN. I realized the failing LAN hosts did not have appropriate persistent routes to both caib and ibs. Adding them solves the issue. I thought it would have worked with proxyarp=1 on $IF_IBS, but I'm OK now just as long as the clients get set up correctly. Thread closed. Thanks, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload / restart
I'm asking because I'm seeing two issues with the restart command when trying to move from shorewall 5.0.14.1 to a more recent version (eg. 5.1.5.1). According to http://www.shorewall.net/pub/shorewall/5.0/shorewall-5.0.14/releasenotes.txt, the "restart" option should behave the same way. So, if RESTART=restart then a "true" restart is done (stop&start). It won't be a "reload". On both of my old and new shorewall systems, RESTART=restart. ADMINISABSENTMINDED is also set to Yes. First issue: Here's what I see when I ping to a host in CAIB zone at 10.215.9.172 from a host in LAN zone while running "shorewall restart". [...] 64 bytes from 10.215.9.172: icmp_seq=4 ttl=59 time=4.06 ms 64 bytes from 10.215.9.172: icmp_seq=5 ttl=59 time=2.77 ms 64 bytes from 10.215.9.172: icmp_seq=6 ttl=59 time=2.30 ms >From 172.16.0.2 icmp_seq=7 Time to live exceeded 64 bytes from 10.215.9.172: icmp_seq=8 ttl=59 time=2.97 ms 64 bytes from 10.215.9.172: icmp_seq=9 ttl=59 time=4.23 ms 64 bytes from 10.215.9.172: icmp_seq=10 ttl=59 time=2.98 ms This is the content of stoppedrules: ACCEPT $IF_LAN $IF_IBS ACCEPT $IF_LAN $IF_CAIB The IP addr. 172.16.0.2 is on a gateway out the WAN interface. The providers file contains: WAN 1 1 - $IF_WAN $ADDR_GW_WANtrack,primary CAIB2 2 - $IF_CAIB$ADDR_GW_CAIB track,fallback=1 IBS 3 3 - $IF_IBS $ADDR_GW_IBStrack,fallback=1 The rtrules file contains: - 10.215.0.0/17 CAIB11692 So I guess that if I wanted to allow all traffic from lan to caib and to ibs then I would also have to modify the routing table. I think I should do this in the "stopped" file with something like this: route add 10.215.0.0/17 gw $ADDR_GW_CAIB I haven't tried it though. Does it make sense? Also, would I need to remove the route entries listed in "stopped" when shorewall starts again? Would I need to add something like this in the "started" or "start" files? Which file BTW? (I would need to do that before Shorewall starts handling routes) route del 10.215.0.0/17 Alternatively, if I could do without running the code in "stopped" and "started" then I could issue a "shorewall reload". However, I've seen the "From 172.16.0.2 icmp_seq=38 Time to live exceeded" message even when issuing a "reload". So it seems that in this particular case (maybe due to the providers&rtrules settings) a reload and a restart behave alike (only tested with 5.0.14.1 as 5.1.5.1 is not in production yet). The second issue regards performance on a restart or a reload. Both of my systems (5.0 / 5.1) have the same ruleset of about 7000 lines. Shorewall 5.0 is running on a "weak" server whereas 5.1 is on much more powerful hardware. With 5.0: # time /etc/init.d/shorewall restart [...] real0m14.793s user0m8.780s sys 0m1.480s With 5.1: # time /etc/init.d/shorewall restart [...] real 0m45.981s user 0m42.410s sys 0m2.310s The difference between the two is staggering. It's probably due to the OPTIMIZE option in shorewall.conf, right? In shorewall 5.0.14.1 the default value for OPTIMIZE is 0. In 5.1.5.1 the default value is All despite the man page saying that "The default value is zero which disables all optimizations" (that was true for older versions). So I guess I have to set OPTIMIZE=0 or None in 5.1 in order to get similar or better timings. BTW, I'm wondering if the OPTIMIZE option could somehow explain the other issue I'm having in the ML thread "traffic issues through firewall router". I'll do a test asap. Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Documentation error?
From: Philip Le Riche > > I presume "Corresponding..." down to the end of the quote is an unintentional > duplicate. It is. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] traffic issues through firewall router
I can see the light at the end of the tunnel, but I'm not quite there yet. A reminder of my current network: Internet providers --- gw1 --- fw2 --- lan, dmz, caib, ibs I replaced the old fw1 with the new fw2 this morning, and everything seemed to work until I found that some lan hosts could not access hosts in the caib and ibs zones. They could however access hosts in the wan zone, as well as fw2 itself. The strange thing is that two hosts with apparently the same access rules do not behave the same way. One can ping, the other can't. Let's just take one example: - ping dest IP address 10.215.134.196 in "ibs" zone from "lan" host with IP address 10.215.144.48 is OK - ping dest IP address 10.215.134.196 in "ibs" zone from "lan" host with IP address 10.215.246.47 FAILS Same thing happens with dest IP address 10.215.9.172 in "caib" zone. Please note that host at 10.215.246.47 can ping fw2 and 8.8.8.8 in "wan" zone just fine. This is the "rule" that should match: ACCEPTlan:10.215.246.0/23caib:10.215.0.0-10.215.143.255all ACCEPTlan:10.215.246.0/23ibs:10.215.0.0-10.215.143.255all While performing the first test, I see this on fw2: # tcpdump -nni enp10s0 host 10.215.246.47 07:41:23.433865 ARP, Request who-has 10.215.134.196 tell 10.215.246.47, length 46 07:41:28.933987 ARP, Request who-has 10.215.134.196 tell 10.215.246.47, length 46 07:41:34.434102 ARP, Request who-has 10.215.134.196 tell 10.215.246.47, length 46 07:41:39.934164 ARP, Request who-has 10.215.134.196 tell 10.215.246.47, length 46 My current "interfaces" file on fw2 is as follows: lan $IF_LAN routeback,arp_filter=1 wan $IF_WAN routeback,arp_filter=1 caib$IF_CAIBarp_filter=1 ibs $IF_IBS arp_filter=1 dmz $IF_DMZ routeback,dhcp - lo - I unsuccessfully tried adding proxyarp=1 to IF_IBS, but not IF_LAN. Here's the link to the shorewall dump while doing this test (I added logging to the lan-ibs and lan-caib policies): https://drive.google.com/file/d/0B-tpkY1LkI67LXBXSTlaV1FOeEE/view?usp=sharing (More) help appreciated. Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] shorewall reload / restart
Hi, I read the shorewall man page regarding the "reload" and "restart" commands. From a practical point of view and with default shorewall.conf settings in 5.1, if I change/add/delete entries in the "rules" file, and issue the "reload" command then I should expect the following: - existing connections will not be affected - the "new rules" will be processed and applied Same thing should happen when changing entries in snat, mangle, routes, rtrules. The params file should also be re-read. Correct? So, with shorewall >=5.0.15, when would it be useful to issue the "restart" command? The only scenario I can think of is if I wanted to interrupt active connections (or at least preserve only those in "stoppedrules"). Regards, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] traffic issues through firewall router
From: Tom Eastep > > there is no evidence in the dump that your rule was present. Here's part of the output of shorewall -vv check: Checking /etc/shorewall/snat... [...] Snat record "SNAT(10.215.144.92) 172.16.0.2 enp11s0" Checked However, the following yields nothing after a shorewall restart: # grep -i snat /var/lib/shorewall/firewall | grep enp11s0 So I was wondering if I was being bitten again by the AUTOMAKE issue I experienced lately on another system. On gw1: # grep AUTOMAKE /etc/shorewall/shorewall.conf AUTOMAKE=Yes Changed it to No, and now: # grep -i snat /var/lib/shorewall/firewall | grep enp11s0 -A POSTROUTING -o enp11s0 -s 172.16.0.2 -j SNAT --to-source 10.215.144.92 Finally, I successfully ping'ed fw2 from gw1 as source addr. 10.215.144.92. Sorry about that. From now on, I'll try to remember to always check that AUTOMAKE is disabled. Thanks, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] traffic issues through firewall router
From: Tom Eastep >> Here's what I did in gw1's snat file: >> >> SNAT($IF_LAN_MASQ_ADDRESS) $IF_LAN_MASQ_SOURCE $IF_LAN >> >> The params file contains: >> >> IF_LAN=enp11s0 >> IF_LAN_MASQ_ADDRESS=10.215.144.92 >> IF_LAN_MASQ_SOURCE=172.16.0.2 > > You wanted: >SNAT($IF_LAN_MASQ_ADDRESS)$IF_LAN:$IF_LAN_MASQ_SOURCE- I hope I copied it correctly: # tail -n 1 snat SNAT($IF_LAN_MASQ_ADDRESS) $IF_LAN:$IF_LAN_MASQ_SOURCE - However, this led to: # shorewall check [...] ERROR: DEST must be specified # shorewall version 5.1.5 Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] traffic issues through firewall router
From: Vieri Di Paola via Shorewall-users > > So if I wanted to avoid using proxy arp on the WAN interface, and since the > bulk 10.215.0.0/16 is > really on the LAN interface then I could change gw1's enp11s0 IP settings to > 10.215.144.92/32 with a > route for 10.215.0.0/16 via 172.16.0.1. Hi, I changed the network configuration in my gw1 shorewall gateway, and removed proxyarp=1 in fw2 as in the setup described earlier: Internet providers --- gw1 (10.215.144.92/32 172.16.0.2/28) --- fw2 --- lan Traffic from lan to wan is OK now, so the issue is solved. However, there's still just one last thing that I'd like to deal with. I tried to ping from gw1 to fw2 but failed. A tcpdump on fw2 shows that the ping request source IP address is 172.16.0.2. It's being blocked by fw2's shorewall rules. I could allow this traffic, but I'd rather keep the ACCEPT rule from wan:10.215.14.92 to $FW alone. I thought I only needed to masquerade on gw1's lan interface. Here's what I did in gw1's snat file: SNAT($IF_LAN_MASQ_ADDRESS) $IF_LAN_MASQ_SOURCE $IF_LAN The params file contains: IF_LAN=enp11s0 IF_LAN_MASQ_ADDRESS=10.215.144.92 IF_LAN_MASQ_SOURCE=172.16.0.2 However, pings still fail for the same reason. A tcpdump on fw2 shows requests such as: 10:50:08.948027 IP 172.16.0.2 > 10.215.144.91: ICMP echo request, id 26579, seq 8, length 64 I'm trying to masq them as "10.215.144.92 > 10.215.144.91". I'm sending a link to gw1's dump while trying to ping 10.215.144.91 (fw2) from gw1 (it actually succeeds because I added the allow rule for 172.16.0.2 to fw2): https://drive.google.com/file/d/0B-tpkY1LkI67YTVQQ2hjQi03T0U/view?usp=sharing In short, I'd like any application running on gw1 (ping, curl, ssh, links, wget, etc.) to access fw2 with source address 10.215.144.92 by default instead of 172.16.0.2. Any idea where my mistake is? Thanks, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] traffic issues through firewall router
From: Tom Eastep > > Here is the main routing table on gw1: > 10.215.0.0/16 dev enp11s0 proto kernel scope link src 10.215.144.92 > > Note the last route. It assumes that the entire 10.215.0.0/16 network is > directly attached to enp11s0. > > Here is the main table on fw2: > The WAN interface that is connected to gw1 is enp6s0 which only has > routes to a handful of 10.215.0.0/16 hosts. The bulk 10.215.0.0/16 is > connected to the LAN interface (enp10s0). Consequently, enp6s0 must > proxy ARP requests for 10.215.x.x. Thank you very much. So if I wanted to avoid using proxy arp on the WAN interface, and since the bulk 10.215.0.0/16 is really on the LAN interface then I could change gw1's enp11s0 IP settings to 10.215.144.92/32 with a route for 10.215.0.0/16 via 172.16.0.1. Have a nice weekend, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] traffic issues through firewall router
From: Tom Eastep
>
> A current dump of fw1 might shed some light on that...
Just to clear things up a little, here's the current network:
providers --- gw1 (shorewall gateway) --- fw{1,2} (shorewall firewall router)
where
- fw1 was the "old" firewall
- fw2 is the new firewall with proxyarp=1 as I explained in my previous e-mail
- gw1 is the "other" shorewall system connected to the internet providers
I'm sending shorewall dumps of both gw1 and fw2 in the following links.
https://drive.google.com/file/d/0B-tpkY1LkI67QTFqVVFzSWZiNlE/view?usp=sharing
https://drive.google.com/file/d/0B-tpkY1LkI67YmVOVHdBUGtHd2M/view?usp=sharing
Thanks,
Vieri
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] traffic issues through firewall router
From: Vieri Di Paola via Shorewall-users > > # tcpdump -nni enp6s0 icmp I think I just found a solution, but I still need to understand why. I had to add proxyarp=1 to the wan interface in "interfaces". Pings to wan hosts started working. Funny thing is that if I set proxyarp=0 and restart shorewall the pings still work. They stop working only if I reboot the kernel (waiting doesn't seem to make the pings fail either - there doesn't seem to be a timeout or similar). Resetting proxyarp=1 and restarting shorewall works as expected. I still have to understand why this interface requires proxyarp, and the other interfaces don't. Thanks, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] traffic issues through firewall router
From: Tom Eastep >> I will be running the following command as soon as I can: >> >> # tcpdump -nni enp6s0 icmp > > That should do it, I'm really sorry to keep this thread alive for so long, but I'm in a nasty predicament. Here's the test I performed while trying to ping from "lan" host at 10.215.144.48 to 8.8.8.8, 172.16.0.2, and 10.215.144.92 (all these are out on the WAN interface): # tcpdump -nni enp6s0 icmp 07:20:55.508319 IP 10.215.144.48 > 8.8.8.8: ICMP echo request, id 1, seq 1950, length 40 07:20:55.508332 IP 10.215.144.48 > 172.16.0.2: ICMP echo request, id 1, seq 1951, length 40 07:21:00.500377 IP 10.215.144.48 > 8.8.8.8: ICMP echo request, id 1, seq 1969, length 40 07:21:00.500408 IP 10.215.144.48 > 172.16.0.2: ICMP echo request, id 1, seq 1968, length 40 07:21:05.507934 IP 10.215.144.48 > 8.8.8.8: ICMP echo request, id 1, seq 1987, length 40 07:21:05.507966 IP 10.215.144.48 > 172.16.0.2: ICMP echo request, id 1, seq 1988, length 40 07:21:10.499942 IP 10.215.144.48 > 8.8.8.8: ICMP echo request, id 1, seq 2006, length 40 07:21:10.499973 IP 10.215.144.48 > 172.16.0.2: ICMP echo request, id 1, seq 2007, length 40 07:21:15.507474 IP 10.215.144.48 > 172.16.0.2: ICMP echo request, id 1, seq 2025, length 40 07:21:15.507491 IP 10.215.144.48 > 8.8.8.8: ICMP echo request, id 1, seq 2026, length 40 07:21:20.499413 IP 10.215.144.48 > 172.16.0.2: ICMP echo request, id 1, seq 2044, length 40 07:21:20.499427 IP 10.215.144.48 > 8.8.8.8: ICMP echo request, id 1, seq 2045, length 40 07:21:25.507017 IP 10.215.144.48 > 8.8.8.8: ICMP echo request, id 1, seq 2062, length 40 07:21:25.507030 IP 10.215.144.48 > 172.16.0.2: ICMP echo request, id 1, seq 2063, length 40 07:21:30.498980 IP 10.215.144.48 > 8.8.8.8: ICMP echo request, id 1, seq 2080, length 40 07:21:30.499035 IP 10.215.144.48 > 172.16.0.2: ICMP echo request, id 1, seq 2081, length 40 07:21:35.506473 IP 10.215.144.48 > 8.8.8.8: ICMP echo request, id 1, seq 2100, length 40 07:21:35.506484 IP 10.215.144.48 > 172.16.0.2: ICMP echo request, id 1, seq 2099, length 40 There's nothing regarding 10.215.144.92 here, but I'm guessing it could be an arp cache issue on the lan host at 10.215.144.48 because I'm not getting any ICMP requests for that destination on $FW's "lan" interface. I did however delete the arp cache on that host before trying to ping again... oh, well. However, the other two destinations (8.8.8.8 and 172.16.0.2) are listed above. Also note that: - I can ping 8.8.8.8 and 172.16.0.2 (as well as 10.215.144.92 which is on the "other" shorewall gateway) from $FW itself just fine. All 3 dst are on WAN interface. - The "lan" host at 10.215.144.48 has default gateway 10.215.144.91 (which is on the $FW) and it can successfully ping the latter address. - lan-ibs and lan-caib traffic is OK With that in mind, I'm supposing there shouldn't be an arp cache issue here. Furthermore, the arp cache timeout setting of the switch between $FW and the other shorewall gateway is 10 seconds. I also tried changing the wan NIC on $FW just to dicard hardware/driver issues. I used one of the 4 ports on the Intel NIC which is already working OK for the ibs and caib zones. Same results, no joy. Any help is greatly appreciated, as always, but especially now. Thanks, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] traffic issues through firewall router
From: Tom Eastep >> I'm logging everything, even ACCEPTs, but I don't see anything being >> dropped regarding the failing pings. I only see "lan-wan ACCEPT" >> messages for my ICMP tests. > > Then the next step is to determine if the requests are actually being > sent out of the WAN interface (enp6s0) I will be running the following command as soon as I can: # tcpdump -nni enp6s0 icmp Anything else while I'm at it? Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] traffic issues through firewall router
From: Tom Eastep > > Unfortunately, the FW2 configuration has the same shortcoming as did FW1 > - namely, that there are DROP policies that don't log. So it isn't > possible to see what is being dropped and I was unable to come to any > conclusion... Hi, I set up a trimmed-down shorewall system today in order to find the root cause of my woes. I'm attaching 3 files (on Google Drive, actually): - shorewall dump while pinging 8.8.8.8, 10.215.144.92, 172.16.0.2, 10.215.144.91 from "lan" host with IP addr. 10.215.144.48 - kernel messages as the shorewall dump did NOT grab the full data for some reason (ie. the dump was done at 07:24 with counters reset at 07:22, but oddly it did not include syslog messages before 07:24) - the full shorewall config files (in the hope you see something I oversaw) https://drive.google.com/file/d/0B-tpkY1LkI67bUJOU2Y1dTFrUWM/view?usp=sharing https://drive.google.com/file/d/0B-tpkY1LkI67MTRYeVRMTlBXZGc/view?usp=sharing https://drive.google.com/file/d/0B-tpkY1LkI67OXpxQkZzM2RvbFU/view?usp=sharing I'm interested in lan-wan communication for now. $FW-wan is OK. lan-wan does not work. All the pings from 10.215.144.48 listed above FAIL except to 10.215.144.91 which is one of the IP addresses of this shorewall system ($FW). I'm logging everything, even ACCEPTs, but I don't see anything being dropped regarding the failing pings. I only see "lan-wan ACCEPT" messages for my ICMP tests. I don't think the issue is with the other shorewall gateway at 10.215.144.92 because replacing this failing shorewall system with the old one restores all traffic as expected. However, if you require a dump of the other gateway as well then please let me know. I'm also sending a link to the dump taken on the "old" shorewall system while doing the same ping tests: https://drive.google.com/file/d/0B-tpkY1LkI67QU00M29VbWRFb0k/view?usp=sharing Of course, the "rules" are more comlpex than on the failing system, but some settings are identical (eg. interfaces). So now I'm trying to find the diffs between the old/working shorewall system and the new/failing one (you might not see all ACCEPT kernel messages for the same reason described previously, but all's working with the old FW). Any ideas? Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] traffic issues through firewall router
From: Tom Eastep >> >> Sorry to be so slow responding, but I am traveling this week. Probably >> won't be able to look at it until the weekend. > > So am I. > I won't be able to make any changes for the next 2 weeks, so please take your > time. > Enjoy your weekend. No news, bad news. I suppose the dumps and traces I sent last time didn't reveal anything useful. I guess I'll be going back to basics next week, and start out with a "three-interfaces" setup (or maybe even with the "two-interfaces") as in the Samples dir. I'll then gradually add more complexity until I find out where it fails. Thanks, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] traffic issues through firewall router
From: Tom Eastep > Sorry to be so slow responding, but I am traveling this week. Probably> won't > be able to look at it until the weekend. So am I.I won't be able to make any changes for the next 2 weeks, so please take your time.Enjoy your weekend. Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] dropNotSyn
From: Tom Eastep
>
> This happens when Netfilter believes that flow is closed and deletes the
> conntrack entry, while one of the end-points still thinks that the flow
> is alive and sends an RST. In my own ruleset, I handle this with:
>
> RST(ACCEPT) { SOURCE=all, DEST=all }
>
> I have also seen similar problems with SYN,PSH,ACK packets, and added a
> FIN action in 5.1.5. I use it similarly:
>
> FIN(ACCEPT) { SOURCE=ALL, DEST=all }
I added these lines to the rules file:
RST(ACCEPT) { SOURCE=all, DEST=all }
FIN(ACCEPT) { SOURCE=all, DEST=all }
and restarted shorewall.
I'm still getting these in the logs:
Jul 11 11:07:57 inf-gw1 kernel: Shorewall:dropNotSyn:DROP:IN=enp9s5 OUT=
MAC=00:0d:88:cd:7f:c5:00:13:f7:23:ef:b4:08:00 SRC=216.58.214.163
DST=192.168.100.2 LEN=1140 TOS=0x00 PREC=0x00 TTL=55 ID=32907 PROTO=TCP SPT=443
DPT=43579 WINDOW=351 RES=0x00 ACK PSH URGP=0 MARK=0x2
Jul 11 11:07:57 inf-gw1 kernel: Shorewall:dropNotSyn:DROP:IN=enp9s6 OUT=
MAC=00:0d:88:cd:7f:c6:50:67:f0:af:f4:57:08:00 SRC=158.85.58.43
DST=192.168.101.2 LEN=52 TOS=0x00 PREC=0x00 TTL=49 ID=30820 DF PROTO=TCP SPT=80
DPT=16779 WINDOW=514 RES=0x00 ACK RST URGP=0 MARK=0x3
Jul 11 11:07:57 inf-gw1 kernel: Shorewall:dropNotSyn:DROP:IN=enp9s5 OUT=
MAC=00:0d:88:cd:7f:c5:00:13:f7:23:ef:b4:08:00 SRC=216.58.214.163
DST=192.168.100.2 LEN=856 TOS=0x00 PREC=0x00 TTL=55 ID=31520 PROTO=TCP SPT=443
DPT=35305 WINDOW=351 RES=0x00 ACK PSH URGP=0 MARK=0x2
# shorewall version
5.1.5
# grep -v ^# /usr/share/shorewall/action.RST | grep -v ^$
DEFAULTS DROP,-
@1 - - ;;+ -p 6 --tcp-flags RST RST
# grep -v ^# /usr/share/shorewall/action.FIN | grep -v ^$
DEFAULTS ACCEPT,-
@1 - - ;;+ -p 6 --tcp-flags ACK,FIN,PSH ACK,FIN,PSH
Functionally speaking, no user has yet reported issues accessing http or https
sites.
I could ignore these messages although I wasn't getting them in previous
systems.
Vieri
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] traffic issues through firewall router
Hi,
Well, I'm back...
This time, I tried replacing my old internal shorewall firewall with a new one
(host name "inf-fw2" with IP addr. 10.215.144.91).
This router controls access to several zones, and most of the traffic was
allowed as expected. However, traffic through the "wan" interface is failing or
misbehaving.
The "wan" interface on "inf-fw2" is connected to a switch, and from there to a
Shorewall gateway ("inf-gw1" -- the one that was described in my previous
thread with a different host name).
This morning I took special care to make sure that there wouldn't be any ARP
cache issues by connecting to every single switch, and making sure to set low
timeouts.
First off, when I replaced the shorewall firewall I noticed that the "shorewall
start" or "restart" commands would take much longer to run than on the old
firewall. I admit there are a few more rules than on the old system, but it
starteled me when I noticed that the process took about 30 seconds to run on
powerful hardware while it takes around 10-12 seconds on the older system.
Anyway, it's just an observation, and I'll need to dig into this.
Now for the detailed failing connections...
ICMP traffic is OK from 10.215.144.91 (inf-fw2) to any host's IP address in all
zones, including "wan". However, even if the pings reply with low latency from
10.215.144.92 in "wan" zone (inf-gw1), I had trouble connecting via SSH. It
took way too long to log in.
inf-fw2 ~ # ssh 10.215.144.92
Password:
No logon servers
inf-gw1 ~ #
The connection finally succeeded. I suspect it took so long because inf-gw1's
sshd also uses PAM with SAMBA-winbind configured with a PDC in inf-fw2's "lan"
zone. If there are traffic issues between lan and wan then surely this could
explain the long wait and the "No logon servers" message (even if I used a
local root account).
So, in short, ping from 10.215.144.91 (inf-fw2) to all: OK.
ICMP traffic from a host in the "lan" zone with IP address 10.215.144.48 to:
- host with IP address 10.215.134.196 in "ibs" zone is OK
- host with IP address 10.215.9.172 in "caib" zone is OK
- $FW with IP address 10.215.144.91 (inf-fw2) is OK
- host with IP address 10.215.144.92 (inf-gw1) in "wan" zone is FAILING
- host with IP address 8.8.8.8 in "wan" zone and beyond inf-gw1 is FAILING
A tcpdump on inf-fw2's "lan" interface shows that the ICMP requests come in, so
it doesn't seem to be an ARP cache issue. Besides, if it were, I suspect pings
to IP addresses of hosts in the other zones would also fail.
For testing purposes I added this line right at the top of the rules file in
inf-fw2:
ACCEPT lan:10.215.144.48 $FW,wan,dmz all
I'm attaching the shorewall dumps of both inf-gw1 and inf-fw2 while trying to
ping from the host in "lan" zone with IP addr. 10.215.144.48 to 8.8.8.8 and
10.215.144.92.
I'm attaching links instead of files due to ML limitations:
inf-fw2's dump - https://drive.google.com/open?id=0B-tpkY1LkI67ZkdDTGE3bkZwY2c
inf-gw1's dump - https://drive.google.com/open?id=0B-tpkY1LkI67X0ViTU9OU0FUejA
An ICMP tcpdump on inf-gw1's "loc" interface (connected to inf-fw2's "wan"
interface) does not show requests coming from 10.215.144.48.
It did not occur to me to run a tcpdump on inf-fw2's wan interface.
I'm expecting inf-gw1 to reply to ICMP requests from 10.215.144.48 because of
this rule (in inf-gw1):
Ping/ACCEPT loc $FW
I'm also expecting internet hosts such as the one with IP addr. 8.8.8.8 to
reply to ICMP requests because of these rules:
ACCEPT loc:10.215.144.0/22,10.215.246.0/23,10.215.248.0/24
net1:^[${OUT_COUNTRIES_1}],^[${OUT_COUNTRIES_2}],+OUT_WL,+OUT_MANUAL_WL all
ACCEPT loc:10.215.144.0/22,10.215.246.0/23,10.215.248.0/24
net2:^[${OUT_COUNTRIES_1}],^[${OUT_COUNTRIES_2}],+OUT_WL,+OUT_MANUAL_WL all
ACCEPT loc:10.215.144.0/22,10.215.246.0/23,10.215.248.0/24
net3:^[${OUT_COUNTRIES_1}],^[${OUT_COUNTRIES_2}],+OUT_WL,+OUT_MANUAL_WL all
ACCEPT loc:10.215.144.0/22,10.215.246.0/23,10.215.248.0/24
net4:^[${OUT_COUNTRIES_1}],^[${OUT_COUNTRIES_2}],+OUT_WL,+OUT_MANUAL_WL all
where OUT_COUNTRIES_1 contains "US".
# shorewall show capabilities | grep -i geo
Geo IP Match (GEOIP_MATCH): Available
I also forgot to re-enable info logging for loc-net* policies during the dumps.
However, replacing the new inf-fw2 with the old system restores ICMP traffic as
expected. So, I suspect the issue must be in inf-fw2.
The interfaces file in inf-fw2 contains:
lan $IF_LAN routeback
wan $IF_WAN routeback,arp_filter=1
caib$IF_CAIBarp_filter=1
ibs $IF_IBS arp_filter=1
dmz $IF_DMZ routeback,dhcp
- lo -
I hope you don't mind me sending you privately both /var/lib/shorewall/firewall
and sh -x /var/lib/shorewall/firewall reload > trace 2>&1 (inf-fw2) as they
might be of use as in my previous thread.
Thanks,
Vieri
--
[Shorewall-users] dropNotSyn
Hi, I'm getting a considerable amount of log messages such as this one: kernel: Shorewall:dropNotSyn:DROP:IN=enp9s6 OUT= MAC=00:0d:88:cd:7f:c6:50:67:f0:af:f4:57:08:00 SRC=173.194.153.82 DST=192.168.101.2 LEN=40 TOS=0x00 PREC=0x00 TTL=49 ID=29119 PROTO=TCP SPT=443 DPT=58079 WINDOW=0 RES=0x00 RST URGP=0 MARK=0x3 What does it mean exactly? Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] cannot ping through Shorewall 5.1.4.4 gateway
From: Tom Eastep
>
> the file as converted by 'update' will work
> if you just get rid of the masq file. The trace shows the masq file> being
> processed, but it appears to be simply
>
>?IF $FW_TYPE
>?ENDIF
I see now. Shorewall completely ignores the snat file even if masq is "empty".
I had to erase it. Now all's working as expected.
Actually, my masq file isn't empty as it contains the following conditional
clause:
# cat /etc/shorewall/masq
?IF $FW_TYPE
INCLUDE /SAMBA/${FW_TYPE}_extra/masq.FHM
?ENDIF
I'm using this for convenience because I correctly updated to using snat on my
"fw2" gateway. However, my internal "fw1" firewall has a more complicated masq
file that I need more time to update.
So I wrongly thought that if /SAMBA/${FW_TYPE}_extra/masq.FHM was empty then
Shorewall would not apply any masq rules (because the IF statement would
evaluate to TRUE, but would include an empty file), but would proceed with snat
entries.
Anyway, I'm half-way through. One down, one to go (fw1).
I guess I've had several glitches at the same time:
- shorewall snat/masq
- shorewall AUTOMAKE
- hardened kernel and/or hardened package base of my distro
I'd also like to add that the other issue I reported here:
https://sourceforge.net/p/shorewall/mailman/message/35920709/
has been solved now. In that case, even pings from a particular "loc" host to
the shorewall gateway would fail (not masq-related). I suspect the guilty party
could be the kernel or kernel-related tools as everything else is alike. I'll
try to go back to using hardened systems only once I get both shorewall systems
in check.
In any case, thank you very much for all the help.
I'll let you know if I run into any trouble with "fw1"... ;-)
Vieri
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] cannot ping through Shorewall 5.1.4.4 gateway
From: Vieri Di Paola via Shorewall-users > > The next step is to find out how to write my snat files correctly. I tried the following, but it must be wrong: SNAT($IF_ISP4_IP) 0.0.0.0/0 $IF_ISP4 SNAT($IF_ISP3_IP) 0.0.0.0/0 $IF_ISP3 SNAT($IF_ISP2_IP) 0.0.0.0/0 $IF_ISP2 SNAT($IF_ISP1_IP) 0.0.0.0/0 $IF_ISP1 Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] cannot ping through Shorewall 5.1.4.4 gateway
From: Tom Eastep
>
> I see that you are using interface names as the SOURCE in your
> masquerade/snat rules. That has been deprecated for years (and generates
> warnings during compilation).
I've been using Shorewall since 2002/2003. I always used the "masq" file until
now.
The warning didn't bother me much because it says that the interface must be up
and configured beforehand.
My /etc/shorewall/snat includes another file.
# cat /etc/shorewall/snat
?IF $FW_TYPE
INCLUDE /SAMBA/${FW_TYPE}_extra/snat.FHM
?ENDIF
# grep params.TYPE /etc/shorewall/params
INCLUDE /SAMBA/firewall_type/params.TYPE
# cat /SAMBA/firewall_type/params.TYPE
FW_TYPE=gateway
Similar setup for the "masq" file.
Here are the results of the tests you asked for, and a few more:
-rw--- 1 root root 63 Jul 3 08:21 /etc/shorewall/snat
-rw-r--r-- 1 root root 836 Jul 3 08:18 /SAMBA/gateway_extra/snat.FHM
-rw--- 1 root root 63 Jul 3 08:21 /etc/shorewall/masq
-rw-r--r-- 1 root root 0 Jul 3 08:18 /SAMBA/gateway_extra/masq.FHM
10.215.0.0/16 proto kernel scope link src 10.215.144.92
172.16.0.0/28 proto kernel scope link src 172.16.0.2
192.168.147.0/24 scope link
192.168.210.0/23 via 172.16.0.1 metric 9
192.168.212.0/24 via 172.16.0.1 metric 9
I'd like to point out that this morning I emptied my snat file and used my old
masq file instead.
The failing pings started working again.
I can take a breath of fresh air now.
The next step is to find out how to write my snat files correctly.
I tried replacing the interfaces ($IF_LAN, $IF_DMZ) with IP addresses, but that
"didn't seem to work" either. I'll need to study the man page.
Here's the "failing" snat file:
# cat /SAMBA/gateway_extra/snat.FHM
# Rules generated from masq file by Shorewall 5.1.4.4 - Tue Jun 27 11:42:04
CEST 2017
#
SNAT($IF_ISP4_IP) $IF_ISP3_IP $IF_ISP4
SNAT($IF_ISP4_IP) $IF_ISP2_IP $IF_ISP4
SNAT($IF_ISP4_IP) $IF_ISP1_IP $IF_ISP4
SNAT($IF_ISP3_IP) $IF_ISP4_IP $IF_ISP3
SNAT($IF_ISP3_IP) $IF_ISP2_IP $IF_ISP3
SNAT($IF_ISP3_IP) $IF_ISP1_IP $IF_ISP3
SNAT($IF_ISP2_IP) $IF_ISP4_IP $IF_ISP2
SNAT($IF_ISP2_IP) $IF_ISP3_IP $IF_ISP2
SNAT($IF_ISP2_IP) $IF_ISP1_IP $IF_ISP2
SNAT($IF_ISP1_IP) $IF_ISP4_IP $IF_ISP1
SNAT($IF_ISP1_IP) $IF_ISP3_IP $IF_ISP1
SNAT($IF_ISP1_IP) $IF_ISP2_IP $IF_ISP1
SNAT($IF_ISP4_IP) $IF_LAN $IF_ISP4
SNAT($IF_ISP3_IP) $IF_LAN $IF_ISP3
SNAT($IF_ISP2_IP) $IF_LAN $IF_ISP2
SNAT($IF_ISP1_IP) $IF_LAN $IF_ISP1
SNAT($IF_ISP4_IP) $IF_DMZ $IF_ISP4
SNAT($IF_ISP3_IP) $IF_DMZ $IF_ISP3
SNAT($IF_ISP2_IP) $IF_DMZ $IF_ISP2
SNAT($IF_ISP1_IP) $IF_DMZ $IF_ISP1
Here's the "working" masq file:
# cat /SAMBA/gateway_extra/masq.FHM
#INTERFACE SOURCE ADDRESS PROTO PORT(S) IPSEC
MARK
$IF_ISP4$IF_ISP3_IP $IF_ISP4_IP
$IF_ISP4$IF_ISP2_IP $IF_ISP4_IP
$IF_ISP4$IF_ISP1_IP $IF_ISP4_IP
#
$IF_ISP3$IF_ISP4_IP $IF_ISP3_IP
$IF_ISP3$IF_ISP2_IP $IF_ISP3_IP
$IF_ISP3$IF_ISP1_IP $IF_ISP3_IP
#
$IF_ISP2$IF_ISP4_IP $IF_ISP2_IP
$IF_ISP2$IF_ISP3_IP $IF_ISP2_IP
$IF_ISP2$IF_ISP1_IP $IF_ISP2_IP
#
$IF_ISP1$IF_ISP4_IP $IF_ISP1_IP
$IF_ISP1$IF_ISP3_IP $IF_ISP1_IP
$IF_ISP1$IF_ISP2_IP $IF_ISP1_IP
#
$IF_ISP4$IF_LAN $IF_ISP4_IP
$IF_ISP3$IF_LAN $IF_ISP3_IP
$IF_ISP2$IF_LAN $IF_ISP2_IP
$IF_ISP1$IF_LAN $IF_ISP1_IP
#
$IF_ISP4$IF_DMZ $IF_ISP4_IP
$IF_ISP3$IF_DMZ $IF_ISP3_IP
$IF_ISP2$IF_DMZ $IF_ISP2_IP
$IF_ISP1$IF_DMZ $IF_ISP1_IP
> Please send me (privately), your /var/lib/shorewall/firewall file.
OK.
Vieri
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] cannot ping through Shorewall 5.1.4.4 gateway
Hi, This is message 4 (last) related to previous message in same thread. Vieri swdump_10.215.144.7.part2 Description: Binary data -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] cannot ping through Shorewall 5.1.4.4 gateway
Hi, This is message 2 related to previous message in same thread. Vieri swdump_172.16.0.1.part2 Description: Binary data -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] cannot ping through Shorewall 5.1.4.4 gateway
Hi, This is message 3 related to previous message in same thread. Vieri swdump_10.215.144.7.part1 Description: Binary data swtrace_10.215.144.7.gz Description: application/gzip swtrace_10.215.144.7_TRACE.gz Description: application/gzip tcpdump_10.215.144.7.gz Description: application/gzip -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] cannot ping through Shorewall 5.1.4.4 gateway
From: Tom Eastep
>
> Okay -- let's try this:
>
> a) set LOG_BACKEND=LOG in shorewall.conf
> b) shorewall reload
> c) shorewall iptrace -s 172.16.0.1 -p icmp
> d) Try the ping that fails from fw1
> e) shorewall noiptrace -s 172.16.0.1 -p icmp
> d) forward the part of the shorewall log that captures the time covered
> by this test
Note that LOG_BACKEND was already set to LOG. I did not have to change that.
# grep LOG_BACKEND /etc/shorewall/shorewall.conf
LOG_BACKEND=LOG
I created the following script on "fw2" to do what you asked.
# cat sw_trace.sh
#!/bin/bash
srcip=$1
[ ${#srcip} -eq 0 ] && srcip=172.16.0.1
locif=enp10s0
echo '' > /var/log/shorewall/info.log
shorewall reset
shorewall reload
shorewall iptrace -s $srcip -p icmp
echo "Now start pinging from $srcip to 8.8.8.8 and press ENTER"
read
tcpdump -n -c 30 -i $locif icmp and host $srcip > ./tcpdump_$srcip
sleep 2
shorewall noiptrace -s $srcip -p icmp
shorewall dump > ./swdump_$srcip
cp /var/log/shorewall/info.log ./swtrace_$srcip
gzip --best ./swtrace_$srcip
I then realized that the trace dumps were incomplete, so I retrieved them from
/var/log/messages with:
grep "TRACE:" /var/log/messages
I thought LOGFILE=/var/log/shorewall/info.log was enough in shorewall.conf, but
this is the least of my problems right now. ;-)
So I hope you don't mind if I send 2 trace files. One was taken from
/var/log/shorewall/info.log, the other from /var/log/messages (according to
timestamps).
I'm attaching all the results in this and later posts (due to message size
limits in the ML).
I also did new shorewall dumps because of a few minor changes.
Any *part* file name I attach should be rebuilt with:
cat FILE.PART1 FILE.PART2 ... > FILE.gz
I did 2 tests. One was from "fw1" at 172.16.0.1, the other was from a host in
one of fw1's zones (IP addr. 10.215.144.7). Failing ping requests go to 8.8.8.8.
The tcpdump tests show that both the host at 10.215.144.7 and fw1 can ping fw2
just fine. Trying to access the providers seems to be the issue here.
Thanks,
Vieri
swdump_172.16.0.1.part1
Description: Binary data
swtrace_172.16.0.1.gz
Description: application/gzip
swtrace_172.16.0.1_TRACE.gz
Description: application/gzip
tcpdump_172.16.0.1.gz
Description: application/gzip
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] cannot ping through Shorewall 5.1.4.4 gateway
From: Tom Eastep > > root@debianvm:/etc/shorewall# shorewall start [...] > Compiling /etc/shorewall/providers... > ERROR: Providers interfaces may not specify 'routefilter' when > USE_DEFAULT_RT=Yes /etc/shorewall/providers (line 10) Do you mean that it's fixed in 5.1.5, or that you cannot reproduce the issue I reported? I redid the same, but this time in "interfaces" I not only have routefilter but also rpfilter (for the sake of testing -- not that I need both options). Now I'm getting a different error with "shorewall check", but "shorewall start" still doesn't complain and exits successfully. If I run the following: shorewall stop > swtest 2>&1 3>&1 shorewall status >> swtest 2>&1 3>&1 shorewall check >> swtest 2>&1 3>&1 echo ">>> shorewall start:" >> swtest 2>&1 3>&1 shorewall start >> swtest 2>&1 3>&1 echo ">>> interfaces:" >> swtest 2>&1 3>&1 cat interfaces >> swtest echo ">>> providers:" >> swtest 2>&1 3>&1 cat providers >> swtest I get this: Stopping Shorewall Processing /etc/shorewall/stop ... Processing /etc/shorewall/tcclear ... Preparing iptables-restore input... Running /sbin/iptables-restore... IPv4 Forwarding Enabled Processing /etc/shorewall/stopped ... done. Shorewall-5.1.4.4 Status at inf-fw2 - Wed Jul 5 08:59:27 CEST 2017 Shorewall is stopped State:Stopped Wed Jul 5 08:59:27 CEST 2017 (/var/lib/shorewall/firewall compiled Wed Jul 5 08:53:34 CEST 2017 by Shorewall version 5.1.4.4) Checking using Shorewall 5.1.4.4... Processing /etc/shorewall/params ... Processing /etc/shorewall/shorewall.conf... Loading Modules... Checking /etc/shorewall/zones... Checking /etc/shorewall/interfaces... ERROR: The 'routefilter', 'sfilter' and 'rpfilter' options are mutually exclusive /etc/shorewall/interfaces (line 2) >>> shorewall start: Starting Shorewall Initializing... Processing /etc/shorewall/init ... Processing /etc/shorewall/tcclear ... Setting up ARP filtering... Setting up Route Filtering... Setting up Martian Logging... Setting up Accept Source Routing... Setting up log backend Setting up Proxy ARP... Adding Providers... Preparing iptables-restore input... Running /sbin/iptables-restore ... IPv4 Forwarding Enabled Processing /etc/shorewall/start ... Processing /etc/shorewall/started ... done. >>> interfaces: #ZONE INTERFACE OPTIONS net4$IF_ISP4 optional,tcpflags,nosmurfs,logmartians,proxyarp=0,arp_ignore=1,sourceroute=0,rpfilter,routefilter net3$IF_ISP3 optional,tcpflags,nosmurfs,logmartians,proxyarp=0,arp_ignore=1,sourceroute=0,rpfilter,routefilter net2$IF_ISP2 optional,tcpflags,nosmurfs,logmartians,proxyarp=0,arp_ignore=1,sourceroute=0,rpfilter,routefilter net1$IF_ISP1 optional,tcpflags,nosmurfs,logmartians,proxyarp=0,arp_ignore=1,sourceroute=0,rpfilter,routefilter dmz $IF_DMZ routeback loc $IF_LAN routeback >>> providers: #NAME NUMBER MARKDUPLICATE INTERFACE GATEWAY OPTIONSCOPY ISP11 1 - $IF_ISP1$IF_ISP1_GW track,balance=3,persistent ISP22 2 - $IF_ISP2$IF_ISP2_GW track,balance=2,persistent ISP33 3 - $IF_ISP3$IF_ISP3_GW track,balance=1,persistent ISP44 4 - $IF_ISP4$IF_ISP4_GW track,balance=1,persistent -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] cannot ping through Shorewall 5.1.4.4 gateway
Hi, I'm sending the second part of the shorewall dump. # cat xaa xab > swdump.gz Vieri xab Description: Binary data -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] cannot ping through Shorewall 5.1.4.4 gateway
From: Tom Eastep
>
> Doesn't look to me as though any of those rules would match the pings
> that don't work. And there are packets beging silently dropped because
> you have not specified any logging for your loc->net* policies.
I had these rules when I did that dump:
ACCEPT loc:10.215.144.0/22,10.215.246.0/23,10.215.248.0/24
net1:^[${OUT_COUNTRIES_1}],^[${OUT_COUNTRIES_2}],+OUT_WL,+OUT_MANUAL_WL all
ACCEPT loc:10.215.144.0/22,10.215.246.0/23,10.215.248.0/24
net2:^[${OUT_COUNTRIES_1}],^[${OUT_COUNTRIES_2}],+OUT_WL,+OUT_MANUAL_WL all
ACCEPT loc:10.215.144.0/22,10.215.246.0/23,10.215.248.0/24
net3:^[${OUT_COUNTRIES_1}],^[${OUT_COUNTRIES_2}],+OUT_WL,+OUT_MANUAL_WL all
ACCEPT loc:10.215.144.0/22,10.215.246.0/23,10.215.248.0/24
net4:^[${OUT_COUNTRIES_1}],^[${OUT_COUNTRIES_2}],+OUT_WL,+OUT_MANUAL_WL all
ACCEPT loc:172.16.0.1 $FW all
ACCEPT loc:172.16.0.1 net1 all
ACCEPT loc:172.16.0.1 net2 all
ACCEPT loc:172.16.0.1 net3 all
If I take into consideration just the first failing ping (from host with IP
addr. 172.16.0.1), I was expecting it to work because of this in all loc-net*
chains:
ACCEPT all -- * * 172.16.0.1 0.0.0.0/0
In any case, in order to avoid confusion, and get more debugging information I
followed your suggestion:
# grep ^loc /SAMBA/gateway_extra/policy.FHM
loc net1DROPinfo
loc net2DROPinfo
loc net3DROPinfo
loc net4DROPinfo
loc dmz DROPinfo
loc $FW DROPinfo
loc all DROPinfo
I also added this rule at the very top of the rules file in order to make sure
I get a theoretical match:
ACCEPT:info loc:172.16.0.1,10.215.144.92,10.215.144.7
net1,net2,net3.net4 all
I restarted/reset shorewall, but the ping tests still fail. I'm unable to find
anything useful in /var/log.
I can still confirm that a tcpdump on the "loc" interface shows ICMP requests
coming in, but no replies.
I'm attaching another dump taken while performing a ping to 8.8.8.8 from two
hosts in the "loc" zone with IP addresses 172.16.0.1 and 10.215.144.7.
Note that I'm posting 2 consecutive messages to this list so I can pass the
message size limit. You just need to do this to get the full dump:
# cat xaa xab > swdump.gz
Finally, since I'm a bit desperate now... ;-) I'm also attaching a quick "diff"
of most of the shorewall config files between shorewall host "a" that's
"working OK" and shorewall host "b" that's failing.
Host a is running:
Linux 4.8.17-hardened-r2
shorewall version 5.0.15.6
Host b is running:
Linux 4.9.16-gentoo
shorewall version 5.1.4.4
shorewall.conf is mostly default, except for the LOG path and the dynamic
blacklist.
Vieri
ab.diff.gz
Description: application/gzip
xaa
Description: Binary data
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] cannot ping through Shorewall 5.1.4.4 gateway
OK, never mind my question regarding ip_forward. I just discovered IP_FORWARDING=[On|Off|Keep] in shorewall.conf. Thanks, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] cannot ping through Shorewall 5.1.4.4 gateway
From: Tom Eastep > >> Checking /etc/shorewall/providers... ERROR: Providers interfaces may >> not specify 'routefilter' when USE_DEFAULT_RT=Yes > > That error is expected as 'routefilter' causes Martians when > USE_DEFAULT_RT=Yes. Use 'rpfilter' instead. OK, so I guess "shorewall start" should also throw that error and abort. If not, continue, but warn about it. In "interfaces" I'm now using options such as: net4enp7s0f0 optional,tcpflags,nosmurfs,logmartians,proxyarp=0,arp_ignore=1,sourceroute=0,rpfilter However, if I restart shorewall and dump afterwards I get this result: # grep /rp_filter swdump /proc/sys/net/ipv4/conf/all/rp_filter = 0 /proc/sys/net/ipv4/conf/default/rp_filter = 0 /proc/sys/net/ipv4/conf/enp10s0/rp_filter = 0 /proc/sys/net/ipv4/conf/enp5s0/rp_filter = 0 /proc/sys/net/ipv4/conf/enp6s0/rp_filter = 0 /proc/sys/net/ipv4/conf/enp7s0f0/rp_filter = 0 /proc/sys/net/ipv4/conf/enp7s0f1/rp_filter = 0 /proc/sys/net/ipv4/conf/enp7s0f2/rp_filter = 0 /proc/sys/net/ipv4/conf/enp7s0f3/rp_filter = 0 /proc/sys/net/ipv4/conf/enp8s5/rp_filter = 0 /proc/sys/net/ipv4/conf/lo/rp_filter = 0 # shorewall show capabilities | grep RPFilter RPFilter Match (RPFILTER_MATCH): Available # shorewall version 5.1.4.4 Why isn't /proc/sys/net/ipv4/conf/enp7s0f0/rp_filter = 1? Am I required to set this with sysctl? Also, I'm currently checking and enabling /proc/sys/net/ipv4/ip_forward via sysctl. Is there a reason why shorewall doesn't enable it directly when required? If shorewall can't do that directly then maybe "shorewall check" could check the value of ip_forward, and warn the user to enable it if required. Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] cannot ping through Shorewall 5.1.4.4 gateway
From: Tom Eastep
>
> You have failed to enable IP forwarding on fw2.
Sorry, my mistake. However, I'm still getting the same results after setting up
IP forwarding (no ICMP replies). I'm attaching 2 shorewall dumps taken on the
same shorewall system ("fw2" in my case). During the first dump, I'm trying to
ping to 8.8.8.8 from "fw1" with IP addr. 172.168.0.1/10.215.144.91. During the
second dump (swdump_7), I'm trying to ping to 8.8.8.8 from 10.215.144.7 (a
host's IP addr. behind "fw1").
I'm still seeing echo requests with tcpdump on "fw2" but no replies.
Pings from "fw2" to 8.8.8.8 work fine.
> No -- what error are you seeing?
Checking /etc/shorewall/providers...
ERROR: Providers interfaces may not specify 'routefilter' when
USE_DEFAULT_RT=Yes
Vieri
swdump.gz
Description: application/gzip
swdump_7.gz
Description: application/gzip
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] cannot ping through a shorewall router
Hi,
I recently posted a similar issue. This case is slightly different.
I have 2 shorewall routers fw1 and gw1. Both are 5.0.
Everything is working as expected except for one particular case that's driving
me crazy.
I can't ping from gw1's IP addr. 10.215.144.92 on it's "loc" zone interface to
a host with IP addr. 10.215.145.240 within fw1's "lan" zone.
Also, I can't ping from the host with IP addr. 10.215.145.240 in fw1's "lan"
zone to 8.8.8.8 which should be reachable from any of net{1,2,3,4} in gw1.
I'm attaching shorewall dumps of both systems.
Vieri
swdump_fw1_5.0.gz
Description: application/gzip
swdump_gw1_5.0.gz
Description: application/gzip
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] cannot ping through Shorewall 5.1.4.4 gateway
Hi,
I'm attaching two shorewall dumps:
1) swdump_fw1 was taken from a shorewall firewall/router from which I tried to
ping 8.8.8.8 ($FW IP addr. 10.215.144.91/172.16.0.1)
2) swdump_fw2 was taken from another shorewall firewall/router acting as a
gateway to ISPs in which the ICMP traffic should have gone out and back in ($FW
IP addr. 10.215.144.92)
The shorewall firewall in "fw1" has not been touched in any way as it is in
production. Pings et al. were OK when I was using another Shorewall system for
"fw2". I started having issues when replacing "fw2", so obviously there must be
a mistake there.
The failing traffic during the dump was:
ping from 10.215.144.91 in fw1 (which is in "loc" zone for "fw2") to 8.8.8.8
(which is in any of net{1,2,3,4} zones in "fw2")
A tcpdump on the "loc" interface in "fw2" shows ICMP traffic coming from "fw1"
but only one-way.
Just in case you're wondering, placing back the "old fw2" shorewall firewall
makes the pings flow again (ie., there's no apparent problem accessing the
internet providers). I'd also like to point out that the "new fw2" was using
identical "providers" settings as the "old fw2", except for the fact that I
removed the routefilter option as I had USE_DEFAULT_RT=Yes in shorewall.conf.
BTW if I set the routefilter option on a provider's interface in "interfaces",
and USE_DEFAULT_RT is Yes then "shorewall check" complains with an error.
However, "shorewall start" does not complain and is really started (status is
started). Is this expected?
Thanks,
Vieri
dump_fw1.gz
Description: application/gzip
dump_fw2.gz
Description: application/gzip
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] ping test fails through firewall (attaching smaller dump)
From: Tom Eastep > > I see no evidence of any ping traffic between the time that the counters > were reset and when the dump was taken. What address did you ping and > from where? I rebooted $FW without changing any settings, and the pings started working. I don't know why, yet. Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] trouble running shorewall update
Sorry about that. Issue solved. "shorewall update" could not know that I was migrating from FORMAT 2 in interfaces file. It wasn't for the "optional" option, but for the fact that I was not using the BROADCAST column in FORMAT 1. Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] trouble running shorewall update
Hi, # shorewall update Updating Shorewall configuration to 5.1.4.4... Processing /etc/shorewall/params ... Processing /etc/shorewall/shorewall.conf... No update required to configuration file /etc/shorewall/shorewall.conf; /etc/shorewall/shorewall.conf.bak not saved Loading Modules... Converting 'FORMAT', 'SECTION' and 'COMMENT' lines to compiler directives... Checking /etc/shorewall/zones... Checking /etc/shorewall/interfaces... ERROR: Invalid BROADCAST address /etc/shorewall/interfaces (line 1) This happens when: # cat interfaces net4$IF_ISP4optional[...] [...] Without "optional" there's no error. Is this expected? # shorewall version 5.1.4.4 Thanks, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] ping test fails through firewall (attaching smaller dump)
I tried to momentarily downgrade shorewall to:
# shorewall version
5.0.15.6
Running "shorewall check" on the same config as in my previous post gives me
this error:
ERROR: Invalid parameter (DROP),Multicast(DROP)
/usr/share/shorewall/action.Broadcast (line 1)
from (line EOF)
"shorewall -vv" shows this:
Compiling /usr/share/shorewall/action.Broadcast for chain Broadcast...
ERROR: Invalid parameter (DROP),Multicast(DROP)
/usr/share/shorewall/action.Broadcast (line 1)
from (line EOF)
"shorewall trace start":
Compiling /usr/share/shorewall/action.Broadcast for chain Broadcast...
SYS> /sbin/iptables -w -F fooX19614
SYS> /sbin/iptables -w -X fooX19614
SYS> /sbin/iptables -w -F foo1X19614
SYS> /sbin/iptables -w -X foo1X19614
SYS> /sbin/iptables -w -t mangle -F fooX19614
SYS> /sbin/iptables -w -t mangle -X fooX19614
SYS> /sbin/iptables -w -t nat -F fooX19614
iptables: No chain/target/match by that name.
SYS> /sbin/iptables -w -t nat -X fooX19614
iptables: No chain/target/match by that name.
SYS> /sbin/iptables -w -t raw -F fooX19614
SYS> /sbin/iptables -w -t raw -X fooX19614
ERROR: Invalid parameter (DROP),Multicast(DROP)
/usr/share/shorewall/action.Broadcast (line 1)
from (line EOF) at /usr/share/shorewall/Shorewall/Config.pm line 1469.
Shorewall::Config::fatal_error("Invalid parameter (DROP),Multicast(DROP)")
called at /usr/share/shorewall/Shorewall/Config.pm line 2162
Shorewall::Config::split_list3("DROP),Multicast(DROP", "parameter") called at
/usr/share/shorewall/Shorewall/Config.pm line 3517
Shorewall::Config::push_action_params("Broadcast", HASH(0x329ee38),
"DROP),Multicast(DROP", "none", "", "fw-wan") called at
/usr/share/shorewall/Shorewall/Rules.pm line 1917
Shorewall::Rules::process_action(SCALAR(0x18f2928), REF(0x18f2988), "fw-wan")
called at /usr/share/shorewall/Shorewall/Rules.pm line 2294
Shorewall::Rules::use_policy_action("Broadcast:none:::DROP),Multicast(DROP",
"fw-wan") called at /usr/share/shorewall/Shorewall/Rules.pm line 915
Shorewall::Rules::add_policy_rules(HASH(0x2073d08), "DROP", 6,
"Broadcast:none:::DROP),Multicast(DROP", "") called at
/usr/share/shorewall/Shorewall/Rules.pm line 973
Shorewall::Rules::complete_policy_chain(HASH(0x2073d08), "fw", "wan") called at
/usr/share/shorewall/Shorewall/Rules.pm line 1045
Shorewall::Rules::complete_policy_chains() called at
/usr/share/shorewall/Shorewall/Compiler.pm line 857
Shorewall::Compiler::compiler("script", "/var/lib/shorewall/.start",
"directory", "", "verbosity", 1, "timestamp", 0, ...) called at
/usr/share/shorewall/compiler.pl line 142
eval() called 26 times
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] ping test fails through firewall (attaching smaller dump)
From: Tom Eastep > > There is a bug in 5.1.4.3 :-( Patch attached. > >patch /usr/share/shorewall/Shorewall/Providers.pm < FALLBACK.patch Thanks Tom. That fixed the startup issue. I'm still having trouble making a simple ping work in the same environment but with shorewall 5.1.4.4. I'm unable to ping from host with IP addr. 10.215.144.48 in "lan" zone and host with IP addr. 192.168.212.92 in "dmz" zone. I've even enabled info messages, but I'm unable to get any in my log file. I only get that Shorewall has been started. I'm attaching the shorewall dump. Thanks, Vieri swdump.gz Description: application/gzip -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] ping test fails through firewall (attaching smaller dump)
Following up on my previous message, a shorewall trace restart shows the following messages at the end: + '[' -n 'via 172.20.11.49 dev enp7s0f3 nexthop via 172.28.17.110 dev enp7s0f2 weight 1 ' ']' + run_ip route replace default scope global table 253 via 172.20.11.49 dev enp7s0f3 nexthop via 172.28.17.110 dev enp7s0f2 weight 1 + ip -4 route replace default scope global table 253 via 172.20.11.49 dev enp7s0f3 nexthop via 172.28.17.110 dev enp7s0f2 weight 1 RTNETLINK answers: Invalid argument + error_message 'ERROR: Command "ip -4 route' replace default scope global table 253 via 172.20.11.49 dev enp7s0f3 nexthop via 172.28.17.110 dev enp7s0f2 weight '1" Failed' + echo ' ERROR: Command "ip -4 route' replace default scope global table 253 via 172.20.11.49 dev enp7s0f3 nexthop via 172.28.17.110 dev enp7s0f2 weight '1" Failed' ERROR: Command "ip -4 route replace default scope global table 253 via 172.20.11.49 dev enp7s0f3 nexthop via 172.28.17.110 dev enp7s0f2 weight 1" Failed + return 1 + stop_firewall + case $COMMAND in + set +x /usr/share/shorewall/lib.common: line 93: 26111 Terminated $SHOREWALL_SHELL $script $options $@ I can send the full trace if required. shorewall -vv doesn't seem to report any issues. Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] ping test fails through firewall (attaching smaller dump)
Regarding my previous post, I switched to a new system with the same configuration, but with a non-hardened, and more recent kernel (4.9.16). Shorewall version is 5.1.4.3. This time, shorewall check is OK but shorewall start fails with: RTNETLINK answers: Invalid argument ERROR: Command "ip -4 route replace default scope global table 253 via 172.20.11.49 dev enp7s0f3 nexthop via 172.28.17.110 dev enp7s0f2 weight 1" Failed /usr/share/shorewall/lib.common: line 93: 7475 Terminated $SHOREWALL_SHELL $script $options $@ Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] ping test fails through firewall (attaching smaller dump)
Hi, I set up a test environment in order to pinpoint issues before going live. I have a live Shorewall gateway connected to a test Shorewall Firewall/router (from now on $FW) through a NIC. I then have test hosts in different zones, and I'm trying to ping them. On the Shorewall Gateway, there is no ICMP traffic according to: # tcpdump -n -i enp11s0 icmp On $FW I can ping any host Ip address, including the ones listed below. No issues there. However, the following ping requests fail from a host in the LAN zone with IP address 10.215.144.48 to: - 10.215.144.92 (on the Shorewall Gateway, in $FW's WAN zone) - 172.16.0.12 (on the Shorewall Gateway, in $FW's WAN zone) - 192.168.212.92 (in $FW's DMZ zone) The following ping requests succeed from a host in the LAN zone with IP address 10.215.144.48 to: - 10.215.144.91 ($FW, LAN NIC IP addr.) - 172.16.0.11 ($FW, WAN NIC IP addr.) The only unreplied ARP request I see in $FW is "who-has 10.215.144.92 tell 10.215.144.48" on the LAN interface. On the Shorewall Gateway I do not see any output when running this command: # tcpdump -n -i enp11s0 arp and host 10.215.144.48 Note that the Shorewall Gateway rules allow ICMP traffic. I'm attaching the dump to see if you can help me find where I made a mistake. Thanks, Vieri swdump.test.gz Description: application/gzip -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Tarpit Guide?
From: Brent Gordon > Is there a guide on how to set up TARPIT on Shorewall? Maybe setting it > up is simpler than I think, but I don't want to risk making a major > > mistake. I'm running Shorewall 5.0.4. I used tarpit with 5.0 and a rule such as: TARPIT(tarpit):info wan $FW tcp 22 (disable SSH access from wan) You need to check for TARPIT support: # shorewall show capabilities | grep TARPIT TARPIT Target (TARPIT_TARGET): Available Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] routing issue with rtrules (with SW dump)
From: Simon Matter >> This is the failing ping performed on $FW: >> >> # ping -I 10.215.246.91 10.215.236.123 -c 1 > > Last week you asked the list about a possible arp cache issue. Did you > find a solution there or is the issue you report now probably related? > > Since you didn't let us know what came out last week I'm not sure both > things are related or not. Hi Simon, I didn't follow up on my last issue regarding arp cache because I ran into several critical issues. I noticed that my main switch had a default cache timeout of 300 seconds. I lowered it to 1s before doing the FW change, and set it back to 300s afterwards. This helped because the change was very fast, and the clients connected to the first layer of switches were quickly working again. However, some other clients had trouble, and had to be rebooted. In any case, traffic was apparently flowing as expected in all zones except for one (the WAN zone, or internet access). Since I wasn't able to pinpoint the cause of the problem in due time, I had to revert to the old FW. I wasn't even able to do a correct "shorewall dump" as specified in the troubleshooting guide since I confused "shorewall reset" with "shorewall clear". :-( The ping issue I reported here was occurring after falling back to the old FW. I mean *really* after -- at least three hours later. Since this wasn't critical I ignored it until I tested it again this morning. This time it worked as expected. Do you know how I can relate this to ARP (this is the old FW, and it's trying to ping using one of its own IP addresses on the LAN NIC to a remote host's IP address through another NIC)? Also, how can I deal with this if it ever occurs again? Should I run "arp -d *" on $FW? Or is the issue within the ARP cache of the swithes beyond my "other NIC" which are remotely administered, and to which I do not have access (except maybe if I unplug them). This leads me to another question. You previously mentioned that proxyarp in Linux can lead to similar issues. I was/am using proxyarp=1 in shorewall (old FW) with this in my interfaces file: lan $IF_LAN routeback,proxyarp=1,arp_filter=1 wan $IF_WAN routeback,proxyarp=1,arp_filter=1 caib$IF_CAIBarp_filter=1 ibs $IF_IBS arp_filter=1 dmz $IF_DMZ routeback,dhcp,proxyarp=1 - lo - BTW on the other end of $IF_WAN there's another Shorewall server acting as a gateway/router/firewall. This is its interfaces file: net4$IF_ISP4 optional,tcpflags,nosmurfs,routefilter=0,logmartians,proxyarp=0,arp_ignore=1,sourceroute=0 net3$IF_ISP3 optional,tcpflags,nosmurfs,routefilter=0,logmartians,proxyarp=0,arp_ignore=1,sourceroute=0 net2$IF_ISP2 optional,tcpflags,nosmurfs,routefilter,logmartians,proxyarp=0,arp_ignore=1,sourceroute=0 net1$IF_ISP1 optional,tcpflags,nosmurfs,routefilter,logmartians,proxyarp=0,arp_ignore=1,sourceroute=0 dmz $IF_DMZ routeback loc $IF_LAN routeback I used proxyarp on the FW because I had a particular use case a while back, but I should not require it anymore. I was hoping to use this interfaces file instead: lan $IF_LAN routeback,arp_filter=1 wan $IF_WAN routeback,arp_filter=1 caib $IF_CAIB arp_filter=1 ibs $IF_IBS arp_filter=1 dmz $IF_DMZ routeback,dhcp - lo - However, when I replaced the old FW with the new one without "proxyarp=1" connections were not working within my zones. When I re-enabled "proxyarp=1" all zone traffic worked except for LAN2WAN. Anyway, I'll post a dump later on if I get the chance. In the meantime, I'd like to know how to truly disable proxyarp on a system that had it enabled previously. Removing "proxyarp=1" might not be enough. I might need to use "proxyarp=0"? Or should I echo 0 > /proc/sys/net/ipv4/conf/DEVICE/proxy_arp? I'm asking because even after removing "proxyarp=1" I still have this in the system: # cat /proc/sys/net/ipv4/conf/$IF_LAN/proxy_arp 1 # cat /proc/sys/net/ipv4/conf/$IF_WAN/proxy_arp 1 # cat /proc/sys/net/ipv4/conf/$IF_DMZ/proxy_arp 1 Thanks, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] routing issue with rtrules (with SW dump)
Hi, I used to ping correctly from the shorewall FW to a remote host's IP address in particular zone (CAIB, see below). Somehow, this ping is failing now, and I don't know if it's a config error on my behalf or that the remote host stopped replying. This is the failing ping performed on $FW: # ping -I 10.215.246.91 10.215.236.123 -c 1 PING 10.215.236.123 (10.215.236.123) from 10.215.246.91 : 56(84) bytes of data. --- 10.215.236.123 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms Still on $FW, I can ping the same IP address from a differnet source IP address: # ping -I 10.215.144.91 10.215.236.123 -c 1 PING 10.215.236.123 (10.215.236.123) from 10.215.144.91 : 56(84) bytes of data. 64 bytes from 10.215.236.123: icmp_seq=1 ttl=60 time=2.08 ms --- 10.215.236.123 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 2.084/2.084/2.084/0.000 ms I have this in rtrules: # grep "10.215.232.0/21" rtrules 10.215.144.0/23 10.215.232.0/21 IBS 11420 - 10.215.232.0/21 CAIB11615 where IBS and CAIB are providers for the same 10.215.232.0/21 network (can be used as load-balanced links or failover). # shorewall show routing | grep 10.215.232.0 11420: from 10.215.144.0/23 to 10.215.232.0/21 lookup IBS 11615: from all to 10.215.232.0/21 lookup CAIB Note that pinging 10.215.236.123 from a LAN host with IP address 10.215.246.* is successful. On $FW: # traceroute -s 10.215.246.91 10.215.236.123 traceroute to 10.215.236.123 (10.215.236.123), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * *^C # traceroute -s 10.215.144.91 10.215.236.123 traceroute to 10.215.236.123 (10.215.236.123), 30 hops max, 60 byte packets 1 172.28.17.110 (172.28.17.110) 0.694 ms 1.396 ms 1.408 ms 2 10.128.12.0 (10.128.12.0) 2.096 ms 2.558 ms 2.816 ms 3 172.20.30.2 (172.20.30.2) 1.770 ms 1.763 ms 1.732 ms 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 *^C # traceroute -s 172.20.11.62 10.215.236.123 traceroute to 10.215.236.123 (10.215.236.123), 30 hops max, 60 byte packets 1 172.20.11.50 (172.20.11.50) 0.518 ms 0.612 ms 0.569 ms 2 172.20.4.210 (172.20.4.210) 2.008 ms 2.009 ms 1.966 ms 3 10.215.4.242 (10.215.4.242) 6.316 ms 6.314 ms 6.317 ms 4 172.20.4.14 (172.20.4.14) 8.094 ms 8.028 ms 8.549 ms^C I'm attaching a shorewall dump while performing the ping from $FW (10.215.246.91) to 10.215.236.123. Thanks, Vieri swdump.gz Description: application/gzip -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] routing issue with rtrules
Hi, I used to ping correctly from the shorewall FW to a remote host's IP address in particular zone (CAIB, see below). Somehow, this ping is failing now, and I don't know if it's a config error on my behalf or that the remote host stopped replying. This is the failing ping performed on $FW: # ping -I 10.215.246.91 10.215.236.123 -c 1 PING 10.215.236.123 (10.215.236.123) from 10.215.246.91 : 56(84) bytes of data. --- 10.215.236.123 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms Still on $FW, I can ping the same IP address from a differnet source IP address: # ping -I 10.215.144.91 10.215.236.123 -c 1 PING 10.215.236.123 (10.215.236.123) from 10.215.144.91 : 56(84) bytes of data. 64 bytes from 10.215.236.123: icmp_seq=1 ttl=60 time=2.08 ms --- 10.215.236.123 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 2.084/2.084/2.084/0.000 ms I have this in rtrules: # grep "10.215.232.0/21" rtrules 10.215.144.0/23 10.215.232.0/21 IBS 11420 - 10.215.232.0/21 CAIB11615 where IBS and CAIB are providers for the same 10.215.232.0/21 network (can be used as load-balanced links or failover). # shorewall show routing | grep 10.215.232.0 11420: from 10.215.144.0/23 to 10.215.232.0/21 lookup IBS 11615: from all to 10.215.232.0/21 lookup CAIB Note that pinging 10.215.236.123 from a LAN host with IP address 10.215.246.* is successful. On $FW: # traceroute -s 10.215.246.91 10.215.236.123 traceroute to 10.215.236.123 (10.215.236.123), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * *^C # traceroute -s 10.215.144.91 10.215.236.123 traceroute to 10.215.236.123 (10.215.236.123), 30 hops max, 60 byte packets 1 172.28.17.110 (172.28.17.110) 0.694 ms 1.396 ms 1.408 ms 2 10.128.12.0 (10.128.12.0) 2.096 ms 2.558 ms 2.816 ms 3 172.20.30.2 (172.20.30.2) 1.770 ms 1.763 ms 1.732 ms 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 *^C # traceroute -s 172.20.11.62 10.215.236.123 traceroute to 10.215.236.123 (10.215.236.123), 30 hops max, 60 byte packets 1 172.20.11.50 (172.20.11.50) 0.518 ms 0.612 ms 0.569 ms 2 172.20.4.210 (172.20.4.210) 2.008 ms 2.009 ms 1.966 ms 3 10.215.4.242 (10.215.4.242) 6.316 ms 6.314 ms 6.317 ms 4 172.20.4.14 (172.20.4.14) 8.094 ms 8.028 ms 8.549 ms^C I'm attaching a shorewall dump while performing the ping from $FW (10.215.246.91) to 10.215.236.123. Thanks, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] traffic does not flow through firewall/router
From: Simon Matter > > Exactly, what about the rest of the network, switches/routers, how do they > know about the FW change? (I guess the easiest solution would be to simply> > reboot those devices after the FW change) Note that I've kept the new FW online for more than 5 minutes. I'm not sure yet when an ARP entry times out in my network devices (I'll need to check on each and every switch firmware), but in Linux it should be about 1 minute according to: /proc/sys/net/ipv4/neigh/default/gc_stale_time I'm only assuming the other network devices have similar settings, but I guess I'll need to check thoroughly. The fact that I can ping from the new FW to any host in any "zone" can be explained by the fact that the new FW has an empty ARP table, and when a new connection is to be made the dst host replies to the ARP request directly to the new FW. So I guess I can successfully ping from the new FW to host A, but not necessarily the other way around. Thanks, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] traffic does not flow through firewall/router
Hi, I'm trying to update to shorewall 5.1 with a config that is *supposedly* working with 5.0. In any case, I'm trying to ping from a host in lan zone with IP addr. 10.215.144.48 to a host in IBS zone with IP addr. 10.215.9.172. ICMP traffic should be allowed but the client isn't receiving any replies. I'm attaching the shorewall dump. /var/log/shorewall/info.log only has messages of this kind when restarted: Jun 15 07:52:10 inf-fw2 root[32520]: Shorewall Stopped Jun 15 07:52:11 inf-fw2 root[900]: Shorewall started /var/log/shorewall-init.log doesn't seem to contain any error messages. Please note that this shorewall box was supposed to replace another one with the same IP address (it's the default gateway/firewall). So I merely unplugged the ethernet cables from the "old" shorewall box and plugged them into the new one. It didn't occurr to me to try and ping $FW from a lan host or connect via ssh. However, from within the $FW console I could ping to any host IP addresses in all "zones". The switch happened at 07:45:05 and had to revert to the old FW at 07:52:11 because the users were already complaining. Could there be an arp cache issue? Thanks, Vieri swdump.gz Description: application/gzip -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] custom Drop action
Hi, I'd like to know how to rewrite my custom Drop action for Shorewall 5.1. My goal is to add the SRC IP address of a remote host that tries to connect to an "unpublished"/unavailable port. To do that I created a custom DROP action and included it at the very end of my rules file. Custom action: # grep -v ^# /etc/shorewall/action.DROPBL | grep -v ^$ ?warning "You are using the deprecated Drop default action. Please see http://www.shorewall.net/Actions.html#Default"; ?if passed(@1) ?if @1 eq 'audit' DEFAULTS -,-,A_DROP,A_ACCEPT,A_DROP,A_DROP ?else ?error The first parameter to Drop must be 'audit' or '-' ?endif ?else DEFAULTS -,-,DROP,ACCEPT,DROP,DROP ?endif COUNT ?if passed(@2) Auth(@2) ?endif AllowICMPs(@4) - - icmp Broadcast(DROP,@1) Multicast(DROP,@1) Invalid(DROP,@1) SMB(@3) DropUPnP(@6) NotSyn(DROP,@1) - - tcp DropDNSrep(@5) ADD(POL_BL:src) # grep DROP_DEFAULT /etc/shorewall/shorewall.conf DROP_DEFAULT="Broadcast(DROP),Multicast(DROP)" # tail -n 1 /etc/shorewall/rules DROPBL:info:polbl net4all # grep ^net4 /etc/shorewall/policy net4$FW DROP net4loc DROP net4dmz DROP net4net3DROP net4net2DROP net4net1DROP net4all DROP First of all I was thinking of changing my rules file and replacing this line: DROPBL:info:polbl net4all with this other line: ADD(POL_BL:src):info:polbl net4all Would I get the same behavior, considering that the default policy is DROP? If that were the case I would not need to define the DROPBL custom action. If not, how would I need to re-write my custom action? I tried the solution to replace DROPBL with ADD and got the following results: # grep LOGTAGONLY /etc/shorewall/shorewall.conf LOGTAGONLY=Yes shorewall check shows: WARNING: Log Prefix shortened to "Shorewall:polbl:ADD(POL_BL:s " This is on a box with Shorewall 5.0.15.6. Despite the log tag issue the rest seems to be working as expected. With shorewall 5.1.4.1 the log tag warning doesn't show up, but I'm still in the process of moving to that version. Thanks, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] upgrading to shorewall 5.1.4.1
Hi, I'm trying to install shorewall 5.1.4.1 but got this line repeated several times when running shorewall check: Use of uninitialized value $fanout in concatenation (.) or string at /usr/share/shorewall/Shorewall/Rules.pm line 643, <$currentfile> line 2. I had to revert the change quickly so I couldn't really debug this. I'll have more time tomorrow, but I was wondering if someone already had this issue. Thanks, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] DROP and COUNT with PROTO=255
From: Tom Eastep
>
> That rule doesn't indicate that the packet is being dropped -- it
> simply means that it is being logged and counted.
I'm asking because I created a custom Action (DROPBL) as you previously
suggested in another thread so that I could Drop and insert the src IP address
in an ipset if a client tried to connect to an "unpublished" port.
My custom DROP action simply contains the following instruction at the bottom:
ADD(POL_BL:src)
Usually when there's a false positive and a remote client complains I simply
grep the shorewall log and look for its IP address with a custom log tag
('polbl') and a :DROP: right after it. I can then inform the client that they
were trying to access the wrong port.
However, in this particular case I saw this in the log:
# grep 1.2.3.4 /var/log/shorewall/info.log
Jun 5 16:47:51 kernel: Shorewall:polbl:COUNT:IN=enp9s5 OUT=
MAC=00:0d:88:cd:7f:c5:00:13:f7:23:ef:b4:08:00 SRC=1.2.3.4 DST=192.168.100.2
LEN=60 TOS=0x00 PREC=0x00 TTL=124 ID=10689 PROTO=255 MARK=0x2
Jun 5 16:52:58 kernel: Shorewall:blsinit:REDIRECT:IN=enp9s5 OUT=
MAC=00:0d:88:cd:7f:c5:00:13:f7:23:ef:b4:08:00 SRC=1.2.3.4 DST=192.168.100.2
LEN=52 TOS=0x00 PREC=0x00 TTL=124 ID=10900 DF PROTO=TCP SPT=49339 DPT=80
WINDOW=8192 RES=0x00 SYN URGP=0 MARK=0x2
The IP address 1.2.3.4 was added to the POL_BL ipset.
If I look at another example in the log I see:
Jun 7 11:26:38 kernel: Shorewall:polbl:COUNT:IN=enp9s6 OUT=
MAC=00:0d:88:cd:7f:c6:50:67:f0:af:f4:57:08:00 SRC=4.3.2.1 DST=192.168.101.2
LEN=60 TOS=0x00 PREC=0x00 TTL=59 ID=0 DF PROTO=TCP SPT=80 DPT=24620
WINDOW=28960 RES=0x00 ACK SYN URGP=0 MARK=0x3
Jun 7 11:26:38 kernel: Shorewall:polbl:DROP:IN=enp9s6 OUT=
MAC=00:0d:88:cd:7f:c6:50:67:f0:af:f4:57:08:00 SRC=4.3.2.1 DST=192.168.101.2
LEN=60 TOS=0x00 PREC=0x00 TTL=59 ID=0 DF PROTO=TCP SPT=80 DPT=24620
WINDOW=28960 RES=0x00 ACK SYN URGP=0 MARK=0x3
So I guess the DROP in my first example was not logged for some reason.
Still, the COUNT log line in the second example reveals the DPT to which the
remote client tried to access. In the first example I don't know what PROTO=255
is, except "Reserved for extra".
Supposedly, the remote host with IP addr. 1.2.3.4 is "trusted" and should not
use an unknown protocol.
Anyway, it's not really an issue. Just wondering why.
Thanks,
Vieri
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] DROP and COUNT with PROTO=255
Hi, My last Shorewall rule is DROP with logging options (:info:polbl). It's a custom DROP action identical to the upstream version, except it includes the SRC IP addr. in an ipset. I usually get messages in the log such as Shorewall:polbl:DROP... However, I sometimes get messages such as the one below: Jun 5 16:47:51 kernel: Shorewall:polbl:COUNT:IN=enp9s5 OUT= MAC=00:0d:88:cd:7f:c5:00:13:f7:23:ef:b4:08:00 SRC=1.2.3.4 DST=192.168.100.2 LEN=60 TOS=0x00 PREC=0x00 TTL=124 ID=10689 PROTO=255 MARK=0x2 What is the reason for which the packet was DROPped? What does COUNT mean exactly, especially with PROTO=255? Thanks, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
