Messages

I fixed the link.

Thank you for sharing your hard work.  Amazing write up!  :D

I have a permanent 48 and a different 64, from which I have allocated PDs/subnets to two separate LANs.  The LAN NICs are configured with a corresponding static 64 each.  I don't host public services, so some of your good advice won't be applicable to my setup.  Thanks again.

Any idea why on the KEA leases table GUI, IPv6 addresses leased to LAN devices showed up as belonging to the WAN interface until I rebooted the router?

Other than this little glitch, the KEA DHCPv4 and v6 services are both working faultlessly so far.

DHCPv6 works only for some clients - and sometimes, it is only being used to fetch DNS info, not IPs nor routes.

I was only testing Dnsmasq local address resolution for IPv4 - I had no IPv6 reserved addresses configured, only subnets for PD.  The DUID and/or MAC address of the client did not prove effective to allow local address resolution for IPv6 at all and for IPv4 it only worked some times.

Take a look at this for a more in-depth explanation and a remedy.

When I click on your link I don't arrive at the correct page.

A quick update on progress.

I had another go at configuring Dnsmasq.  DHCPv4 just works^(TM).  DHCPv6 does not work with the phones, but works with PCs.  There seems to be an issue related to the current phone firmware, which solicits via DHCPv6 an IPv6 address only at phone boot time and does not seek to renew it thereafter.  For some reason, the phones do not pick up an IPv6 address on this initial transaction with Dnsmasq and they end up with no IPv6 address at all - unless I have configured their firmware to use SLAAC.  I have set radvd to 'Assisted' and works fine with ISC and KEA.  I have not tried to configure RA on Dnsmasq itself.  I rebooted the phones with ISC DHCPv6 enabled (Dnsmasq disabled) in order for them to obtain an IPv6 address, then disabled ISC and enabled Dnsmasq to see what happens.  The Dnsmasq DHCPv6 does not recognise the IPv6 already allocated to the phones and continues to advertise different IPv6 addresses to them non-stop once a second flooding the logs.

The resolving of local domain names with Dnsmasq has been a hit & miss affair.  When I connect a host with a reserved IP address to the router, it obtains its address and its local domain name can then be resolved.  A few hours later I get NXDOMAIN responses from the router on port 53, while it resolves successfully the host's name on port 53053.  Restarting unbound didn't fix it.  This is not a major issue for my simple use case with less than two dozen hosts at any time and LAN servers/printers having reserved addresses anyway.  Perhaps setting lease renewal in more frequent intervals would address this local DNS issue, but given the above I decided to move on from Dnsmasq for now.

I then tried to set up KEA DHCPv4 and DHCPv6 with no DNS for local addresses. This was overall an easier and quicker setup than Dnsmasq for me.  DHCPv4 works reliably, leases are renewed regularly and more frequently than Dnsmasq.  KEA DHCPv6 has no problem allocating IPv6 addresses to the phones when they boot and extending their leases (every 20 minutes) on the same IPv6 addresses they obtained initially without fuss.

The only thing which caused some concern was the GUI table with all KEA DHCPv6 leases showed the phones' interface as WAN, instead of OPT1.  See attached screenshot, the top 4 entries show the phones connected on OPT1 NIC, but the GUI shows WAN interface instead.  Is this a parsing error, or something more critical?  After I rebooted the router the problem was gone.

PS. I removed some of the addresses to retain privacy.

Hi All,

I am trying to migrate from ISC DHCPv4 and DHCPv6 to Dnsmasq,  with only partial success so far.  I have followed the docs and example provided, but my understanding of Dnsmasq is rather poor and consequently the result is only partly working as intended.

1. When SIP phones are set with their own static IPv4 (no DHCPv4 solicitation) and also configured to obtain a stateful DHCPv6 address from the router, plus SLAAC, they fail to obtain an IPv6 address:

https://service.snom.com/display/wiki/HowTo+-+Networking+-+IPv6

The logs show a sequence of DHCPSOLICIT from the phones and DHCPADVERTISE from the router's interface, but eventually they time out and do not obtain any IPv6 address whatsoever.  Interestingly, other hosts receive IPv6 stateful addresses off the same router NIC, so far it is only the phones which fail to do so.  The ISC DHCPv6 had no problem serving the phones with an address from within the IPv6 range allocated to the router's NIC.

I still have Services > Router Advertisements enabled, rather than the Dnsmasq > General > Router advertisements, which is left disabled.  I understand this is the recommended approach, have I got this wrong?  Is there anything else I need to configure to have Dnsmasq working with IPv6 as ICS is able to do?

