OPNsense 23.10.3-amd64 - DHCPv4 static entries not setup correct DNS servers

[Reiner030]

We are moving from pfSense to OPNsense and network routers step by step;
Last week we switched DHCP and had some trouble with one user which needs static IP for having dedicated outbound NAT for SEO work with Google.

It seems solved first but today she had again problems - not DHCP assignment anymore but now accessing internal services.
After quick investigation and tcpdump sniping it was clear that the DHCP servers offers the "default" DNS server (him itself) instead of our typed in ADS nameservers.

1st setup was static entry with mac/hostname/ip address and VLAN/Interface based DNS servers "only"
2nd setup was with same additional dns servers in static setup but still "defauilt server" assigned.

Quick workaround was to forward Unbound to query ADS with "private domains" setup as prepared.
But this seems to be a bug which should be fixed for situations where this workaround can't be done.
And we want also best the right DNS servers directly assigned.

Can someone proove it? Dependend on situation I can open bug report if needed on Github.

[Reiner030]

Nobody has this problem? Very weird similar to the problem itself...

Since there are many fancy blogs writing "howto debug DHCP packets" with all the same "clear" solution but no one has deeper hints for helpful for tcpdump calls I had to do some brain work ^^ because the first fetched packages where only the common packets from client to server without also wanted response

=> To get all packes and only these we need a) MAC addrresses of firewalls b) broadcast MAC address combined with OR ... and combined with AND with c) the individual MAC address of client.

Additional the interface and some parameters - here maybe not the bests - to get plain and verbose packet output on the common DHCP filter sequence port 67 aand 68 ...

In my case:

• interface: lagg0_vlan4 / lagg0_vlan14
• fw01: f4:90:ea:00:8f:1a
• fw02: f4:90:ea:00:8f:26
• broadcast: ff:ff:ff:ff:ff:ff
• client: 3c:18:a0:16:e7:2f

which gives the call for my Client LAN interface:

Code Select Expand

tcpdump -i lagg0_vlan4 -ennvvv port 67 or port 68 and '(ether host f4:90:ea:00:8f:1a or ether host f4:90:ea:00:8f:26 or ether host ff:ff:ff:ff:ff:ff)' and ether host 3c:18:a0:16:e7:2f


The testing notebook nb-277 is defined as static DHCP entry for both LAN004 and LAN014 similar;
only IP address, gateway and MAC are different to match the network card / network range similar to the common LAN Interface definitions (thes use both same DNS servers 10.30.2.5 and 10.30.2.6).

And then the funny things happens...
The LAN interface works as expected:

Code Select Expand


root@fw01:~ # tcpdump -i lagg0_vlan4 -ennvvv port 67 or port 68 and '(ether host f4:90:ea:00:8f:1a or ether host f4:90:ea:00:8f:26 or ether host ff:ff:ff:ff:ff:ff)' and ether host 3c:18:a0:16:e7:2f
tcpdump: listening on lagg0_vlan4, link-type EN10MB (Ethernet), capture size 262144 bytes
20:01:36.074762 3c:18:a0:16:e7:2f > f4:90:ea:00:8f:1a, ethertype IPv4 (0x0800), length 361: (tos 0x0, ttl 128, id 52519, offset 0, flags [none], proto UDP (17), length 347)
    10.30.4.11.68 > 10.30.5.251.67: [udp sum ok] BOOTP/DHCP, Request from 3c:18:a0:16:e7:2f, length 319, xid 0xe9e1af02, Flags [none] (0x0000)
          Client-IP 10.30.4.11
          Client-Ethernet-Address 3c:18:a0:16:e7:2f
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Request
            Client-ID Option 61, length 7: ether 3c:18:a0:16:e7:2f
            Hostname Option 12, length 6: "nb-277"
            FQDN Option 81, length 23: "nb-277.local.example.com"
            Vendor-Class Option 60, length 8: "MSFT 5.0"
            Parameter-Request Option 55, length 14:
              Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
              Router-Discovery, Static-Route, Vendor-Option, Netbios-Name-Server
              Netbios-Node, Netbios-Scope, Option 119, Classless-Static-Route
              Classless-Static-Route-Microsoft, Option 252
            END Option 255, length 0
20:01:36.074861 f4:90:ea:00:8f:1a > 3c:18:a0:16:e7:2f, ethertype IPv4 (0x0800), length 414: (tos 0x0, ttl 64, id 57212, offset 0, flags [none], proto UDP (17), length 400, bad cksum 0 (->7b9f)!)
    10.30.5.251.67 > 10.30.4.11.68: [bad udp cksum 0x1fcf -> 0xdf21!] BOOTP/DHCP, Reply, length 372, xid 0xe9e1af02, Flags [none] (0x0000)
          Client-IP 10.30.4.11
          Your-IP 10.30.4.11
          Client-Ethernet-Address 3c:18:a0:16:e7:2f
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: ACK
            Server-ID Option 54, length 4: 10.30.5.251
            Lease-Time Option 51, length 4: 600
            Subnet-Mask Option 1, length 4: 255.255.254.0
            Default-Gateway Option 3, length 4: 10.30.5.250
            Domain-Name-Server Option 6, length 8: 10.30.2.5,10.30.2.6
            Domain-Name Option 15, length 16: "local.example.com"
            T119 Option 119, length 78: <correct answer from search domain defintion>
            END Option 255, length 0



