[Shorewall-users] cannot ping through Shorewall 5.1.4.4 gateway

[Tom Eastep]

Hi,
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.

You have failed to enable IP forwarding on fw2.

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?

No -- what error are you seeing?

-Tom

[Tom Eastep]

________________________________ From: Tom Eastep

Post by 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.

Sorry, but I'm not going to have time to look at these today. I'll try
to get to them tomorrow.

Pings from "fw2" to 8.8.8.8 work fine.

Post by Tom Eastep
No -- what error are you seeing?

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.

-Tom

[Tom Eastep]

Post by Tom Eastep

________________________________ From: Tom Eastep

Post by 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.

Sorry, but I'm not going to have time to look at these today. I'll try
to get to them tomorrow.

But a quick look through the dump shows:



Chain loc-net1 (1 references)
pkts bytes target prot opt in out source
destination
...
0 0 ACCEPT icmp -- * * 10.215.0.2
0.0.0.0/0 icmptype 8 /* Ping */
...
0 0 Broadcast all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 DROP all -- * * 0.0.0.0/0
0.0.0.0/0

Chain loc-net2 (1 references)
pkts bytes target prot opt in out source
destination
...
1 84 ACCEPT icmp -- * * 10.215.144.7
192.168.100.1 icmptype 8 /* Ping */
0 0 ACCEPT icmp -- * * 10.215.145.10
192.168.100.1 icmptype 8 /* Ping */
0 0 ACCEPT icmp -- * * 10.215.144.48
192.168.100.1 icmptype 8 /* Ping */
...
1 65 Broadcast all -- * * 0.0.0.0/0
0.0.0.0/0
1 65 DROP all -- * * 0.0.0.0/0
0.0.0.0/0

Chain loc-net3 (1 references)
pkts bytes target prot opt in out source
destination
...
0 0 ACCEPT icmp -- * * 192.168.210.0/23
0.0.0.0/0 icmptype 8 -m geoip --destination-country
AD,AT,AU,BE,CH,DE,DK,EU,FI,FR,GB,GR,IE,IS,US /* Ping */
0 0 ACCEPT icmp -- * * 192.168.212.0/24
0.0.0.0/0 icmptype 8 -m geoip --destination-country
AD,AT,AU,BE,CH,DE,DK,EU,FI,FR,GB,GR,IE,IS,US /* Ping */
0 0 ACCEPT icmp -- * * 192.168.210.0/23
0.0.0.0/0 icmptype 8 -m geoip --destination-country
NL,NO,NZ,PT,SE,CA,ES,IT /* Ping */
0 0 ACCEPT icmp -- * * 192.168.212.0/24
0.0.0.0/0 icmptype 8 -m geoip --destination-country
NL,NO,NZ,PT,SE,CA,ES,IT /* Ping */
0 0 ACCEPT icmp -- * * 192.168.210.0/23
0.0.0.0/0 icmptype 8 match-set OUT_WL dst /* Ping */
0 0 ACCEPT icmp -- * * 192.168.210.0/23
0.0.0.0/0 icmptype 8 match-set OUT_MANUAL_WL dst /* Ping */
0 0 ACCEPT icmp -- * * 192.168.210.0/23
0.0.0.0/0 icmptype 8 match-set OUT_XTRA_WL dst /* Ping */
0 0 ACCEPT icmp -- * * 192.168.212.0/24
0.0.0.0/0 icmptype 8 match-set OUT_WL dst /* Ping */
0 0 ACCEPT icmp -- * * 192.168.212.0/24
0.0.0.0/0 icmptype 8 match-set OUT_MANUAL_WL dst /* Ping */
0 0 ACCEPT icmp -- * * 192.168.212.0/24
0.0.0.0/0 icmptype 8 match-set OUT_XTRA_WL dst /* Ping */
...
1 84 ACCEPT icmp -- * * 10.215.144.7
192.168.101.1 icmptype 8 /* Ping */
0 0 ACCEPT icmp -- * * 10.215.145.10
192.168.101.1 icmptype 8 /* Ping */
0 0 ACCEPT icmp -- * * 10.215.144.48
192.168.101.1 icmptype 8 /* Ping */
...
7 489 Broadcast all -- * * 0.0.0.0/0
0.0.0.0/0
7 489 DROP all -- * * 0.0.0.0/0
0.0.0.0/0

