Strict Reverse Path Filtering and Firewall Logging

I’ve noticed some changes in what is logged in the Firewall Log in IPFire since the update to 168.

I think it is related to the strict reverse path filtering changes but was curious if it is expected.

Prior to the update, the most common log entry in the firewall log was:

DROP_INPUT

for the red0 interface for tcp from various IPs as the source with my external ip as the destination over various ports.

After the update, I no longer see such entries.

Based on information posted in another thread, if I temporarily disable the rp filter with:

sysctl net.ipv4.conf.default.rp_filter=2
sysctl net.ipv4.conf.all.rp_filter=2

then said entries return.

Is that to be expected in terms of what might be logged when the filtering is enabled?

Oddly, with the filtering enabled I do see DROP_INPUT for red0 for UDP when I have a VPN enabled with the VPN endpoint IP and my IP. I do not see these entries when filtering is disabled and the router is connected to the VPN endpoint.

If anyone could provide any clarification about if the above is expected, etc., would be appreciated. Just want to make sure something is not amiss if my usage happens to be an edge case that might be impacted by the RPF.

Thanks!

Are you able to post an entire log line? Do you have any intentional or unintentional asymmetric routing?

Michael:

Thanks for responding.

Log lines with some info redacted:

Examples of the DROP_INPUT lines that were there prior to the update:

Jun 13 14:41:31 ipfw kernel: DROP_INPUT IN=red0 OUT= MAC=XXX SRC=139.162.190.203 DST=MY ISP IP LEN=40 TOS=0x00 PREC=0x20 TTL=230 ID=64500 PROTO=TCP SPT=16174 DPT=3517 WINDOW=1024 RES=0x00 SYN URGP=0
Jun 13 14:41:32 ipfw kernel: DROP_INPUT IN=red0 OUT= MAC=XXX SRC=143.110.234.214 DST=MY ISP IP LEN=40 TOS=0x00 PREC=0x20 TTL=231 ID=58031 PROTO=TCP SPT=61953 DPT=50001 WINDOW=1024 RES=0x00 SYN URGP=0
Jun 13 14:41:44 ipfw kernel: DROP_INPUT IN=red0 OUT= MAC=XXX SRC=193.57.40.49 DST=MY ISP IP LEN=40 TOS=0x00 PREC=0x20 TTL=234 ID=37253 PROTO=TCP SPT=56119 DPT=3221 WINDOW=1024 RES=0x00 SYN URGP=0
Jun 13 14:41:49 ipfw kernel: DROP_INPUT IN=red0 OUT= MAC=XXX SRC=89.248.165.110 DST=MY ISP IP LEN=40 TOS=0x00 PREC=0x20 TTL=236 ID=15487 PROTO=TCP SPT=40032 DPT=3063 WINDOW=1024 RES=0x00 SYN URGP=0

Example of the UDP DROP_INPUT that shows up after the update that didn’t have any entries prior to the update:

Jun 15 10:33:33 ipfw kernel: DROP_INPUT IN=red0 OUT= MAC=XXX SRC=VPN ENDPOINT IP DST=MY ISP IP LEN=93 TOS=0x00 PREC=0x20 TTL=57 ID=48069 DF PROTO=UDP SPT=1194 DPT=52229 LEN=73

For asymmetric routing, not that I am aware of. Is there a way to check to see if there is anything unintentional?

The only thing that I can think of that might be related would be the VPN setup and related firewall rules but those are pretty standard as best I can tell.

The network itself is pretty simple with green (wired), blue (wireless) and red.

When the VPN is on, everything goes through it as it is enabled on the ipfire box with openvpn as a daemon with a setup file from the vpn provider.

The additional VPN firewall rules that are added to firewall.local:

iptables -I WIRELESSFORWARD 1 -s 192.168.1.0/24 -i blue0 -o tun0 -j ACCEPT
iptables -t nat -A CUSTOMPOSTROUTING -s 192.168.0.0/24 -o tun0 -j MASQUERADE
iptables -t nat -A CUSTOMPOSTROUTING -s 192.168.1.0/24 -o tun0 -j MASQUERADE

Thank you.