Messages

(Not upgraded yet, will soon)

I have some geoblocking in my firewall (mainly to prevent direct attacks/spam from a few countries). One of these countries is China, a rather large source of this. But I just noticed that 101.47.29.67 was not blocked, while it is clearly Chinese. That made me wonder: are there tables I have to update or anything else I should do?

OK. Thanks both. The change popup mentioned the ipfw to pf thing, but I must have misunderstood. Anyway, waiting for 25.10.2 is probably fine for me. My OPNsense router is a SPOF in my small setup (the key elements in my landscape are failover etc, but not the router), so I am a bit careful/conservative.

25.4 is EOL so I will be upgrading to 25.10. But I noticed quite an important change: from ipfw to pf. Now, both work in a fundamentally different way (first/last rule match wins for instance). Is this change seamless? Any other gotchas?

Thanks! That makes it a lot easier. I was already looking at creating a custom script using pcftl, aliases, and a cron job.

I was looking at scheduling FW rules but it seems they work on a calendar one year in advance max. Am I correct in concluding it isn't possible to create a schedule that is more crontab like, like "every day from 09:00-17:00" or "every Sunday from 10:00-12:00"?

Problem solved and it is not a bug.

It turns out the Geolocation was at least one of the issues. There was a pass on a (pretty wide) source alias of countries for the NAT rule and it turns out an IP-address that all systems I checked tell me is in Germany wasn't seen that way by recent Geolocation by OPNsense. Geolocation is of course by definition not perfectly reliable, so this was technically my own fault.

Addition:

• Connecting from inside to the internal server on port 953 with dig works
• Connecting from inside to the internal server using hairpin (so outside IP address) on port 53 times out, but does not show a log entry from the firewall that it has been blocked
• Connecting from the outside to the outside IP address on port 53 times out and does show a firewall block log message on the default blocking rule

I recently updated to 25.4.2 Business Edition from 24.x Business Edition and it seems this has somehow made OPNsense block something it should not. I must stress 'seems' as I really suspect this is probably my problem, but I have been unable to understand what is going on. This is a bit of a pressing issue for me, as this blocks my upcoming LE certificate renewals.

I have a system on the inside that provides a DNS server on port 953 (this is for ACME DNS challenge and it runs alongside a regular internal DNS that listens on port 53, only reachable on the LAN). The ACME DNS challenge server works and internally is reachable internally on that server on port 953.

I have a NAT Port Forwarding rule that maps an outside port 53 on the WAN interface of one of my public IPs to an inside server port 953.

But when I try to reach the ACME DNS challenge server from the outside (and I have been running this without issue in 24.x for years, which is why I am now suspecting the upgrade) the traffic is blocked by the default deny rule. Hence, LE certificate updating has stopped working as LE cannot reach my ACME DNS Challenge server.

There is a FW rule on the WAN interface that explicitly passes it, but it seems not to be triggered:

Code Select Expand

@96 pass in log quick on igb0 inet proto tcp from <countries_letsencrypt_allowed:0> to <wan_vanroodewierda_rna_nl:1> port = domain flags S/SA keep state label "216b045bfd3fbe399846a0acb206d45b"
evaluations: 5
packets: 0
bytes: 0
states: 0
inserted: uid 0 pid 74119
state_creations: 0
time: n/a
@97 pass in log quick on igb0 inet proto udp from <countries_letsencrypt_allowed:0> to <wan_vanroodewierda_rna_nl:1> port = domain keep state label "216b045bfd3fbe399846a0acb206d45b"
evaluations: 0
packets: 0
bytes: 0
states: 0
inserted: uid 0 pid 74119
state_creations: 0
time: n/a
Any ideas where to look? Could this be a bug in 25.4 Business Edition?

I did not see a separate feature request possibility somewhere so I'm posting it here: it would be really helpful for me if the HAProxy version in OPNsense would support proxying UDP. I understand this is available in HAProxy, but OPNsense does not include a HAProxy that has that.

