Messages

[DNS over TLS]

I am only wanting a backup DNS method in case dns over TLS Fails

Refer to the note in OPNsense documentation found here: https://docs.opnsense.org/manual/unbound.html#dns-over-tls

It's possible that if DNS over TLS fails to Quad9 due to a problem at their end or somewhere in between, its quite probable queries using the traditional port 53 will also fail.

As a contingency in my configuration I have include the two Cloudflare DNS servers, which also provide threat-blocking over DNSSEC, but they are disabled. I've not experienced problems with Quad9 where I've had to use them.

In the event Quad9 becomes unusable, I would add Cloudflare DNS servers to my list of external trusted DNS servers and then enable them in Unbound's DNS over TLS settings, as well as disabling the Quad9 entries.

[Forward first]

this option called forward first.  is this new?

No, its not new.

If I understand the behaviour for a "." zone, as per your configuration (domain field is bank), I expect this will result in DNS queries being forwarded to root servers in the event SERVFAIL is encountered - this may not be what you want.

I have configured Unbound to use the two DNS servers at Quad9 which offer Threat-blocking with DNSSEC and I do not have Forward first enabled.

An extract from an unbound.conf file which can be downloaded from Quad9.net where they will be the sole DNS provider;

https://docs.quad9.net/assets/conf/freebsd/forward.conf

Code Select Expand

forward-zone:
    name: "."
    forward-tls-upstream: yes        # Use DNS-over-TLS
    forward-first: no            # do NOT send direct

Here is the information on the Unbound site: https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#unbound-conf-forward-forward-first

In my environment, I've blocked all access to external DNS servers as best I can. Restricting TCP/UDP port 53 was easy, it's the DoHS which is the challenge.

These are the two forwarders I've configured for Quad9.

It means that all the rules need to be redone because migrating them doesn't work

It seems you are in the minority of users experiencing the impossibility of migrating firewall and NAT rules.

Perhaps you could invest time working through your issue and find a way to restore your old configuration file and get it working in a way where information already provided has not worked.

Considering the pain this has caused you, and in the interest that another user may some day befall your predicament, you could document the process you used and post it to the list, so they may also benefit from your experience.

I had only one plugin installed, so I don't expect that any plugin conflicts would need resolving

Referring to page 6, after you powered on the restored system, did you check the 'Status' page and was the 'Resolve plugin conflicts' button there!?

Migrating the rules does not work

Sorry to hear that.

The notes were written and tested using a configuration file from February 2022 and this process was what worked the smoothest.

Migrating the firewall and NAT rules prior to upgrading to 26.7 allows you to edit them in 26.7.

[Rules [new]]

Where is the plugin needed to edit these rules

In the steps I provided, after updating to 26.1.11_10 the next step after verifying the dashboard is to migrate the firewall rules to Rules [new].

A similar question came up recently, with someone wanting to restore their configuration file from 21.7.8

I've attached notes to restore an old configuration file and get up to date using 25.1.12. Of course, there have been additional updates since the notes were written.

Hope the notes helps you get going relatively smoothly.

The mirrors still include old versions and 25.1 is still listed.

the ATA use the opnSense as DNS,

Are you using Unbound as the DNS server on your OPNsense box?

a normalization rule for the LAN and WAN Network

Unless they only accept VoIP connections with specific DSCP markings, the PF Normalisation may not provide you with any perceivable benefit. If you haven't configured FQ_CoDel queues in OPNsense, you may want to set it up as this will provide you with lower latency for your connections to the Internet - See https://docs.opnsense.org/manual/how-tos/shaper_bufferbloat.html#fighting-bufferbloat-with-fq-codel

Can you be sure AI knows the DSCP settings for your VoIP service!?

There is a link in this posting to documentation which may provide the DSCP markings you require - https://telekomhilft.telekom.de/conversations/festnetz-internet/dscp-klassen-f%C3%BCr-voip/668669584ae73561dada193e

after upgrading to 26.7.5 the error has gone away

The 'apcupsd' package was re-installed when upgrading to 26.7. I expect this is what fixed your problem.

Postfix is the default MTA and not a plug-in : Right ?

It doesn't appear that mail is installed in OPNsense by default, at least not on mine. There is nothing in /etc/mail and no sendmail program.

But how about adding .conf files

I have done this with Unbound - after reading the documentation. Your mileage may vary for other services, depending on how OPNsense configures them. However, it's best they are managed using an applicable plug-in.

[Edit] Of course, such custom settings wont be included in a back-up.

OPNsense Web GUI for Unbound lets me know there is a configuration which could possibly overwrite settings in the Web GUI.

[Advanced 802.1Q VLAN]

Netgear's unmodifiable "default" uses vlan tag 1