2. LAN clients receive the configured Dnsmasq host 'name.internal' as set in  Services > Dnsmasq > Hosts, but nslookup fails to resolve local domain names returning NXDOMAIN, while reverse lookups against the host's IP address return correctly the host name.  What could have I missed or misconfigured?

Grateful for any pointers.

You can update safely. ISC is still very much there in 25.1.7.

I updated last night and nothing broke for me.

Thanks, this will give me some (more) time to look into the alternatives.

Is there a migration guide from ISC to either KEA or dnsmasq, rather than configuring either of these alternatives to ISC afresh as described in the guide?  I consider my DHCP setup rather basic, but since I am not familiar with either KEA or dnsmasq it will take me time to look into pros & cons of either and walk through the documentation.

At least, can I update 25.1.6_4 to 25.1.7 and continue using ISC just as it is configured for now, or will it be removed by the new DHCP package(s) and leave me with a broken configuration?

Probably not directly related to gateways config, but I thought I should post this just in case.  I also received the same red coloured "Danger Unexpected error check log for details" pop up when I started an update to 24.7.12 earlier today.  The update completed a minute or so later and the system rebooted fine.  I can't find a php error.  The dpinger works and monitors the gateways, before and after the update, so I don't know why popped up.

Ok, after digging a little deeper I did a packet capture on the Apps on my Android phone RTP & STUN are being blocked and some DNS queries on port 53.

I experienced a problem with RTP failing due to packet size on releases newer than 24.7, something to do with how fragmentation is now being processed.  As a workaround I had to edit the VoIP phone and remove enough codecs from its configuration to allow packets to go through.  Perhaps your problem is related?

I'm on release 24.7.4_1 now, but the same RTP fragmentation problem remains.   :(

I noticed something with ping which I can't recall if it was the same on 24.7.  When I ping using IPv4 to check MTU size, it complains  about the packet size (unless I use sudo):

Code Select Expand

~ $ ping -4 -c 1 -D -s 1472 www.google.com
ping: packet size too large: 1472 > 56: Operation not permitted

However, no such problem with IPv6:

Code Select Expand

~ $ ping -6 -c 1 -D -s 1452 www.google.com
PING(1500=40+8+1452 bytes) 2001:XXXXXXXXXXX --> 2a00:1450:4009:81f::2004
1460 bytes from 2a00:1450:4009:81f::2004, icmp_seq=0 hlim=120 time=6.121 ms

--- www.google.com ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 6.121/6.121/6.121/0.000 ms

Could someone please confirm if ping packet size is meant to have this constraint on IPv4 only, or if it is a result of the later releases?

Last time I used this setup a 4/5G modem the ISP provided CGNAT, so my suggestion would not work.  If you set keep alives from your network hopefully the VPN will not drop out.