[UDP]

Thank you. I would like to try to set this up. However, I don't know how to make it so that UDP requests to port 53 are proxied. Can I, or does this mean only TCP DNS requests will be answered by that new virtual IP?

I want to use my OPNsense router as a proxy for two internal DNS resolvers. Preferably, I want a HA-setup where on the OPNsense a proxy runs that tests if my two internal DNS-es are alive and routes the UDP port 53 to an alive one. That way, I can let the DHCP of the OPNsense router hand out the OPNsense router's IP address as DNS to the DHCP clients.

Reason: I run two internal DNS resolvers. Currently, the DHCP on OPNsense hands out both to clients. It turns out I have many clients that will stick to the one they select first (especially iOS/macOS devices, but it may be the same for others). Recently, I have had availability issues on both where one failed because a switch in front of it had trouble, and the other failed because it had an ethernet hardware issue. Not at the same time, but that doesn't matter, because when I client had settled on one, it would stubbornly keep trying. that one, not switching to the other one. I think that is a problem with macOS/iOS, but as this is what I have to deal with (good luck in getting Apple to fix anything), I want my setup to be robust under the scenario that one of my internal DNS resolvers is unavailable.

I accept that makes the OPNsense into a SPOF, but if the router is down, not much will work anyway.

What is the best way to do this on an OPNsense business edition?

I have two internal DNS resolvers running on two different servers (different OS too). I currently give the IP addresses of both to the clients via DHCP, so each client gets two IP addresses to use as resolver (e.g. 192.168.1.5 and 192.168.1.6). But when one of these servers dies, the clients tend to remain stuck on that server for their DNS needs, and thus a lot of stuff starts failing. In general, it seems my clients (mostly Apple) don't really react to one of the DNS resolvers being unavailable, or at least not quickly.

I would like to add a virtual IP-address to OPNsense (e.g. 192.168.1.53) that passes traffic on to either 192.168.1.5 or 192.168.1.6, specifically UDP on port 53 of course, depending on availability. Is that possible and if so, how? I am running 24.10 business edition.

I'd like to see the 'Mode' (None/Active/Backup/Disabled) of a server in the Real Servers overview. Added this to github.

OK, my issue is now solved, but I am not sure why.

• I started with a GoDaddy-authenticated cert for my router, but the cert I ask for is a wildcard (not strictly necessary, but my router doesn't have a public DNS name and I like to keep it that way).
• I was hit my GoDaddy's sudden dropping everyone <50 certs from API access. My cert was still valid (until July 12)
• I spent a day trying to get CloudFlare and NameSilo running on OPNsense/ACME.sh, but failed. I did a few resets of teh ACME.sh plugin for OPNsense
• I moved to CNAME + self-hosted acme-dns, first getting that to work on another systems (Linux+Docker+certbot)
• I got acme-dns to work with the Linux+Docker+certbot system, but then for some reason, a test cert could be had via the ACME.sh plugin, but a production cert not
• I got the certbot+acme-dns working on macOS
• I still did not get it to work (production) on OPNsense. The log shows that curl fails to talk to my acme-dns server because of the cert acme-dns is setup with, but the other machine have no problem with that (fine) cert.

This was where I was when I posted the question.

Now, I did some editing and trial runs again. Staging cert worked. Then I tried production cert mostly to get logging for my problem-hunt. And lo and behold, suddenly it worked. It was able to use acme-dns, update the TXT record, and LE could validate.

Happy enough that it works now. But not really an idea why acme.sh from OPNsense first had problems connecting to my self-hosted acme-dns (with its curl throwing up the error with value 60, whereas the certbots on my LAN had no issue with it) where now it does work. A mystery.

I got acme-dns and certbot+plugin to work. My acme-dns service is fine.

I am starting to suspect OPNsense has an outdated Intermediate cert that is no longer used by LetsEncrypt.