Messages

Quick update: I discovered that turning on a third-party VPN (ProtonVPN) on both the Mac and iPhone seems to work around this problem. I think that turning on ProtonVPN turns off Apple's Private Relay which would validate the problem area.

I'm having issues with my iPhones reporting "Privacy Warning" and/or "internet not connected" errors since upgrading to 26.7. I applied the 26.7.1 patch today but the problems persist. Google AI is reporting that Apple's Private Relay is being temporarily blocked or getting slow access via Unbound DNS which causes iOS to timeout and issue these errors. I've tried a lot of different tests suggested by Google AI but I can't solve this issue. I don't know why DNS requests to Quad9 are getting stalled when they come through any device running Private Relay. This didn't happen under OPNSense 21.x.

I've also noticed slow updates on the OPNSense web page when going through the various settings. OPNSense is accessed from my Mac via Private Relay under Safari as well so this further indicates the problem is between Private Relay and Unbound DNS. It sometimes takes more than a full minute to update the OPNSense GUI whenever I switch to a different settings page if the new page hasn't been cached already.

I'm currently using both AdGuard and Stevens Blacklist lists with the Normal relaxed/balanced blocking level setting.

@patient0... Ding ding ding, you nailed it! There *were* 0 evaluations or matches being made according to Inspect in the WAN rules. There's no Inspect button in the port forwarding rules but I did find *old* PASS rules prior to the new block rules. The old rules weren't showing up earlier for some reason but when I erased all the categories, they showed up. Oops! I deleted the old port forward rules and left only the new ones and now I'm getting hundreds of matches per minute showing up in the WAN rules.

Thank all of you for resolving this mess. The Inspect Results attached show what's hitting me in a 5-minute time period. Fail2ban is now almost dead quiet running on the OpenVPN Access server which was my long-term goal :-)

Tony

I would remove that "Internet -> WAN (Firewall)" rule on the spot.
It ALLOWS any Internet host that is NOT in your alias to access any port on your public WAN IP!

An allow rule is not blocking anything in any case!!!
An Allow rule with a source (not inverted) only allows hosts matching the criteria.
An allow rule with an inverted (!) source allows all EXCEPT hosts matching the criteria.

More on the rest later.

Removed.

While waiting for a reply last night, I experimented with the settings shown below. These settings are still NOT blocking the tony_bogons alias list.

I also added a screen shot showing the tens of thousands of bogon IPs slipping through to my OpenVPN Access server and being trapped by fail2ban. Many of these are already in the tony_bogons list.

@Eric,
The attachments below show what I've implemented based on my flawed understanding of what you've said. To be clear, these WAN rule and port forwarding rules still don't block the bogons. They're showing up on the DMZ interface with the "let anything out of the firewall" default rule. Also, I see no blocking at all on the WAN interface other than the IP6 default rule.

Can you please be very specific in what changes I need to make?

Thank you

+1 on Patrick's reply wrt WAN Address.
The goal is to filter on the way IN (on WAN).

The auto-generated rule you mention is an OUT rule (likely on DMZ).
It would be irrelevant if the packets were filtered coming IN the firewall.

I understand what you're saying but I'm not sure how to filter coming into the firewall. Source would be WAN, destination The Firewall???

Here are the current WAN interface rules (attached). I originally tried blocking in the WAN interface but they didn't work.

Destination muss "WAN address" sein.

If you mean set the destination to WAN address, I just tried it and nothing changed. There's an automatic rule preceding my rules that's letting the bogons through.

Your PF rule can have an associated FW rule. Are you currently using PASS?
You can also specify a source criteria (eg !bad_actors_alias) in the PF rule.

I've set up an inverted alias list of bogons as shown in the attached JPEG. Unfortunately, those bogons are still being passed to the DMZ interface and flooding the OpenVPN Access Server with unwanted traffic. Again, they're coming in from a previous rule that lets anything out from the firewall. I didn't set that rule, it's automated and can't be deleted, moved, etc.

Your PF rule can have an associated FW rule. Are you currently using PASS?
You can also specify a source criteria (eg !bad_actors_alias) in the PF rule.

