Why are my syslog messages using the WAN interface address?

[eponymous]

If you are using TCP with syslog, no information will be leaked, because the initial 3-way handshake always fails. UDP datagrams on the other hand might leak logged information to your ISP.

Good point.

I had that toggle active. However, after I created a floating rule with logging enabled, I found some leaking IPs because of remnants of old configurations. The WAN interface usually has the default route, so that is really no surprise.

The toggles handle only incoming RFC1918 traffic, not outgoing. You can see that in the automatic interface rule that handles only "in" packets for private/bogon IPs.

In terms of blocking all RFC1918 traffic out of the WAN then - what is the solution?

[eponymous]

How would you do this when an automatically generated rule exists for WAN which essentially "lets out anything from firewall host itself" and which is put before any manually created rules?

Create a floating rule which has a higher priority than interface rules.

That seems like a solution however, shouldn’t the toggle for blocking RFC1918 operate on both IN and OUT? I suspect this could be classed as a bug if it’s only working on IN.

[meyergru]

That is not a bug in itself, because blocking RFC1918 in and out serves very different purposes.

You could use OpnSense in all kinds of scenarios, including some where the counterpart on the "WAN" is another company network (e.g. 10/8). In that case, you would want to block incoming traffic, but not outgoing.

So, if at all, there could be a checkbox to "block outgoing private addresses". To me, it was not obvious how to do that and I had never thought about it until now, which is why I asked (and got answered).