WAN interface passing to private destinations

[lmoore]

Here are my rules.

If the unknown and unexpected traffic is originating from inside the network, e.g, from either IOT, LAN or WireGuard interfaces, enabling logging on the LAN, WAN and WireGuard rules should show where they are coming from.

Looking at these rules, I would hedge my suspicion towards the WireGuard interface as the LAN & IOT rules are restricting the connections from these networks to their respective network addresses.

If this traffic is unexpected, it is advisable to identify their source and resolve the real problem.

Depending on how you use your WireGaurd VPN, you could have one or more rules and set the Source to be WireGuard (Group) network.

Are their any Wireless Access Points connected to the network?

[glenb2]

Sorry if this is a dumb question

That is how routing works, if it is not local, it gets out the default gateway.

Why is your last screenshot not showing any ports, that is dumb for sure.

Showing who you really are on the internet is dumb for sure. Have the life you deserve. :)

[meyergru]

I once had "out" rules blocking RFC1918 IPs on WAN (which shows one of the very few appropriate uses for "out" rules), but then somebody pointed me to this way better approach:

You cannot view this attachment.

Why this works? Because your local RFC1918 interface routes are more specific than these and make your real routes work.

[mooh]

Can't contribute to the solution but I'd like to add an observation that may be relevant here. I have a guest WiFi network in one location blocking all local traffic, only allowing access to the internet. When logging of the rule is on, I see traffic directed at private addresses that match the address ranges used in another location I'm frequently at. As it turns out, the traffic is caused by Apple devices that somehow fail to realise that they are in a different network and location. I haven't dug into it any further. For now, I just turned logging off.

Port 7000 happens to be used by Apple Airplay but I cannot explain how this matches the "let out anything from the firewall host itself" rule.

[meyergru]

The RFC1918 leakage caused by clients that try to access something not in your own networks (like probing for anything on 192.168.1.1) can have adverse side-effects: Some ISPs take it as a hint to a misconfiguration. In Germany, Deutsche Glasfaser takes down the connection for a few minutes when this occurs excessively.

[nero355]

To avoid connections to RFC-1918 destinations leaking out of your firewall to the Internet, other than those directly connected to OPNsense, you can create black hole routes in OPNsense, in addition, as an added precaution you can create a rule to prevent connections to RFC-1918 destinations going out your WAN interface.

I once had "out" rules blocking RFC1918 IPs on WAN (which shows one of the very few appropriate uses for "out" rules), but then somebody pointed me to this way better approach:

You cannot view this attachment.

Why this works? Because your local RFC1918 interface routes are more specific than these and make your real routes work.

I think I am going to add those NULL Routes to my Configuration too, because I thought that when you ENABLE these :

That they would block this kind of traffic but apparently do not ?!?!

[meyergru]

That they would block this kind of traffic but apparently do not ?!?!

Not going out the interface, only in...
 

[nero355]

That they would block this kind of traffic but apparently do not ?!?!

Not going out the interface, only in...

I get that, but the question is : Why not ?!

Would it be reasonable to ask the OPNsense developers to add that to those options or perhaps create additional ones for Outgoing Traffic ??

[keeka]

I went with the out rule on the WAN blocking destination RFC1918. Why do you prefer the null routes solution?
AISI a firewall rule, with logging enabled, can at least alert you to what is probably unexpected traffic.
Using that approach, the two instances of unexpected RFC1918 I have so far encountered are leaked docker network IPs and a phone app looking for an IOT device at its default address when it could not find it on the expected IP.

[meyergru]

Why do you prefer the null routes solution?

That has been discussed in this thread: https://forum.opnsense.org/index.php?topic=50678 - essentially, with "out" rules, you may forget that you actually have RFC1918 IPs you want to reach on WAN, whereas with null routes, that works out of the box. Also, note the "disable reply-to" problem here: https://forum.opnsense.org/index.php?msg=258978

On the other hand, you are correct in that you will see nothing the logs, for this is routing, not a firewall rule.

[keeka]

That has been discussed in this thread: https://forum.opnsense.org/index.php?topic=50678 - essentially, with "out" rules, you may forget that you actually have RFC1918 IPs you want to reach on WAN, whereas with null routes, that works out of the box. Also, note the "disable reply-to" problem here: https://forum.opnsense.org/index.php?msg=258978

@meyergru many thanks for the background info.

[lmoore]

could someone explain why my WAN interface is passing outward traffic to these networks?

Thinking about this a little more, I expect the IP addresses you are seeing are from your Apple devices and they are trying to communicate with devices they have connected to in the past.

I have seen something similar on my network with an app installed on a visitors smart phone and it wanting to communicate with the streaming media service on the owners home network. That traffic was appearing in my logs as blocked inbound traffic destined for a RFC-1918 network not in my environment.



Note, my "in" and "out" rules are set to Last match. This is so I can create new rules which include RFC-1918 addresses without having to worry about these rules interfering with them.

I have access to my DSL modem's interface which is on my WAN interface, however, I  have implemented access differently to @meyergru's excellent document, and do not have any exclusions in my RFC1918 alias to access it, and yes, my WAN interface is set to block private networks - image provided earlier in this thread.