Setting filters on a DMZ interface

[tonys]

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.

[EricPerl]

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.

[tonys]

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

[tonys]

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.

[Patrick M. Hausen]

Destination muss "WAN address" sein.

[tonys]

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.

[Patrick M. Hausen]

Sorry for answering in German. Confused with another thread. Can you show that automatic rule?

[EricPerl]

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

[tonys]

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

[tonys]

+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???

[Patrick M. Hausen]

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

[EricPerl]

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

[tonys]

@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

[Patrick M. Hausen]

The port forward needs to read

Source: !tony_bogons
Destination: WAN address

Also please show the tony_bogons alias.

[tonys]

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.