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.
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.
Quote from: EricPerl on March 27, 2025, 08:57:26 PMYour 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
Quote from: tonys on March 27, 2025, 09:38:07 PMQuote from: EricPerl on March 27, 2025, 08:57:26 PMYour 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.
Destination muss "WAN address" sein.
Quote from: Patrick M. Hausen on March 27, 2025, 10:21:55 PMDestination 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.
Sorry for answering in German. Confused with another thread. Can you show that automatic rule?
+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.
Here are the current WAN interface rules (attached). I originally tried blocking in the WAN interface but they didn't work.
Quote from: EricPerl on March 27, 2025, 11:06:25 PM+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???
Quote from: tonys on March 28, 2025, 01:22:19 AMSource would be WAN, destination The Firewall???
Interface: WAN
Source: any ("the Internet")
Destination: WAN address ("the Firewall")
NAT: internal server address
That's what the connection looks like on the outside and what the port forwarding rule must be.
@OP, if you had descriptions in your PF rules, they would carry over the associated FW rules.
It would make it clear where the FW rules come from.
Personally, I would also enable logging on anything as risky as PF rules.
Overall, it's pretty simple. Expanding a bit on Patrick's post:
You VPN in, your client on the Internet (source = *) is contacting your VPN server (destination = public WAN IP).
That's how you configured your VPN client, that's how packets show up on the WAN interface.
As part of processing the PF rule, if it matches the criteria, the packets are forwarded to the NAT IP.
If your PF rule had source = !tony_bogons, destination = WAN address, then the associated FW rule would reflect the same.
@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
The port forward needs to read
Source: !tony_bogons
Destination: WAN address
Also please show the tony_bogons alias.
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.
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.
As mentioned in the previous post, that first FW rule needs to go.
The PF rules look fine to me. The corresponding FW rules match my expectations as well.
The destination in the associated FW rule might seem weird but these are evaluated after the PF rule transform.
Your alias is of type networks.
Per the Alias doc (https://docs.opnsense.org/manual/aliases.html#networks), all entries should be in CIDR notation (or wildcard notation).
That includes a /32 for hosts.
Just including IPs is likely causing a failure at least for these IPs, if not for the entire alias. I have not tested the failure mode.
So at best, the alias only includes the networks. At worst, it's empty. Allowed sources are any EXCEPT that content.
Quote from: EricPerl on March 28, 2025, 07:13:30 PMI 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.
Quote from: tonys on March 28, 2025, 06:09:51 PMI 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 thesea are already in the tony_bogons list.
If you press the 'Inspect' in the NAT and WAN firewall rules, do you see them matching?
NAT rules come before the firewall rule, I assume that was already mentioned in the thread. When I try that out, no rule on the WAN interface is necessary, on in the NAT port forwarding (and that creates one automagically).
You did press 'Apply' after changing the alias, yes?
@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