Chain loc-net4 (1 references)
pkts bytes target prot opt in out source
destination
...
0 0 ACCEPT icmp -- * * 10.215.144.7
192.168.102.1 icmptype 8 /* Ping */
0 0 ACCEPT icmp -- * * 10.215.145.10
192.168.102.1 icmptype 8 /* Ping */
0 0 ACCEPT icmp -- * * 10.215.144.48
192.168.102.1 icmptype 8 /* Ping */
...
0 0 Broadcast all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 DROP all -- * * 0.0.0.0/0
0.0.0.0/0

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.

-Tom

[Tom Eastep]

Post by Tom Eastep
________________________________

Post by 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.

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
ACCEPT all -- * * 172.16.0.1 0.0.0.0/0
# grep ^loc /SAMBA/gateway_extra/policy.FHM
loc net1 DROP info
loc net2 DROP info
loc net3 DROP info
loc net4 DROP info
loc dmz DROP info
loc $FW DROP info
loc all DROP info
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.
# 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.
Linux 4.8.17-hardened-r2
shorewall version 5.0.15.6
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.

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

Note1: If the SOURCE IP of the ping packets that you see on the 'loc'
interface is not 172.16.0.1, then change the [no]iptrace commands to use
the correct address.

Note2: If you have made ANY configuration changes to fw2 since the last
dump you sent, please send another dump.

Thanks,
-Tom

[Tom Eastep]

Post by Tom Eastep
________________________________

Post by Tom Eastep
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
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.
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.

Thare are no SNAT/MASQUERADE rules being instantiated. Hence, reply
packets from 8.8.8.8 cannot be routed back you fw2. What is the output
of 'ls -l /etc/shorewall/snat'?

-Tom

[Tom Eastep]

Post by Tom Eastep

Post by Tom Eastep
________________________________

Post by Tom Eastep
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
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.
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.

Thare are no SNAT/MASQUERADE rules being instantiated. Hence, reply
packets from 8.8.8.8 cannot be routed back you fw2. What is the output
of 'ls -l /etc/shorewall/snat'?

I am going to be away from home for the day so I need you to gather some
data while I'm away.

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).

Please send me (privately), your /var/lib/shorewall/firewall file.

Also, please:

sh -x /var/lib/shorewall/firewall reload > trace 2>&1

and send me the 'trace' file.

Finally, include the output of 'ip route ls dev enp10s0'

Thanks,
-Tom

[Tom Eastep]

Post by Tom Eastep

Post by Tom Eastep
Thare are no SNAT/MASQUERADE rules being instantiated. Hence, reply
packets from 8.8.8.8 cannot be routed back you fw2. What is the output
of 'ls -l /etc/shorewall/snat'?

I am going to be away from home for the day so I need you to gather some
data while I'm away.
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).
Please send me (privately), your /var/lib/shorewall/firewall file.
sh -x /var/lib/shorewall/firewall reload > trace 2>&1
and send me the 'trace' file.
Finally, include the output of 'ip route ls dev enp10s0'

I have just noticed that there are rules in your snat file that don't
depend on the input interface and there aren't present either. So it
seems that the snat file is not being processed during compilation.

So back to my original line of questioning - is /etc/shorewall/snat
readable and non-empty? If so, please forward the output of "shorewall
trace -vvv check".

-Tom

[Tom Eastep]

Post by Tom Eastep
________________________________

The next step is to find out how to write my snat files correctly.

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

