SG-3100 fail to get WAN IP from Frontier fiber ONT
-
Is there anything logged in the 3100 dhcp log?
Are the replies coming into the correct MAC address?
Was the pcap filtered at all?
I note the DHCP offer to the 1100 appears to come from the relay agent IP but the offer to the 3100 from the DHCP server directly. Though I'm not sure what difference that could make.
Steve
-
@stephenw10 said in SG-3100 fail to get WAN IP from Frontier fiber ONT:
Is there anything logged in the 3100 dhcp log?
Here is what I got from the log. Starts with when I disconnected the cable to the WAN port (from cable modem). You can see the 4 requests and then several discovers. Note after that it logs 'No DHCPOFFERS received'
Dec 20 16:16:34 STSpfSense dhclient[30428]: connection closed
Dec 20 16:16:34 STSpfSense dhclient[30428]: exiting.
Dec 20 16:17:09 STSpfSense dhclient[7665]: Cannot open or create pidfile: No such file or directory
Dec 20 16:17:09 STSpfSense dhclient[8333]: PREINIT
Dec 20 16:17:09 STSpfSense dhclient[7665]: DHCPREQUEST on mvneta2 to 255.255.255.255 port 67
Dec 20 16:17:11 STSpfSense dhclient[7665]: DHCPREQUEST on mvneta2 to 255.255.255.255 port 67
Dec 20 16:17:15 STSpfSense dhclient[7665]: DHCPREQUEST on mvneta2 to 255.255.255.255 port 67
Dec 20 16:17:19 STSpfSense dhclient[7665]: DHCPREQUEST on mvneta2 to 255.255.255.255 port 67
Dec 20 16:17:24 STSpfSense dhclient[7665]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 2
Dec 20 16:17:26 STSpfSense dhclient[7665]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 2
Dec 20 16:17:28 STSpfSense dhclient[7665]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 5
Dec 20 16:17:33 STSpfSense dhclient[7665]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 7
Dec 20 16:17:40 STSpfSense dhclient[7665]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 21
Dec 20 16:18:01 STSpfSense dhclient[7665]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 17
Dec 20 16:18:18 STSpfSense dhclient[7665]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 7
Dec 20 16:18:25 STSpfSense dhclient[7665]: No DHCPOFFERS received.
Dec 20 16:18:25 STSpfSense dhclient[7665]: Trying recorded lease 67.xx.xx.xx
Dec 20 16:18:25 STSpfSense dhclient[16519]: TIMEOUT
Dec 20 16:18:25 STSpfSense dhclient[16721]: Starting add_new_address()
Dec 20 16:18:25 STSpfSense dhclient[16770]: ifconfig mvneta2 inet 67.xx.xx.xx netmask 255.255.252.0 broadcast 67.xx.xx.xx
Dec 20 16:18:25 STSpfSense dhclient[16867]: New IP Address (mvneta2): 67.xx.xx.xx
Dec 20 16:18:25 STSpfSense dhclient[17204]: New Subnet Mask (mvneta2): 255.255.252.0
Dec 20 16:18:25 STSpfSense dhclient[17367]: New Broadcast Address (mvneta2): 67.xx.xx.xx
Dec 20 16:18:25 STSpfSense dhclient[17600]: New Routers (mvneta2): 67.xx.xx.xx
Dec 20 16:18:26 STSpfSense dhclient[21176]: New Routers (mvneta2): 67.xx.xx.xx
Dec 20 16:18:27 STSpfSense dhclient[22685]: Deleting old routes
Dec 20 16:18:27 STSpfSense dhclient[7665]: No working leases in persistent database - sleeping.
Dec 20 16:18:27 STSpfSense dhclient[23293]: FAIL@stephenw10 said in SG-3100 fail to get WAN IP from Frontier fiber ONT:
Are the replies coming into the correct MAC address?
Yes correct MAC assigned to mvneta2
@stephenw10 said in SG-3100 fail to get WAN IP from Frontier fiber ONT:
Was the pcap filtered at all?
No. I selected 'Enable promiscuous mode', left everything else at default, and set count to 0
-
Ok, to be clear, you have verified that WAN port connects as expected to some other DHCP server? On the 1100 LAN for example?
Did you try reassigning the 3100 WAN to mvneta0 (opt)?
Steve
-
This :
First few DHCP requests the 3100 asks for the last IP it had, which was a cable company IP, the ONT returns NAK each time, message is address not available (makes sense as it is not in Frontier's pool).
The dhclient actually receives the multiple NACKs ?
edit : me thinking : is it normal that client continues asking for a know - used before - IP ?
I mean, I've this impression that there is a one way communication ....3100 finally begins to send DHCP discover messages and for each one, the ONT replies with an offer with ip address within their pool. The 3100 does not accept the offer but just continues to send discover packets, each one replied to by the ONT with a valid offer.
Again : (does it) look like he dhclient process never sees the DHCP answers.
But they are there, the capture is clear about it. The captures are taken from pfSense, right ?
-
@stephenw10 said in SG-3100 fail to get WAN IP from Frontier fiber ONT:
Ok, to be clear, you have verified that WAN port connects as expected to some other DHCP server? On the 1100 LAN for example?
Did you try reassigning the 3100 WAN to mvneta0 (opt)?
SteveThe WAN port has been plugged into for more than a year, and remains plugged into a cable modem. This is our office and we have been running it flawlessly everyday now. Frontier fiber was installed on friday. We attempt to make frontier work but remain with cable until this is figured out. Both services (cable modem, fiber ONT) are next to each other in our server room.
I have not tried assigning mvneta0, I can try that. You say re-assign. I never assigned 2 over 0, I ran the wizard and started with that base setup more than a year ago. I believe the wizard assigned 2 to WAN.
-
@gertjan said in SG-3100 fail to get WAN IP from Frontier fiber ONT:
The dhclient actually receives the multiple NACKs ?
edit : me thinking : is it normal that client continues asking for a know - used before - IP ?
I mean, I've this impression that there is a one way communication ....Yes, the 3100 makes 4 attempts at request for known IP and gets 4 NAKs. The 1100 we are using as the 'control' makes 1 request for known IP, gets 1 NAK and then makes DHCP request.
@gertjan said in SG-3100 fail to get WAN IP from Frontier fiber ONT:
The captures are taken from pfSense, right ?
Yes. under Diagnostics > Packet Capture with the settings 'Enable promiscuous mode', left everything else at default, and set count to 0
-
Ah, OK. Then if the OPT port is not used I would just set that as DHCP and connect the finer to it instead. See if it pulls a lease there.
Are you running Snort or Suricata in blocking mode? Has it somehow blocked the DHCP server IP? (which should not be possible)
Steve
-
Under Interfaces, WAN the section "DHCP Client Configuration" have you compared this section between the 3100 and 1100? Mine is blank, on mine, but if you check the "Advanced Configuration" box, you get some more items, a new section "Lease Requirements and Requests". Again on mine, it's blank, but perhaps there is a difference on your 3100 and 1100.
-
@jaredo said in SG-3100 fail to get WAN IP from Frontier fiber ONT:
Yes, the 3100 makes 4 attempts at request for known IP and gets 4 NAKs. The 1100 we are using as the 'control' makes 1 request for known IP, gets 1 NAK and then makes DHCP request.
Exactly.
The 1100 tries to validate the old know IP, get a - just one - 'NAK' and behaves accordingly : it goes for a 'discover'.
The 3100 goes for the old IP ..... a NAK comes in, but the 3100 repeats itself, as if it is ignorant of the NAK. After some time, the 3100 takes note 'of the silence' (!) and switches to 'discover' which is the normal procedure.Just to be sure : shut down the firewall completely for a moment.
I guess it's "pfctl -d".
The info - the NAKs etc from the opposite side are coming in, as the capture shows. -
@stephenw10 said in SG-3100 fail to get WAN IP from Frontier fiber ONT:
Ah, OK. Then if the OPT port is not used I would just set that as DHCP and connect the finer to it instead. See if it pulls a lease there
On your suggestion I enabled OPT1. It also fails to get IP from ONT but will get one from arris router. I did not dive deeper with packet capture and such.
@stephenw10 said in SG-3100 fail to get WAN IP from Frontier fiber ONT:
Are you running Snort or Suricata in blocking mode? Has it somehow blocked the DHCP server IP? (which should not be possible)
I run Suricata but not in blocking mode. I turned it off anyways as a test (and it would have not been enabled during the test where I factory defaulted the 3100. Anyways, no luck, still will not get an IP from ONT.
-
Hmm, might need to check the pcap directly then. Something appears to be dropping those packets before the dhclient process ever sees them. Are they arriving tagged somehow and the 1100 switch is doing something with that?
-
@stephenw10 said in SG-3100 fail to get WAN IP from Frontier fiber ONT:
Hmm, might need to check the pcap directly then. Something appears to be dropping those packets before the dhclient process ever sees them. Are they arriving tagged somehow and the 1100 switch is doing something with that?
On your comment I went back into the pcap. Every packet from the ONT has this 208.1Q VLAN tag. Above my pay grade here but from wikipedia seems like it is only inserted if using tagging. "802.1Q VLAN frames are distinguished from ordinary Ethernet frames by the insertion of a 4-byte VLAN tag into the Ethernet header". This 0x8100 would not be in a non-vlag tagged packet.
From my rudimentary understanding, the ID is 0. How do you have a vlan tag of 0?
Also reading forums there is mention of Verizon or Frontier fiber using vlan tags. I think a friend found a reference to verizon using 100 and frontier using 0. Not sure about that.
-
Yeah, I didn't realise you also have a ticket open with us but now I do I've reviewed the pcaps there. The interesting thing is that the pcap from the 1100 does not show tagged traffic. That's probably because in the 1100 the switch always runs in dot1q mode so it tags the traffic into the interface itself. When you capture on WAN there you are actually only seeing traffic in mvneta0.4090 which the interface allows.
It looks like the raw NIC/driver is dropping the VLAN 0 tagged packets.As suggested on the ticket there though the simplest workaround here just to configure one of the 3100 LAN ports as the WAN which replicates what the 1100 WAN does.
Steve
-
Steve I didn’t realize you are an actual netgate employee. I really appreciate you helping here and on the actual support site since I don’t have paid support. It means a lot.
I was out all day at a client site. I will try this fix tomorrow.
-
No worries. It's an interesting issue, pfSense/FreeBSD does this intentionally:
https://redmine.pfsense.org/issues/12070The switch in the 3100 should workaround that though.
Steve
-
Solution for me can be found in this article.
https://forum.netgate.com/topic/160592/how-to-get-pfsense-wan-to-accept-vlan-0/85
@stephenw10 @Gertjan and @mer thank you for help finding a solution to my problem. Frontier fiber is sending packets with VLAN ID of 0 and the article above gives a solution.
A second solution offered to me which I did not try is the following below.
As a workaround you can use one of Eth ports on built-in switch SG-3100 has, create VLAN 4094 and use it as untagged on Eth4 for example and then use Eth4 as a WAN port.
I think Eth4 in this case will get DHCP offer correctly.
Check this guide: https://docs.netgate.com/pfsense/en/latest/solutions/sg-3100/switch-overview.html -
Yes, both those should work. The netgraph script also tags outgoing traffic for ISPs that require it but Frontier doesn't appear to.
I would personally use the switch port instead if you can because that is all contained in the config. If you ever have to reinstall and restore the config that will be far easier.
Steve
