DHCP client source port?

[sjm42]

Well, when my OPNsense is trying to renew its WAN address with DHCP, I see its udp source port is a random upper port.
Is this behaviour normal, acceptable and per specifications? My ISP seems to only accept dhcp requests from source port 68.

I am wondering, does my firewall source NAT its own self-initiated traffic and that is why dhcp unicast gets a different port?

Slightly anonymized tcpdump follows.
The first (unicast) dhcp request never gets a response, but the second request to broadcast address does.

12:59:09.799559 IP (tos 0x10, ttl 128, id 58116, offset 0, flags [none], proto UDP (17), length 328)
    x.y.169.21.6671 > x.y.168.1.67: [udp sum ok] BOOTP/DHCP, Request from 00:e2:69:65:3a:25, length 300, xid 0x11fa7b4a, secs 1508, Flags [none] (0x0000)
     Client-IP x.y.169.21
     Client-Ethernet-Address 00:e2:69:65:3a:25
     Vendor-rfc1048 Extensions
       Magic Cookie 0x63825363
       DHCP-Message Option 53, length 1: Request
       Client-ID Option 61, length 7: ether 00:e2:69:65:3a:25
       Hostname Option 12, length 4: "opns"
       Parameter-Request Option 55, length 10:
         Subnet-Mask, BR, Time-Zone, Classless-Static-Route
         Default-Gateway, Domain-Name, Domain-Name-Server, Hostname
         Option 119, MTU
       END Option 255, length 0
       PAD Option 0, length 0, occurs 29

13:00:53.801032 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    x.y.169.21.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:e2:69:65:3a:25, length 300, xid 0x11fa7b4a, secs 1612, Flags [none] (0x0000)
     Client-IP x.y.169.21
     Client-Ethernet-Address 00:e2:69:65:3a:25
     Vendor-rfc1048 Extensions
       Magic Cookie 0x63825363
       DHCP-Message Option 53, length 1: Request
       Client-ID Option 61, length 7: ether 00:e2:69:65:3a:25
       Hostname Option 12, length 4: "opns"
       Parameter-Request Option 55, length 10:
         Subnet-Mask, BR, Time-Zone, Classless-Static-Route
         Default-Gateway, Domain-Name, Domain-Name-Server, Hostname
         Option 119, MTU
       END Option 255, length 0
       PAD Option 0, length 0, occurs 29

13:00:53.806786 IP (tos 0x0, ttl 16, id 26217, offset 0, flags [none], proto UDP (17), length 306)
    x.y.168.1.67 > x.y.169.21.68: [udp sum ok] BOOTP/DHCP, Reply, length 278, xid 0x11fa7b4a, Flags [none] (0x0000)
     Client-IP x.y.169.21
     Your-IP x.y.169.21
     Server-IP x.y.168.1
     Client-Ethernet-Address 00:e2:69:65:3a:25
     Vendor-rfc1048 Extensions
       Magic Cookie 0x63825363
       DHCP-Message Option 53, length 1: ACK
       Subnet-Mask Option 1, length 4: 255.255.255.128
       Default-Gateway Option 3, length 4: x.y.169.1
       Domain-Name-Server Option 6, length 8: x.y.170.170,x.y.171.171
       Lease-Time Option 51, length 4: 4200
       Server-ID Option 54, length 4: x.y.168.1
       END Option 255, length 0

[Patrick M. Hausen]

What does your outbound NAT rule on WAN look like? If the source address is "any" and not limited to "LAN net" or similar, that might well be the case.

[sjm42]

Actually yes, I figured it out. The firewall was doing source NAT including source port translation to its self-initiated traffic!
I added an outbound NAT rule for destination port 67 with "static port" flag set, and it solved the problem with unicast dhcp!

It was news to me that also self-initiated traffic gets source NATed.

Phew pffffft...

[Patrick M. Hausen]

It was news to me that also self-initiated traffic gets source NATed.

The firewall does what the rules specify. If the NAT rule is "source: any" then it's all traffic. That's why you should change the rule to "source: LAN net" or "source: <group of internal networks>". Then no extra rule with static port is necessary.