Using a LAN port on SG-3100 for WAN interface to Frontier ONT

cmccolgan

Re: SG-3100 fail to get WAN IP from Frontier fiber ONT

From others comments on this forum it's my understanding that if I want to connect my SG-3100 directly to a Frontier ONT (model fox222) the best way to do so would be to take a switch port and use that as the WAN port as Frontier is tagging traffic from their Network with a VLAN ID of 0. User @natbart created a very nice script where I could use the WAN port but user @stephenw10 who works for Netgate indicated that it would be better to use a switch port.

In looking at docs I see this. It seems that if I followed these steps and then configured the port to get it's IP via DHCP (and created some firewall rules) I'd be most of the way there. Is that the case? In this example it tags the port with VLAN ID of 4084 would that be correct or should it be tagged with 0? I'm getting my ONT installed in a few days and wanted to be prepared for the VLAN ID weirdness that Frontier seems to have.

I'd be very interested in anyone else's experience in making this work where the SG-3100 (or other netgate model) is just plugged directly into a Frontier ONT.

Thanks!

Charles

Jarhead

@cmccolgan Funny, I have 2 other family members with Frontier and all 3 use pfSense. 2 have Fox222's, one has the newer Fox4xx (I forget the actual model number). One 222 just worked fine. Plugged right into the WAN and got an IP. The other 2 ONT's would not. I don't understand why one did and never looked into it.
Anyway, try it, might work, might not
If it doesn't, you're not really understanding what the switch is for. You use a managed switch to strip vlan0, not sure if you can use other ports on your pfSense but should work. Do you really wanna waste router ports though?
You don't use the switch port as your WAN, you just need it to strip Vlan0 on the way to your WAN.
So what you do is pick 2 switch ports, untag then with an unused vlan. Now those 2 ports act as a separate switch.
Plug one port into the ONT, plug the other into the WAN of pfSense.
You will then get the public IP on that port.

cmccolgan

@jarhead thanks for the reply.

So I get that I could put an managed switch between the ONT and the SG-3100 and have it strip the VLAN 0 tagging. Also makes sense that I could use switch ports on the SG-3100 and have them untag the VLAN. Currently ports 1 and 2 on the switch on my 3100 are being used. Could I group ports 3 and 4 as such:

And then say plug the ONT into port 3 and then patch port 4 to the WAN port on the 3100. Would that strip the VLAN tagging and make things work assuming me initially pugging into the WAN port doesn't work?

Jarhead

@cmccolgan Again, I've never done that but I would guess it should work.
I still think you'd be wasting valuable router ports when a cheap managed switch will do the job.

cucu007

@jarhead
I have been dealing with this nightmare for a while.

Stephen seen to have some ideas on the issues, but I suspect this is not priority for Netgate at the moment.

I actually had to rollback my box to 2.5.2 and use some hacky script that someone created on the forum in order to get this working. I find this very had to believe that my $20 router from walmart is able to work just fine, same goes for OpenWRT, but my favorite PFsense is not able to get this working. Very frustrating to say the least, we are at the mercy of Netgate developers to sort this out.

cmccolgan

@cucu007 and @Jarhead
Thanks for your replies. Yeah @Jarhead agree that eating up two ports on my router doesn't make a lot of sense. Seems like there are several approaches here:

