Messages

@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.

I don't think */30 is a valid entry, or if it is then you got yourself a block from the list owner(s) for hammering their servers. Usually once a day is acceptable for most list providers.

Actually, this is a perfectly valid entry as shown in https://www.codementor.io/@akul08/the-ultimate-crontab-cheatsheet-5op0f7o4r:

"Every 10 Minutes of Every Day
# m h dom mon dow command
  */10 * * * * /home/user/script.sh"

The cron job should run every 30 minutes in my case. Also, there is no list owner, it's my own, 35-IP address table inputed manually to the alias table in OPNSense. And it's my own DMZ'd server being hammered by both the last IP (a Russian bot documented as a criminal organization) and the second to last IP.

Hi all,

I'm running OPNsense 25.1.3-amd64 FreeBSD 14.2-RELEASE-p2 OpenSSL 3.0.16.

Over the past two days, my firewall alias tables are no longer refreshing or updating on a daily basis. Things were running fine prior to 3/19/25 and as I added new URL Table IP's, they got pulled in and blocked. The latest IP's are no longer being blocked. I read through many posts here as well as the OPNSense docs but none of the suggestions here are working.

I added a cron job to refresh/reload the aliases (see the Cron attachment) every 30 minutes but no change. I checked the alias updates and it's indeed set to Daily, still no luck. I'm out of ideas short of manually hacking the XML file to add new IP's but that probably wouldn't force a reload either.

Is there any way to force a refresh/reload? I can't find this in the docs anywhere. It's clear from the Last Update attachment that only 33 IPs are loaded in the alias table and the two most recent additions (see Alias Table attachment) are not loaded since last update was two days ago prior to me adding these additional IPs. The first 33 IP's are being blocked properly but unfortunately (for me), the last two entries are hitting my DMZ server hard with over 60,000 attempts in the past two days. I really need to get these loaded into the tony_bogons table ASAP.

Ideas? Thanks...