For historical reasons, I have the following network structure:
- Fiber ONT (Deutsche Glasfaser) <-> Fritzbox 7490 (router mode) <-> Opnsense <-> ...
The above scenario worked fine for the last year (without interruptions). But the signal reception of my DECT phones connected to the Fritzbox is not good in some parts of my house, so I want to move the Fritzbox to a new location. This is a good time to remove the Fritzbox from the WAN side of the Opnsense and put it as a dedicated device in a separate VOIP VLAN. So far, so good. A few questions arise.
- The network card in the WAN (Intel X553) had repeated connection losses in the past, which I solved by disabling EEE (Energy Efficient Ethernet) on the Fritzbox. I am not sure if the Opnsense network card (Intel X553) supports configuring EEE itself (setting the system tunable "dev.ix.n.eee_state=0" via SSH results in a hung SSH session. Finally, this parameter is not set). Does anyone have recommendations to avoid such connection loss issues in advance?
- There were some discussions in the forum in the past about missing IPV6 prefix and address assignments (especially in case of connection loss) with Deutsche Glasfaser. On my Fritzbox, such problems never occurred in the past. Does anyone know the reasons some users have pointed to? I think the DHCP DUID should be persistent at least during boot cycles. Is that correct?
- Modern SIP clients should derive the IP address for the SIP server by querying the SRV DNS record instead of directly querying the A record. Does the Opnsense firewall support DNS-based firewall rules based on SRV records?
1. That largely depends on if the ONT does EEE, so I would worry only if the problem turns up.
2. IHMO these were mostly configuration errors by newbies who did not follow all instructions by the letter or tried more sophistcated setups (like LAN bridges, again, without following instructions closely).
3. AFAIK, no. But why would you? The SIP IPs are known beforehand, so you can put them into a firewall alias. SIP nowadays does need a port forward, but if you know your ISP, you can also limit inbound connections to their ASN.
I always restrict such devices to my IoT network, where they cannot do much harm, anyway.
Quote from: meyergru on November 27, 2024, 08:13:55 PM
3. AFAIK, no. But why would you? The SIP IPs are known beforehand, so you can put them into a firewall alias. SIP nowadays does need a port forward, but if you know your ISP, you can also limit inbound connections to their ASN.
I always restrict such devices to my IoT network, where they cannot do much harm, anyway.
I have had quite a few SIP setups that worked without inbound forwarding, modern SIP is supposed to be able to detect NAT and work through it.
Quote from: schnipp on November 27, 2024, 06:05:34 PM
Does the Opnsense firewall support DNS-based firewall rules based on SRV records?
A while ago I used dnsmasq ipset feature to implement firewall rules like "allow *.example.com". dnsmasq would add the A and AAAA results of a DNS query to an iptable that can be referenced as an external alias in OPNsense and thus used in FW rules. This worked well, but since the firewall has no idea about DNS TTL, these rules may live too long, creating a possible security problem. That's why I didn't put it in prod. Also, I believe ipset support has since been removed from FreeBSD.
Also, dnsmasq can create artificial SRV records.
All that said, I don't expect SIP servers to change their names or addresses on a regular basis. So, all this flexibility is probably overkill.
Quote from: meyergru on November 27, 2024, 08:13:55 PM
1. That largely depends on if the ONT does EEE, so I would worry only if the problem turns up.
2. IHMO these were mostly configuration errors by newbies who did not follow all instructions by the letter or tried more sophistcated setups (like LAN bridges, again, without following instructions closely).
3. AFAIK, no. But why would you? The SIP IPs are known beforehand, so you can put them into a firewall alias. SIP nowadays does need a port forward, but if you know your ISP, you can also limit inbound connections to their ASN.
I always restrict such devices to my IoT network, where they cannot do much harm, anyway.
Thank you very much.
Regarding the third point, one of my former ISPs sometimes changed SIP entrys in DNS, so that I had to reconfigure rules in the Opnsense. ASN is my fallback scenrario in case reconfiguration is often needed .
Quote from: bimbar on November 28, 2024, 10:35:36 AM
I have had quite a few SIP setups that worked without inbound forwarding, modern SIP is supposed to be able to detect NAT and work through it.
Do you have one for "Deutsche Glasfaser"? Unfortunately, every SIP provider implements differently, so that there is no global setup. Otherwise, I have analyse the SIP communication and perform configuration on that results.
Quote from: mooh on November 28, 2024, 02:51:18 PM
[...]
Also, dnsmasq can create artificial SRV records.
All that said, I don't expect SIP servers to change their names or addresses on a regular basis. So, all this flexibility is probably overkill.
Unfortunately, one of my former ISPs did change from time to time. I'll have a look on dnsmask. If nothing on that works, I'll use the ASN as a fallback solution. Thanks.
Restructuring my network is done and tested for a longer time. All three topics mentioned in my first post are no issues at all. The only thing which actually does not work anymore is IPv6 privacy extensions. The reason is that no IPv6 address with activated autoconf flag is assigned to the WAN interface. I have to do some more investigations.