I have a simple setup with a dual NIC Intel card on amd64. I know the connection to my ISP works fine because the router I'm replacing can quickly get an external IP. OPNSense struggles. tcpdump on my WAN port (igb0) shows:
01:09:47.918351 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from a0:ce:c8:01:05:8b (oui Unknown), length 300
01:09:47.935354 IP 32.217.174.1.bootps > 32.219.252.142.bootpc: BOOTP/DHCP, Reply, length 300
01:09:47.953487 IP 32.217.174.1.bootps > 32.219.252.142.bootpc: BOOTP/DHCP, Reply, length 300
Looks to me like the replies from their DHCP server are coming back fine. However OPNSense logs show:
2021-04-22T01:11:31 dhclient[18640] No DHCPOFFERS received.
2021-04-22T01:11:19 dhclient[18640] DHCPDISCOVER on igb0 to 255.255.255.255 port 67 interval 12
I didn't do anything to the firewall yet, so this is pretty much the default simple install. How can I fix this?
Secondly, why do I sometimes get the internal DHCP server (172.20.20.X) to assign the WAN interface an address in that range? How come the WAN dhclient is even able to listen to that address?
Thanks!
I should say that I can either fake a cached lease or just use the previously assigned IP address as a static assignment and that works no problem.
What is the exact setup, any bridged modems or fiber converters in WAN? Which ISP? CG-NAT?
Try spoofing the mac that the ISP router uses.
---Edit---
Also check that the ISP is not using some other form of validation.
MAC address was spoofed from the old router. This is Frontier fiber in CT, USA. There are no other pieces of equipment, just the ONT box that translates optical signal to Ethernet and the OPNSense box plugged right into that.
Is there a user forum for that ISP where someone may have posted a similar issue?
Oh and there is no CG-NAT. It's just a public IP.
There is abs I am asking on there as well, but the issue is clearly happening when I switched to OPNSense. I can plug my old router back in and it gets an address right away.
https://www.reddit.com/r/frontierfios/comments/5yvcy8/question_regarding_dhcp_lease_on_ont_via_ethernet/
Yes already saw that one and talked to their tech support who told me there were no issues. They see everything as fine on their end :(
There's nothing peculiar or non standard about the dhcp client, it's a bog standard client. Only time I've ever heard of issues is when the ISP has some weird authentication employed; usually mac spoofing is sufficient.
There is clearly something funny going on here. I was able to use tcpdump to capture a DHCPOFFER:
https://hpd.gasmi.net/?data=45C00148D3670000401170D720DBF80120DBFAEE004300440134D671020106004357CA8B001700000000000020DBFAEE0000000020D9AE0180615F082D7A000000000000000000006468637030352E667477792E696E2E66726F6E746965726E65742E6E6574000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000638253633501023604B810069D330400000E100104FFFFF800030420DBF8010F0F66747264686370757365722E6E657406084A284A284A284A29FF0000000000&force=ipv4
I am running dhclient manually to see its output in the terminal and it claims it never got any offers.
OK so digging into it further, what I see as being weird here is that the DHCP server is at 184.16.6.157 while the address it's offering is 32.219.250.238 and the gateway is 32.217.174.1. I believe this is all in a /21. Could the issue be that dhclient is ignoring the DHCPOFFER because it's coming from a different subnet?
Not really, I guess. I have one ISP that has his DHCP on a machine with a private IP. Doesn't matter, even as private IPs are blocked on WAN...
The IP resolves to
dhcp05.ftwy.in.frontiernet.net
which makes perfectly sense, I guess.
Can I make a suggestion. Turn off the ISP gateway and leave it off for an hour. The lease time is 60 minutes, so let any existing lease expire before re-starting. Sky UK used to have a weirdo where that had to be done.
I tried that already. I can actually verify that their DHCP servers don't care if there is an active lease: I can just keep requesting new IP addresses using different MAC addresses and I see new offers with new addresses. The issue is that dhclient is either not getting or ignoring DHCPOFFERs.
From doing a bunch of web searches it seems that the issue might be VLAN tagging related. In tcpdump I can see that the incoming traffic comes in as VLAN 0. Some online posts suggest that stripping this tag may help: https://www.reddit.com/r/PFSENSE/comments/9l7my1/dhcp_client_not_working_on_wan_att_fiber_dhclient/e76dj12/?utm_source=reddit&utm_medium=web2x&context=3
Looks like pfsense has a similar issue: https://redmine.pfsense.org/issues/8526 with a still open pull request https://github.com/pfsense/FreeBSD-src/pull/9. I think this matches exactly what I'm experiencing with OPNSense. How can I report this bug upstream?
We are already doing write VLAN skip so I guess it would be fair to say we could implement read VLAN (0) skip although that is pretty mean from the ISP to use that reserved non-VLAN but priority trick and there is no base network support for this so whenever the ISP decides to bump priority of a packet outside of DHCP/dhclient with this it's not going to end well. ;)
Discussion at https://github.com/opnsense/src/issues/114
Cheers,
Franco
Thanks again Franco! With some more testing I see that they use any which VLAN or sometimes no VLAN at all. No matter what I do I still can't get it to work, whether directly, through a dumb switch, etc. I am going to keep complaining to the ISP about this, but in the meantime I gotta get work done and have the rest of the house be able to get online so back to OpenWRT I go, at least for now.