But the WIFI Interface like to use it's unbound DNS over the predefined servers:

Code Select Expand


root@fw01:~ # tcpdump -i lagg0_vlan14 -ennvvv port 67 or port 68 and '(ether host f4:90:ea:00:8f:1a or ether host f4:90:ea:00:8f:26 or ether host ff:ff:ff:ff:ff:ff)' and ether host 60:dd:8e:67:1d:7b
tcpdump: listening on lagg0_vlan14, link-type EN10MB (Ethernet), capture size 262144 bytes
19:58:51.983682 60:dd:8e:67:1d:7b > f4:90:ea:00:8f:1a, ethertype IPv4 (0x0800), length 361: (tos 0x0, ttl 128, id 47553, offset 0, flags [none], proto UDP (17), length 347)
    10.30.14.240.68 > 10.30.15.251.67: [udp sum ok] BOOTP/DHCP, Request from 60:dd:8e:67:1d:7b, length 319, xid 0x8f80b209, Flags [none] (0x0000)
          Client-IP 10.30.14.240
          Client-Ethernet-Address 60:dd:8e:67:1d:7b
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Request
            Client-ID Option 61, length 7: ether 60:dd:8e:67:1d:7b
            Hostname Option 12, length 6: "nb-277"
            FQDN Option 81, length 22: "nb-277.local.example.com"
            Vendor-Class Option 60, length 8: "MSFT 5.0"
            Parameter-Request Option 55, length 14:
              Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
              Router-Discovery, Static-Route, Vendor-Option, Netbios-Name-Server
              Netbios-Node, Netbios-Scope, Option 119, Classless-Static-Route
              Classless-Static-Route-Microsoft, Option 252
            END Option 255, length 0
19:58:51.983798 f4:90:ea:00:8f:1a > 60:dd:8e:67:1d:7b, ethertype IPv4 (0x0800), length 400: (tos 0x0, ttl 64, id 16000, offset 0, flags [none], proto UDP (17), length 386, bad cksum 0 (->7c5)!)
    10.30.15.251.67 > 10.30.14.240.68: [bad udp cksum 0x34a6 -> 0xcd6c!] BOOTP/DHCP, Reply, length 358, xid 0x8f80b209, Flags [none] (0x0000)
          Client-IP 10.30.14.240
          Your-IP 10.30.14.240
          Client-Ethernet-Address 60:dd:8e:67:1d:7b
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: ACK
            Server-ID Option 54, length 4: 10.30.15.251
            Lease-Time Option 51, length 4: 600
            Subnet-Mask Option 1, length 4: 255.255.254.0
            Default-Gateway Option 3, length 4: 10.30.15.250
            Domain-Name-Server Option 6, length 4: 10.30.15.254
            Domain-Name Option 15, length 16: "local.example.com"
            T119 Option 119, length 68: <correct answer from search domaain defintion>
            END Option 255, length 0


From DHCP Response fw01 is responsible for the client (and fw02 has same result) because I am wondering why there is no static entry neither for LAN nor WIFI client IP found:

Code Select Expand


root@fw01:~ # grep 10.30.4.11 /var/dhcpd/var/db/dhcpd.leases                                                                               lease 10.30.4.110 {
lease 10.30.4.111 {
lease 10.30.4.112 {
lease 10.30.4.113 {
lease 10.30.4.114 {
lease 10.30.4.115 {
lease 10.30.4.116 {
lease 10.30.4.117 {
lease 10.30.4.118 {
lease 10.30.4.119 {
root@fw01:~ # grep 10.30.14.240 /var/dhcpd/var/db/dhcpd.leases
root@fw01:~ #


but from GUI it's found/setup - see attachment.

When writing this answer down I remembered one other difference - the WIFI client IP was withing dynamic DHCP range while LAN client IP below it.
Tested it unsuccessfully by changing client IP to 10.30.14.14 (both outside below .21) so this is not the cause of failure.

[cookiemonster]

I hope I don't give you incorrect information, please verify or wait for another opinion.
First, check you have your static dhcp lease outside your dynamic range.
Second, check if you have Unbound listening on all interfaces.
Finally, I don't think there is the ability in the UI to define a different DNS server per client. I think if you need this, you would need to consider the use of mimugmail's "custom options" to see if that provides the means.

[Reiner030]

First, check you have your static dhcp lease outside your dynamic range.
Second, check if you have Unbound listening on all interfaces.
Finally, I don't think there is the ability in the UI to define a different DNS server per client. I think if you need this, you would need to consider the use of mimugmail's "custom options" to see if that provides the means.

Thx for hints but
1) in last paragraph I wrote that I moved it outside dynamic block without change
2) Unbound is listening on all interfaces but the problem is that the AD clients needs AD answers and not unbound answers .. (which I forwarded over unbound as workaround so far)
3) there are nearly all options also available for static dhcp clients like in usual DHCP options files/configs over all possible systems (firewalls, routers, dhcp services) ...

[Monviech (Cedrik)]

I think as soon as you leave a field empty, either in the global or the static dhcp pool options, it takes system defaults. I don't think static mappings inherit anything, they're little pools themselves with 1 IP.