Hello,
Sorry if this is a dumb question, but could someone explain why my WAN interface is passing outward traffic to these networks? These are not even ranges that exist in my internal network.
Is your WAN interface bound to a public IP address? x.x.x.235?
Thanks for the response. Yes, my WAN ip has a public address ending in .235
This should be a default rule. Can you provide more information? Interfaces or directions
I have a pretty simple setup. I have LAN, WAN, WG0(Wireguard), and IOT interfaces. My IOT network prevents internal communication using a rule that only allows internet access, by using an alias that describes RFC1918 ranges. This rule allows traffic excluding the alias ranges using the invert option in the rule. My LAN interface runs on 192.168.10.X. My WG0 interface runs on 10.14.x.x. WAN interface has block private and bogon networks enabled.
I use a destination NAT rule to force all DNS requests to use pihole, then I use OPNsense unbound as the upstream server.
OPNsense runs on top of Proxmox (forbidden router I know)
I looked up port 7000, and while I do use MacOS and Apple products, I don't have any devices at these addresses. They are all in the LAN interface range. I have pinged these addresses and there is no response.
Thanks again for the response!
Em...It looks like a broadcast packet, but it shouldn't come from a public network address. Are there any other rules besides DNS NAT rules?
Here are my rules. I only have 5. I passthrough my WAN port directly to my OPNsense VM so Proxmox isn't exposed to the internet.
Thanks!
What is the destination address(WAN address) port range for interface WAN rule?
Quote from: glenb2 on June 30, 2026, 03:00:03 AMSorry 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.
Lol Bob chill dude, try not to be so passive aggressive all the time.
Quote from: glenb2 on June 30, 2026, 03:00:03 AMcould someone explain why my WAN interface is passing outward traffic to these networks? These are not even ranges that exist in my internal network.
If I understand your question, are you saying these packets are are being allowed in through your WAN interface and due to the routes configured on your firewall, they are then going back out to the Internet?
Please provide details about your WAN connection and equipment, and which mode of operation the modem is operating in, e.g. bridge mode.
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 .
In addition, did you enable the option in your WAN interface to
Block private networks?
There is no range. It is just a single number that allows for VPN access into OPNsense from the internet.
Bob.Dig, I'm here asking for help and to learn because I'm not a network engineer. Wincent is asking about an 'in' rule. My concern is that I don't understand why I'm seeing outbound traffic to what I thought were private address spaces from my WAN interface.
Here is my alias. Yes, private networks and bosons are blocked on my WAN interface.
lmoore and Monviech, Thank you.
Quote from: glenb2 on June 30, 2026, 09:54:00 AMThere is no range. It is just a single number that allows for VPN access into OPNsense from the internet.
Bob.Dig, I'm here asking for help and to learn because I'm not a network engineer. Wincent is asking about an 'in' rule. My concern is that I don't understand why I'm seeing outbound traffic to what I thought were private address spaces from my WAN interface.
I thought it was inbound traffic, but if it's outbound, it's normal. As Bob.Dig said, the firewall defaults to sending all non local packets to the default gateway.
If you don't want to see these, set a rule as lmoore mentioned to intercept them.
:)
Thank you. I didn't expect I would have to do that. I came here for education. Thank you..
I politely steer whoever to notice from my first post that I described outward traffic.
Thank you wincent, lmoore and Monviech
Quote from: glenb2 on June 30, 2026, 07:35:42 AMHere 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?
Quote from: Bob.Dig on June 30, 2026, 09:26:47 AMQuote from: glenb2 on June 30, 2026, 03:00:03 AMSorry 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. :)
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:
2026-06-30 13_48_49-Configuration _ Routes _ System _ OPNsense.mgsoft — Mozilla Firefox.png
Why this works? Because your local RFC1918 interface routes are more specific than these and make your real routes work.
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.
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.
Quote from: lmoore on June 30, 2026, 09:52:25 AMTo 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.
(https://forum.opnsense.org/index.php?action=dlattach;attach=56219;image)
Quote from: meyergru on June 30, 2026, 01:51:03 PMI 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:
2026-06-30 13_48_49-Configuration _ Routes _ System _ OPNsense.mgsoft — Mozilla Firefox.png
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 :
(https://forum.opnsense.org/index.php?action=dlattach;attach=56227;image)
That they would block this kind of traffic but apparently do not ?!?!
Quote from: nero355 on June 30, 2026, 06:23:48 PMThat they would block this kind of traffic but apparently do not ?!?!
Not going out the interface, only in...
Quote from: meyergru on June 30, 2026, 06:31:15 PMQuote from: nero355 on June 30, 2026, 06:23:48 PMThat 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 ??
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.
Quote from: keeka on June 30, 2026, 06:43:23 PMWhy 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.
Quote from: meyergru on June 30, 2026, 06:56:36 PMThat 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.
Quote from: glenb2 on June 30, 2026, 03:00:03 AMcould 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.
(https://forum.opnsense.org/index.php?action=dlattach;attach=56249)
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.
Quote from: nero355 on June 30, 2026, 06:35:22 PMI 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 ??
Good question. At first glance it looks like an historic oversight, because in the very beginning a long time ago only "in" rules existed in the GUI.
Traffic leaking isn't great but mostly a sign of misconfiguration. Some people also expect both private and public networks on their WAN link. I've seen setups with virtual IPs for a local subnet on WAN that had a public address. Adding an early kill switch for outbound traffic that can't be overridden would probably kill some people's working setups.
Cheers,
Franco
Quote from: nero355 on June 30, 2026, 06:35:22 PMI get that, but the question is : Why not ?!
In is important, out is just nice. Many people in the US probably had cable-modems web-UI on 192.168.100.1 for statistics.
Quote from: franco on July 03, 2026, 12:04:38 PMTraffic leaking isn't great but mostly a sign of misconfiguration.
True...
QuoteSome people also expect both private and public networks on their WAN link.
I've seen setups with virtual IPs for a local subnet on WAN that had a public address.
Adding an early kill switch for outbound traffic that can't be overridden would probably kill some people's working setups.
I guess you could add this :
Quote from: Bob.Dig on July 03, 2026, 12:11:52 PMMany people in the US probably had cable-modems web-UI on 192.168.100.1 for statistics.
To that situation too.
The same goes for Fibreglass ONTs and xDSL Modems :)
But I was thinking to have something like this :
(https://forum.opnsense.org/index.php?action=dlattach;attach=56227;image)
But then two times each :
- Block Private Networks - Incoming
- Block Private Networks - Outgoing
- Block BOGON Networks - Incoming
- Block BOGON Networks - Outgoing
Would that be a good solution ?
Quote from: nero355 on July 03, 2026, 07:05:03 PMThe same goes for Fibreglass ONTs and xDSL Modems :)
But I was thinking to have something like this :
(https://forum.opnsense.org/index.php?action=dlattach;attach=56227;image)
But then two times each :
- Block Private Networks - Incoming
- Block Private Networks - Outgoing
- Block BOGON Networks - Incoming
- Block BOGON Networks - Outgoing
If your xDSL/ONT modem only has one Ethernet port and if you want the ability to check the status of the modem without interrupting the connection to the Internet, your only choice is to access the modem via the WAN port.
My xDSL modem is a Draytek VigorNIC 132 which is plugged in to a PCIe slot.
Prior to setting up OPNsense as my firewall (January 2021), I was using OpenBSD. With OpenBSD I set up a bridge interface and included re0 (WAN port) and vether0 interfaces as members. The vether interface was configured with the RFC-1918 subnet I use to access the modem's web interface. Doing this allowed the standard outbound blocking rule for RFC-1918 address to be used without impacting access to the DSL modem.
Unfortunately, the vether-kmod port isn't included in OPNsense and won't be a consideration in the future unless the FreeBSD port can be fixed - this seems unlikely.
With OPNsense, I assigned the RFC-1918 subnet to the bridge interface, then set up applicable rules for the modem network.
The preferred method to prevent RFC-1918 leakage is by using the black hole routes, as already mentioned in this thread. It is conceivable that one day, one may encounter a problem and when troubleshooting, the black hole routes may be disabled and they may not be re-enabled if it's forgotten about. The only other mechanism to prevent leakage is to have the outbound firewall rule to block RFC-1918 - I understand ISP's aren't supposed to allow RFC-1918 to be routed normally through their networks.
I have floating rules preventing internal traffic making its way to destinations via the WAN interface. In addition, I've created rules on the WAN interface to block outbound connections from the firewall. This is primarily to prevent connections originating from the firewall itself, otherwise they will be allowed out due to the automatically generated rule
let out anything from firewall host itself (force gw).
Blocking outbound connections to
bogon networks seems like a good idea. Testing to some of the addresses in the
bogons alias, they are being blocked by Q-Feeds. Q-Feeds is the first block rule for my internal networks so it's possible other lists will include them too. However, they aren't being blocked from the firewall itself - time to review and update my outbound rules on the WAN interface.
[Update] - I already had rules to block outbound from the firewall itself so it is fair to say, the other lists I use do not include bogon addresses. I added a rule to use Q-Feeds and it's now blocking connections to bogon addresses which originate from the firewall itself.