That will work -- the problem is that you have an old
/etc/shorewall/masq file -- get rid of that and the compiler will
process your snat file.

-Tom

[Tom Eastep]

Post by Tom Eastep

Post by Tom Eastep
________________________________

The next step is to find out how to write my snat files correctly.

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

That will work -- the problem is that you have an old
/etc/shorewall/masq file -- get rid of that and the compiler will
process your snat file.

Actually, that is wrong -- 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

-Tom

[Tom Eastep]

________________________________ 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
# 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.

I have already updated the code for the next release to process the snat
file if the masq file generates no rules, so that others don't fall into
that trap.

Anyway, I'm half-way through. One down, one to go (fw1). I guess I've
- shorewall snat/masq -
- shorewall AUTOMAKE
- hardened kernel and/or hardened package base of my distro
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.

Okay -- let us know what you discover.

In any case, thank you very much for all the help.

You are most welcome.

I'll let you know if I run into any trouble with "fw1"... ;-)

I'm sure you will :-)

-Tom

[Tom Eastep]

Post by Tom Eastep
________________________________

Post by 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

This is why, with AUTOMAKE=Yes, 'check' can fail but 'start' succeeds.
With AUTOMAKE=Yes, /sbin/shorewall looks at the directories named in
CONFIG_PATH and it runs the compiler only if it finds one newer than
/var/lib/shorewall/firewall. I assume that /SAMBA/${FW_TYPE}_extra/ is
not on the CONFIG_PATH...

-Tom

[Tom Eastep]

Post by Tom Eastep
________________________________

Post by 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.
net4 enp7s0f0 optional,tcpflags,nosmurfs,logmartians,proxyarp=0,arp_ignore=1,sourceroute=0,rpfilter
# 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.

You don't want to set the /proc rp_filter flag!!! The 'rpfilter' option
using a netfilter feature to perform reverse path filtering.

-Tom

[Tom Eastep]

Post by Tom Eastep
________________________________

Post by 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.
net4 enp7s0f0 optional,tcpflags,nosmurfs,logmartians,proxyarp=0,arp_ignore=1,sourceroute=0,rpfilter
# 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.

***@debianvm:/etc/shorewall# shorewall status
Shorewall-5.1.5 Status at debianvm - Tue Jul 4 08:56:52 PDT 2017

Shorewall is stopped
State:Stopped Tue Jul 4 08:56:48 PDT 2017 (/var/lib/shorewall/firewall
compiled Tue Jul 4 08:36:58 PDT 2017 by Shorewall version 5.1.5)

***@debianvm:/etc/shorewall# shorewall start
Compiling using Shorewall 5.1.5...
Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf...
Loading Modules...
Compiling /etc/shorewall/zones...
Compiling /etc/shorewall/interfaces...
Compiling /etc/shorewall/hosts...
Determining Hosts in Zones...
Locating Action Files...
Compiling /etc/shorewall/policy...
Adding Anti-smurf Rules
Adding rules for DHCP
Compiling TCP Flags filtering...
Compiling Kernel Route Filtering...
Compiling Martian Logging...
Compiling Accept Source Routing...
Compiling /etc/shorewall/providers...
ERROR: Providers interfaces may not specify 'routefilter' when
USE_DEFAULT_RT=Yes /etc/shorewall/providers (line 10)
***@debianvm:/etc/shorewall#

-Tom

[Tom Eastep]

Post by Tom Eastep
________________________________
[...]

Post by Tom Eastep
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 couldn't reproduce it.

Post by Tom Eastep
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.

Post by Tom Eastep
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
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)
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.
#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
#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONSCOPY
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
ISP4 4 4 - $IF_ISP4 $IF_ISP4_GW track,balance=1,persistent

There seems to be a problem with AUTOMAKE=Yes -- the 'start' command is
using your previously-compiled script. You can work around this by
setting AUTOMAKE=No, and we'll look at it after we get your other
problem addressed.

-Tom