It's always the possibility that where I am in Frontier's network (Santa Monica, CA) which is a new deployment doesn't do the VLAN 0 tagging or my deployment is configured without it and I can just plug into the WAN port without doing anything!
Use script created by @natbart that allows WAN port to recognize VLAN 0 tagging and work with Frontier from the get go (issues with this is that if I have to restore my SG-3100 or upgrade it will have to port script along manually. Additional issue is seems like some of the latest versions of Netgate firmware don't work with this particular approach)
Convert a switch port on SG-3100 to act as new WAN port per @stephenw10 (will need to mess with this a bit as how to do this isn't totally clear to me)
Add a managed switch between the ONT and SG-3100 that supports Dot1q and will strip the VLAN 0 tagging coming from Frontier and fix the issue basically using that switch as a bridge.
Take two ports on switch on SG-3100 and put them into their own VLAN and use that as a bridge between ONT and WAN port while stripping the VLAN 0 tagging from Frontier

I'm going to try the above approaches in the order listed. My preference would be to either not have to do anything or if that doesn't work convert a single switch port to be a WAN port and then have my WAN port free for other uses. I'll update this thread later this week or next weekend what my experience was and the solution that I ended up doing. Thanks for the suggestions I have several things to try now.

stephenw10

Yeah, with Frontier is seems like the only issue is that they are sending DHCP replies priority tagged (vlan0) so if you strip those it will work fine.
In the 3100 that's easily achievable because of the built in switch. There's no need to setup two ports as a separate switch. Just separate one port as a new interface and use that as the WAN. The traffic traffic coming into the switch will be tagged with the internal VLAN and passed as expected.
So exactly like the guide you linked to here: https://docs.netgate.com/pfsense/en/latest/solutions/sg-3100/switch-overview.html
But at step 8 instead of assigning the VLAN as a new interface, assign WAN to use 'VLAN 4084 on mvneta1'.

Now you also have the WAN port (mvneta2) free to assign and use if you want.

Steve

cmccolgan

@stephenw10
Thanks for the response.

So this makes sense at step 8 I would just do the assignment you indicate:

Subsequent steps 9, 10, 11, 12 , 13 I assume wouldn't need to be done because those are already set for the WAN interface.

Would then need to do 14 to apply changes.

What about any subsequent steps specifically thinking of 15 on and 16 in enabling enabling Dot1q on the switch. Is that something that I need to do to make this work?

Thanks for the info. I've never done any VLAN stuff on the switch I use it extensively for Squid, SquidGuard, and Ntopng but don't do a lot of routing / VLAN stuff.

Jarhead

@stephenw10 said in Using a LAN port on SG-3100 for WAN interface to Frontier ONT:

Yeah, with Frontier is seems like the only issue is that they are sending DHCP replies priority tagged (vlan0) so if you strip those it will work fine.
In the 3100 that's easily achievable because of the built in switch. There's no need to setup two ports as a separate switch. Just separate one port as a new interface and use that as the WAN. The traffic traffic coming into the switch will be tagged with the internal VLAN and passed as expected.
So exactly like the guide you linked to here: https://docs.netgate.com/pfsense/en/latest/solutions/sg-3100/switch-overview.html
But at step 8 instead of assigning the VLAN as a new interface, assign WAN to use 'VLAN 4084 on mvneta1'.

Now you also have the WAN port (mvneta2) free to assign and use if you want.

Steve

Steve,
I'm curious, and may try this before you reply, as to why you can't just add the vlan to the wan port then assign that vlan as the wan?
What would be the difference?

Jarhead

@cmccolgan You're setting a new port as the WAN so you will have to do 9-14 for sure. Can't say anything about after that since I don't have a Netgate appliance.

Jarhead

@stephenw10 Just tried it, wouldn't work.
Added vlan 4094 to em0 (my WAN port), tried to assign the vlan as WAN and every time I clicked save it would revert back to em0.
Is this because I have rules setup on it maybe?

stephenw10

@jarhead said in Using a LAN port on SG-3100 for WAN interface to Frontier ONT:

I'm curious, and may try this before you reply, as to why you can't just add the vlan to the wan port then assign that vlan as the wan?

That won't work, as you found, because it doesn't go through the switch. It needs to go through the switch in order to strip the VLAN0 tag so the NIC/driver will accept it. In this example we are also retagging it 4084.

stephenw10

@cmccolgan At step 8 assign the WAN to the new VLAN like this:
Screenshot from 2022-05-29 13-11-37.png

That should be all that's required.

Steve

cmccolgan

@stephenw10
Thanks @stephenw10 . So decided to try this on my existing Spectrum Cable connection just to test out making the interface changes. I have no issue using the WAN port in a default config on the SG-3100 with Spectrum so figured if I made the WAN port as described above the LAN 4 port it should work fine.

Changes in the interface went fine but when I switched from being plugged into the WAN port to being plugged into LAN 4 I was unable to get an IP address via DHCP. See:

May 29 09:03:08 pfSense dhclient: PREINIT
May 29 09:03:08 pfSense dhclient[86217]: DHCPDISCOVER on mvneta1.4084 to 255.255.255.255 port 67 interval 1
May 29 09:03:09 pfSense dhclient[86217]: DHCPDISCOVER on mvneta1.4084 to 255.255.255.255 port 67 interval 1
May 29 09:03:10 pfSense dhclient[86217]: DHCPDISCOVER on mvneta1.4084 to 255.255.255.255 port 67 interval 2
May 29 09:03:12 pfSense dhclient[86217]: DHCPDISCOVER on mvneta1.4084 to 255.255.255.255 port 67 interval 2
May 29 09:03:14 pfSense dhclient[86217]: DHCPDISCOVER on mvneta1.4084 to 255.255.255.255 port 67 interval 4
May 29 09:03:18 pfSense dhclient[86217]: DHCPDISCOVER on mvneta1.4084 to 255.255.255.255 port 67 interval 9
May 29 09:03:27 pfSense dhclient[86217]: DHCPDISCOVER on mvneta1.4084 to 255.255.255.255 port 67 interval 8
May 29 09:03:35 pfSense dhclient[86217]: DHCPDISCOVER on mvneta1.4084 to 255.255.255.255 port 67 interval 19
May 29 09:03:54 pfSense dhclient[86217]: DHCPDISCOVER on mvneta1.4084 to 255.255.255.255 port 67 interval 11
May 29 09:04:05 pfSense dhclient[86217]: DHCPDISCOVER on mvneta1.4084 to 255.255.255.255 port 67 interval 4
May 29 09:04:09 pfSense dhclient[86217]: No DHCPOFFERS received.
May 29 09:04:09 pfSense dhclient[86217]: No working leases in persistent database - sleeping.
May 29 09:04:09 pfSense dhclient: FAIL

With the idea that this might be that Spectrum was expecting the MAC address of my old interface I also tried it where the mvneta1.4084 interface was spoofing the mvneta2 MAC address. Dhclient showed the same behavior. When I switched my WAN interface back to mvneta2 I was able to get an IP again:

May 29 09:20:15 pfSense dhclient: PREINIT
May 29 09:20:15 pfSense dhclient[50719]: DHCPREQUEST on mvneta2 to 255.255.255.255 port 67
May 29 09:20:17 pfSense dhclient[50719]: DHCPREQUEST on mvneta2 to 255.255.255.255 port 67
May 29 09:20:21 pfSense dhclient[50719]: DHCPREQUEST on mvneta2 to 255.255.255.255 port 67
May 29 09:20:26 pfSense dhclient[50719]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 1
May 29 09:20:27 pfSense dhclient[50719]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 2
May 29 09:20:29 pfSense dhclient[50719]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 2
May 29 09:20:31 pfSense dhclient[50719]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 3
May 29 09:20:34 pfSense dhclient[50719]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 7
May 29 09:20:41 pfSense dhclient[50719]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 9
May 29 09:20:50 pfSense dhclient[50719]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 14
May 29 09:21:04 pfSense dhclient[50719]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 10
May 29 09:21:14 pfSense dhclient[50719]: DHCPDISCOVER on mvneta2 to 255.255.255.255 port 67 interval 13
May 29 09:21:14 pfSense dhclient[50719]: DHCPOFFER from XXX.XXX.XXX.XXX
May 29 09:21:14 pfSense dhclient: ARPSEND
May 29 09:21:16 pfSense dhclient: ARPCHECK
May 29 09:21:16 pfSense dhclient[50719]: DHCPREQUEST on mvneta2 to 255.255.255.255 port 67
May 29 09:21:16 pfSense dhclient[50719]: DHCPACK from XXX.XXX.XXX.XXX
May 29 09:21:16 pfSense dhclient: BOUND
May 29 09:21:16 pfSense dhclient: Starting add_new_address()
May 29 09:21:16 pfSense dhclient: ifconfig mvneta2 inet XXX.XXX.XXX.XXX netmask 255.255.224.0 broadcast 255.255.255.255 
May 29 09:21:16 pfSense dhclient: New IP Address (mvneta2): XXX.XXX.XXX.XXX
May 29 09:21:16 pfSense dhclient: New Subnet Mask (mvneta2): 255.255.224.0
May 29 09:21:16 pfSense dhclient: New Broadcast Address (mvneta2): 255.255.255.255
May 29 09:21:16 pfSense dhclient: New Routers (mvneta2): XXX.XXX.XXX.XXX
May 29 09:21:16 pfSense dhclient: Adding new routes to interface: mvneta2
May 29 09:21:16 pfSense dhclient: /sbin/route add default XXX.XXX.XXX.XXX
May 29 09:21:16 pfSense dhclient: Creating resolv.conf
May 29 09:21:16 pfSense dhclient[50719]: bound to XXX.XXX.XXX.XXX -- renewal in 9152 seconds.

Just to note that after switching interfaces both times I power cycled the cable modem. If I don't do this then while I see DHCP activity from Spectrum in my default config, never saw any DHCP activity from Spectrum in the mvneta1.4084 config, the interface never properly binds (seems like a timing issue).

I didn't try manually assigning the IP I normally get assigned from Spectrum and then seeing if I could ping the Spectrum gateway when I had mvneta1.4084 as the WAN interface but when I was using mvneta1.4084 as WAN I wasn't seeing any DHCP offers from Spectrum which I always see even if they don't bind in my default config.

Any thoughts here? This is just trying out the config you suggested on a known good internet connection with the thought that if it won't work with this it most likely won't work with Frontier.

stephenw10

Urgh, sorry I'm not sure what happened yesterday. Clearly not enough coffee when I read that switch doc!
You still need to complete steps 15-26 there to setup the switch.

If you see no replies it sounds like you may not have set the PVID on the switch port?

Steve

cmccolgan

@stephenw10
Yep that did it. The native WAN port and ETH 4 now both work as uplink ports depending on if I have them assigned to the WAN interface. I'll update this thread after Thursday on my experience with Frontier and if I can use the native WAN interface or need to use the procedure that was defined here.

Thanks for the all the help. Appreciate it!

cmccolgan

So an update.

Got Frontier Fiber installed at home today. Several interesting findings.

I'm getting both phone and internet service via Frontier. Frontier provisioned my phone on to their Arris router. I asked the tech to have frontier provision the phone to the ONT but he said it would cause a cancellation of the service appointment but I could do that with a call later. As a note the Frontier tech on site (David) was awesome.
The ONT provided was not the FOX222 but the FRX523 which is a brand new ONT that Frontier is using for this new deployment in Santa Monica / Pacific Palisades.

As such config was ONT->Arris->SG-3100

Did speed test from Arris was getting 940 Mbit Symmetric. Didn't like having the Arris in front so changed config to be:

ONT->SG-3100(Lan Port 4)->Arris

In this config best I got was 729 Mbit Down / 802 Mbit Up. Good but not line speed. In this config I was able to maintain phone service however by having the phone line plugged into the Arris that was getting connectivity from the SG-3100.

As it turns out Frontier isn't doing the VLAN 0 tagging for DHCP in this area's deployment so I was able to change the config to be:

ONT->SG-3100(Native WAN Port)->Arris

With this config I was able to get 940 Mbit Symmetric. In reading various posts it seems that there are ineffeciencies in using a LAN port at these speeds and I was getting a perf hit by using LAN 4 as my WAN port. Fortunately for me I didn't need to use LAN 4 as discussed earlier in this post and was able to use the native WAN port.

One thing I did need to do to get linespeed on the install was disable ntopng. I like running ntopng but it is a CPU hog and with this running I was not able to get line speed. Guess I'm in the market now to get a 6100?

Anyways that's the update. Thanks everyone for their help and if anyone want pictures of the FRX523 I can post them here. Seems like such a new ONT I can find very little about it on the Internet.

stephenw10

@cmccolgan said in Using a LAN port on SG-3100 for WAN interface to Frontier ONT:

In reading various posts it seems that there are ineffeciencies in using a LAN port at these speeds and I was getting a perf hit by using LAN 4 as my WAN port.

What you were probably hitting there was the shared link between the LAN4 and one of the other LAN ports if that's where you were testing from. In that config both ports are sharing a single NIC. The NIC can send and receive at 1G simultaneously so if you have a udp stream you should see very close to line rate. However for TCP tests the reply traffic moving the other way decreases the available bandwidth. When the path uses two NICs that isn't an issue. So, if you are using a LAN port as the WAN, testing from a client on OPT will likely show the same results you see using the WAN port.

Steve