Referring to the User Manual for this switch (See page 45 - https://www.netgear.com/support/product/ms308e), you need to activate Advanced 802.1Q VLAN mode in order to change the PVID of a port.

Any suggestions on what I could check next would be greatly appreciated.

Is this a new installation or has it worked in the past?

I'm unable to resolve any SRV records for tel.telekom.de, but this may be because I am elsewhere in the world.

Searching the net it appears the SIP server to use is tel.t-online.de and SRV records can be resolved for this address.

Perhaps this page will help: https://www.telekom.de/hilfe/internet-telefonie/telefonie/voice-over-ip-sip-client

Another tidbit I came across is you need to be querying the DNS servers offered by Telekom to ensure it works: https://support.yeastar.com/hc/en-us/articles/360014536894-Recommended-SIP-Configuration-for-Deutsche-Telekom

Which DNS servers are used by the ATA?

If you find you can receive a call as soon as the ATA has registered, but you can't receive an incoming call after a couple of minutes, or until the next registration, you could drop the Keep-Alive interval to 25 seconds. If you use TCP for the SIP connection the state timeout should be the default of 86400 seconds when it is established.

I recently moved some numbers to another ITSP and I'm using TLS and SRTP. I've set the registration interval for this service to 5 minutes.

Have you created specific firewall rules for your VoIP service?

You mentioned you disabled 'Normalization', are you referring to OPNsense?

Does the QoS from Telekom use DSCP and do you know what values these should be?

Don't you need to do some Port Forwards for VoIP

I haven't encountered a situation where port-forwarding has been required for VoIP. Providing the connection that your registration is going through is kept alive, incoming calls should reach the ATA.

The problem with null routing is that it breaks policy based site-to-site VPNs

If you are able to reconfigure your IPSEC policy based VPN's to use VTI's, you may overcome the discarded packets.

If anyone on this list has used the 'return' or 'return-icmp' option in their pf firewall rules for ICMP packets, they may be able to advise which versions of OPNsense / FreeBSD it was known to work in.

You could file a bug report with FreeBSD.

[Update] Alternatively, you may be able to set up a UDP ping between the hosts and react on the responses received.

It appears to be a pf issue. I don't have a convenient way to test UDP (e.g. traceroute, where the application will report unreachables clearly), but TCP returns RST. I'm too lazy to run a capture. ICMP, as you noted, appears to return nothing. I do not know offhand if the "blackhole" sysctls affect this, as I have them... unholed; I don't see an ICMP sysctl offhand that would affect unreachables (other than net.inet.icmp.icmplim).

A search turned up a couple forum posts on the issue (other than this forum); I didn't try to dig into bug reports.

Edit: Ha! lmoore's post - I use bridges, so that appears to be my issue at least. Interesting.

I stand corrected with my assertion about this not being in PF.

I found an old IPF ruleset which included;

block return-icmp(host-prohib) in quick proto icmp all icmp-type echo group 210

Applying this to pf on an OpenBSD boxen as;

block return-icmp(host-prohib) in quick inet proto icmp all icmp-type echoreq

We see the expected reply.

00:22:30.237183 10.200.128.22 > 10.200.128.20: icmp: echo request
00:22:30.237271 10.200.128.20 > 10.200.128.22: icmp: host 10.200.128.20 unreachable - admin prohibited
00:22:31.245814 10.200.128.22 > 10.200.128.20: icmp: echo request
00:22:31.245863 10.200.128.20 > 10.200.128.22: icmp: host 10.200.128.20 unreachable - admin prohibited
00:22:32.245857 10.200.128.22 > 10.200.128.20: icmp: echo request
00:22:32.245904 10.200.128.20 > 10.200.128.22: icmp: host 10.200.128.20 unreachable - admin prohibited

Changing the rule to;

block return in quick inet proto icmp all icmp-type echoreq

00:25:40.316392 10.200.128.22 > 10.200.128.20: icmp: echo request
00:25:40.316483 10.200.128.20 > 10.200.128.22: icmp: 10.200.128.20 protocol 1 port 15632 unreachable
00:25:41.325803 10.200.128.22 > 10.200.128.20: icmp: echo request
00:25:41.325888 10.200.128.20 > 10.200.128.22: icmp: 10.200.128.20 protocol 1 port 28145 unreachable
00:25:42.325833 10.200.128.22 > 10.200.128.20: icmp: echo request
00:25:42.325922 10.200.128.20 > 10.200.128.22: icmp: 10.200.128.20 protocol 1 port 10076 unreachable

In OPNsense the rule appears as;

block return in log quick inet proto icmp all icmp-type echoreq label "<id>"

tcpdump does not show any form of reply.

A little more digging around and testing is required.

I have a HDD with FreeBSD 15.1 installed on it. It will be interesting to see how it behaves.

[Edit] The same is observed with a generic installation of FreeBSD 15.1 - seems like an upstream issue.

Rule:
@1 block return-icmp(host-prohib) in log quick inet proto icmp all icmp-type echoreq
pflog:
2026-09-18 02:14:51.779906 rule 1/0(match): block in on em0: 10.200.128.22 > 10.200.128.2: ICMP echo request, id 18879, seq 0, length 64
2026-09-18 02:14:52.785960 rule 1/0(match): block in on em0: 10.200.128.22 > 10.200.128.2: ICMP echo request, id 18879, seq 1, length 64
2026-09-18 02:14:53.785920 rule 1/0(match): block in on em0: 10.200.128.22 > 10.200.128.2: ICMP echo request, id 18879, seq 2, length 64

tcpdump:
02:16:23.919342 IP 10.200.128.22 > 10.200.128.2: ICMP echo request, id 53324, seq 0, length 64
02:16:24.925840 IP 10.200.128.22 > 10.200.128.2: ICMP echo request, id 53324, seq 1, length 64
02:16:25.925842 IP 10.200.128.22 > 10.200.128.2: ICMP echo request, id 53324, seq 2, length 64

But changing the rule from "REJECT" to "BLOCK", either incoming on lan or outgoing on WAN does not give me an icmp-reply

man page for pf.conf(5) - https://man.freebsd.org/cgi/man.cgi?query=pf.conf&apropos=0&sektion=0&manpath=FreeBSD+15.1-RELEASE+and+Ports.quarterly&format=html#PACKET_FILTERING