I've set up an inverted alias list of bogons as shown in the attached PDF. Unfortunately, those bogons are still being passed to the DMZ interface and flooding the OpenVPN Access Server with unwanted traffic.

Screenshot 2025-03-27 at 3.28.50 PM.png

Hi all,

I have an OpenVPN Access server running on a dedicated LAN interface which is DMZ'd with the three ports used by Access Server forwarded to its LAN address. I previously set up bogon alias filters in a (futile) attempt to filter out the worst attackers detected by Access Server and fail2ban. I *thought* the filter alias was working but realized that the offending IP's are still being forwarded to the dedicated LAN despite putting in a blocking rule in both the WAN and DMZ interfaces. It turns out that the automated "let out anything from firewall host itself" rules (uneditable) are passing the packets before my filters rules are hit and bypassing my rules. The documentation indicates that port forwarding can indeed bypass filter rules and that's what appears to be happening.

Is there any practical way to insert filter alias rules to block the offending IP addresses when port forwarding is being used? There's some vague reference to adding some filter process in this scenario but I can't figure out how to do it. If these forwarded DMZ'd ports can't be filtered at all, then I suppose I need to route them in a different way?

Thanks.

Here's what I think happened:

• At one point the alias had the correct type ,,Network(s)" and correct 33 entries.
• Then you switched it to the incorrect type ,,URL Tables" for reasons unknown to me.
• Since the ,,URLs" are obviously not valid blocklist URLs, the (resolved) alias content is not updated and still contains those 33 networks.
• While the type is still ,,URL Tables" you added two networks. But still none of the values are valid blocklist URLs, so the table still contains the last valid list, i.e those 33 networks.
• Now you have changed the type back to ,,Network(s)" but since the content field hasn't changed and this is not a dynamic type, the (resolved) alias table isn't updated.

I can reproduce the behavior. I guess this wasn't considered a valid use case (understandably so).

Just make some actual changes to the contents field and the alias will be updated.

Both you and meyergru were correct in your assumptions. I originally had the alias table typed as "Networks" but did indeed change it to "URL Tables" after reading the docs which are a bit confusing regarding which types update each day. After changing the type back to "Networks", the table updated overnight and I now have all 35 entries showing up. As for duplicate IPs/ranges, you're correct that these can't be entered into the table but it sure would be nice if OPNSense flagged an error when it automatically deletes duplicate entries. I've seen some entries get deleted but didn't realize they were duplicates at the time. Eventually, I figured out why they were disappearing.

Regarding the 30-minute cron job, this was suggested as a solution in another post similar to mine. Based on the time of the update, it appears that the cron job did not update the table 30 minutes later as expected so I've disabled it for the time being. I just added 4 more entries and the table updated immediately.

Thanks to both of you. Newbies can be dangerous :-)

[not]

You should probably read the documentation on "URL tables" again. Its content should be a URL that points to a web resource that contains a list of IPs, not the IPs or networks themselves. Your tony_bogons are of type URL table, but the contents seem to be a list of IPs and networks that would fit a "networks" type alias.

Because there are different alias types, it is syntactically possible to enter something like "192.168.0.0/16" into that field, but what is expected for a URL table alias is something like "https://iplists.firehol.org/files/firehol_level2.netset".

The way you use it, it will never work, and that is regardless of updates and specific OpnSense version.

Based on your recommendation, I changed the tony_bogons type to "Networks", saved it, applied it, and then rebooted OPNSense. Unfortunately, this didn't resolve the reload/refresh issue. The same 33 original IP's are still loading and the remaining 2 IP's are not. The Diagnostics Alias page also shows only the original 33 IP's. Still no updates to the alias tables (both tony_bogons and the Block Regions) since March 19th. The question here is why aren't the tables refreshing/reloading all of a sudden when they were working fine up until two days ago? How do I get these two lists to reload/refresh?

You get any error in the logs, can the firewall rule successfully be loaded?

I'm not sure which firewall log file holds these error messages if they exist. The firewall rules are fine and working as evidenced by the first 33 entries in the alias table being blocked. It's the alias table itself that's not being reloaded/refreshed.