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
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.
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...
Quote from: sjm42 on April 05, 2024, 02:07:40 PM
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.