Sorry, my mistake....the opnsense SHOULD see the public ip right? (didn't tried yet)...now the wan has a static ip4 ip, should i put PPPoE?

Place the modem in fully bridged mode and configure the opnsense WAN interface with IPv4 PPPoE, adding your login credentials at the "PPPoE configuration" section of the WAN interface page.

My problem is that I have 3 vpn of the same provide implemented and working with a fall-back logic.

You will need to replicate this VPN configuration at the opnsense router.  A bridged modem device would perform no routing.  A double NAT configuration could break many services, not just VPN.

I don't have access to EETV or any BT offering to compare notes, but have a look at these configurations to get you started:

https://forum.opnsense.org/index.php?topic=23064.0
https://www.draytek.co.uk/support/guides/vigor-2860-vdsl-setup

If you have access to a BT HomeHub and it is working as expected with EETV, then you can login into its GUI to find the required router settings, then use these on opnsense.

No, opnsense is installed on bare metal and its igb0 NIC is connected directly with a CAT6 cable to the ONT.

I've had an on & off MTU configuration issue with opnsense for years now.  It used to be the case when I'd set WAN's PPPoE MTU on the GUI to 1508, this would push the MTU of igb0 to 1508 to allow 8 bytes for the PPPoE header+ID tag and leave 1500 bytes for the  payload through WAN.  Unlike meyergru I don't use VLAN, but if I did the VLAN tag would add another 4 bytes for the VLAN tag, increasing the frame size to 1500+8+4=1512.

At some point the WAN interface settings GUI no longer worked this way, so I'd set the MTU for igb0 manually to 1508 on the console, which would provide a 1500 MTU for the WAN interface.  Annoyingly, I'd have to repeat this operation after each update/upgrade of the opnsense firmware - the setting would not stick over a reboot.

For the last few months, up and including 24.7, the MTU setting had started to stick, so I didn't have to look into (re)setting it manually.

Anyway, after I saw the phone would also fail to work over IPv6 and spotted errors on the phone logs mentioning something about no PDU received, I thought it must be an MTU issue again.  I checked with ifconfig and the Interfaces GUI details and was surprised to see pppoe0 showing an MTU of 1508, instead of 1500.  The igb0 link also showed MTU 1508, as it should.  Both couldn't be right.  However, ping tests on the router showed the WAN MTU was indeed 1500:

~ # ping -6 -c 1 -D -s 1452 google.com
PING(1500=40+8+1452 bytes) 2001:XXXXXXXXXXXXXX --> 2a00:1450:4009:827::200e
1460 bytes from 2a00:1450:4009:827::200e, icmp_seq=0 hlim=120 time=5.871 ms

~ # ping -6 -c 1 -D -s 1453 google.com
PING(1501=40+8+1453 bytes) 2001:XXXXXXXXXXXXXX --> 2a00:1450:4009:827::200e
ping: sendmsg: Message too long
ping: wrote google.com 1461 chars, ret=-1

The above ping tests are no different when run with firmware 24.7, although with 24.7 the pppoe0 MTU is displayed correctly as 1500 not 1508.

Here is what I fail to understand:

Despite the displayed MTU size anomaly, ping tests indicate an effective WAN MTU of 1500 bytes with both 24.7 and 24.7.x - so why does a larger INVITE datagram go through fine on 24.7, but fails to do so with 24.7.x?  What else is at play here?

Up to this point, I still think that the outbound NAT rules are wrong one way or another. Maybe the DNS entries do not map to the suspected IPs, maybe it is even worse and he is behind CGNAT or other type of double NAT.

Perhaps my reasoning was wrong, but I was thinking all that changed to cause the phones to stop calling out was the opensense firmware update.  It could be the updates allowed for hidden errors in my configuration to show up, and/or perhaps something else was clashing with the latest firmware changes.  As it happened it was an MTU issue causing fragmentation.

Either way, thank you meyergru for your config suggestions, it helped me improve and tidy up my rules.

Thank you guys for all your help!  :)

TL;DR:  In my case the problem has been with the way the recent kernel changes have affected how the MTU is being processed.  Just to confirm, in my case I did not need a "static port", or additional outbound NAT beyond the automatically created NAT rules when setting Port Forwarding.  This is because in this case the phones and ISP's SIP gateway are 'smart' enough to acknowledge the SIP/RTP ports requested by the phones and use them reliably.

Since I started looking at this problem, I've spent some time checking firewall rules and trying all the different settings meyergru suggested, including "static port" for outbound NAT.  I tried setting a Hybrid Outbound rule with:

Destination address: any

and when it made no difference with:

Destination port: the ISP's SIP/RTP addresses.

Still no success.  I also removed port translation as recommended and took the opportunity to tidy up addresses in my aliases for the ISP's SIP/RTP gateway.  Without a usable VoIP setup I was heading back to the 24.7 firmware, but as a last thing before calling it a day I decided late yesterday to use IPv6, thinking this would allow me to do away with NATing and port forwarding complications, or potential configuration errors.  At this point I discovered with IPv6 the phone registration would fail altogether!  So instead of the IPv4 issue of just outgoing calls failing, with IPV6 the whole lot stopped working.  I suspected an opnsense MTU regression problem (has happened before), but ran out of time.

This morning I checked the WAN MTU and sure enough things looked different ...

Code Select Expand

igb0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1508
        options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>
[snip ...]
pppoe0: flags=10088d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1508
        description: WAN (wan)


Then I saw BoodahsFever's post (thank you!), mentioning the INVITE packet size and how it can get larger with ever more RTP codecs added to it.  So I changed the phone settings to advertise only two codecs suitable for my ISP, which reduced a 1512 byte WAN packet down to 1376 and from then on outgoing calls became possible again.   :D

NOTE: Some months/years ago I had to keep setting the MTU manually using ifconfig on igb0 to 1508, so that the WAN PPPoe0 MTU would have a full IPv4 ethernet  payload of 1500.  Now ifconfig displays the ethernet MTU as 1508, but ping tests indicate it is still 1500.

Either way, should packet fragmentation break VoIP?

Something in the 24.7.x changes has caused my specific problem, but more applications/devices may be lurking out there similarly affected.  Is this something to be addressed in a future update?