Hello,
I'm trying to limit all incoming connections on my FW to Cloudflare IPs only (on 80 & 443 ports)
I created the alias with the list from Cloudflare and it's updating without issue.
I created my rules but it's still possible to connect with any IP (testing with a VPN)
If I add the Cloudflare IPs in my NAT rules I can't access anything.
I attached my NAT & WAN rules
If anyone can help that would be greatly appreciated !
Hmm, the NAT rules indicate an associated rule, yet none of the FW rules match (they both should have the same source).
Quote from: saintjimmy on February 09, 2025, 08:01:36 PMHello,
...
I created my rules but it's still possible to connect with any IP (testing with a VPN)
If I add the Cloudflare IPs in my NAT rules I can access anything.
...
Are you sure your test is going through the VPN? With a split tunnel and NAT reflection, you could redirect locally.
The FW live view should show you the exact source.
And the 2nd statement is not really clear...
Yes I tried from outside my network
Sorry for that 2nd sentence I corrected it
If you restrict the rule to specific sources, YOU can no longer access the IP:port. Only the source(s) can.
Are your firewall logs not matching your rules?
Or maybe YOU can not access something else...
You ought to put yourself in the shoes of people reading your posts. We don't have the same context you have.
Let me know if I can be clearer:
I want all incoming connections on port 80 & 443 to blocked on the Wan interface except the ones coming from Cloudflare IPs.
I created the rules in the Wan interface as you can see in my screenshot, but theses rules seems uneffectives.
I tested the access from other IPs than my network (VPN, 5G network, Work,etc) and I still can access these ports.
My NAT Rules and WAN rules are attached for context, there is nothing else relevant I think ?
No, your NAT rules are only visible in part. The vital portion is left out:
NAT "pass" firewall rules are processed even before floating rules, so if you use that within your port-forwarding rules and have not set a source restriction, everything can use these rules, regardless of other firewall rules you create.
You will either have to use "associated" rules and fine-tune those or simply use a source restriction with your aliases in the port-forwarding rules.
On a side note, that is the same thing when you want a geoblocking rule: It will be processed after the port forwards.
Ok maybe you need all of the WAN rules ? Because the screenshot of my NAT rules is the complete list.
After looking in the logs every attempt from a non authorized IPs is allowed and match the "let out anything from firewall host itself" rule I don't understand why the rules created in the WAN interface don't apply ?
Because if you set "pass" in the "Filter rule association" of a port forwarding rule (which you can only see in the details, not in the list of rules), it is, as I said, an implicit, invisible rule that is not reflected in the WAN firewall rules and has a higher priority than all the other rules.
I never check "pass" but instead create an associated filter rule
Following your explanations I have a better understanding of how OPNSense manages its firewall rules, thank you for that
Now I deleted all my NAT & FW rules and decided to begin from scratch. I create a NAT rule allowing traffic on HTTPS from any source to my reverse proxy. I didn't chose to attache a FW rule automatically or whatever.
I then created a FW rule in WAN interface allowing ony Cloudflare IPs to join my reverse proxy.
And it seems to work !
Is it the proper way to do or can it be improved/hardened ?
What's the value of "filter rule association" for the Port Forward rule?
It's possible that if it's none, then FW rules get evaluated as usual.
I've never used it this way but it's how I read Filter rule association Doc (https://docs.opnsense.org/manual/nat.html#filter-rule-association).
It does not seem very efficient.
If the source is constrained in the PF rule, then Pass (recommended) is sufficient but has the disadvantage of not producing artifacts in the FW view.
With Pass, there's essentially an invisible FW rule corresponding to the PF rule.
Personally, I always use an associated rule. I suspect only that rule is evaluated at runtime (equivalent to Pass) but I'm actually not 100% sure.
If all you're doing in the FW rule is constrain the source, you might as well do that in the PF rule.