Strict Reverse Path Filtering and Firewall Logging

Networking
1

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!

2

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

3

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.

4

Michael:

Any additional feedback based on the last post above?

Thanks!

5

Any reason you didn’t configure this using the UI?

You simply don’t seem to have a firewall rule that matches those packets.

1 Like
6

Michael:

Thanks for the response.

For the firewall rules, for the setup guide I was following, it was suggested to put the rules in firewall.local so that was why I didn’t use the GUI.

Please note that the first set of log entries was from prior to the update so those weren’t the anomalies. As you mentioned, there are no rules for those type of entries, so they were dropped as expected.

The UDP DROP_INPUT example was what is seen after the update while all of the DROP_INPUTs that were previously seen are no longer seen (although the same attempts are coming in).

I think the issue is indeed related to OpenVPN and the reverse path filter setting.

At:

https://community.openvpn.net/openvpn/wiki/Concepts-PolicyRouting-Linux

it appears to suggest that a stricter setting than 2 can cause issues with OpenVPN.

Another reference I found also seems to suggest that filter = 1 can produce martians similar to what I was seeing.

For now, I’ve gone back to the prior filter setting and all seems to be working again as expected.

Thanks.

7

Well, yes it makes things more complicated because it does not allow you to run “experimental” network configurations - or probably more likely: Unintended network configurations.

Traffic is supposed to flow only one way so that we can filter it in the right place. In this instance, you are masquerading all traffic I suppose - that should not trigger any problems with the RP filter unless you are doubly-using the same IP address space?!

I don’t think I know enough about your network design to say precisely what the problem is.

2 Likes
8

Michael:

To my knowledge, I’m not doubly using the same IP address space, only 192.168.0.x on green and 192.168.1.x on blue and the VPN tunnel is using 10.x.x.x.

Other than the 3 firewall additions related to OpenVPN in firewall local mentioned above, a pretty simple network setup. RED, BLUE, and GREEN local setup with everything going through the VPN to the VPN provider.

All other firewall settings within the GUI are the defaults. I haven’t changed anything else related there.

Thanks for the assistance and if there is anything additional that you can think of that would be helpful for me to provide setup wise, please let me know.