Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Jasonkruys on August 06, 2022, 11:55:53 AM
-
Hi all,
Is anyone implementing MTU of 1500 on Zen FTTP using OPNSense? Having done some reading, I thought it was as simple as setting Interfaces > WAN > MTU to 1508 (it then shows calculated PPP MTU as 1500). If I do that, internet access is 'Broken'. Pages load really slowly, if at all, speedtest.net gets stuck on finding best server etc.
Do I need to set MSS clamping manually in the WAN interface?
I use IPv6 (as per Zens instructions for DHCPv6) - is that the issue?
If anyone has a similar set-up and has it working, any help would be appreciated!
Thanks.
-
All I can say is on pfSense all you do is set the PPP connection to 1500 MTU and the internal logic handles the rest. It automatically adjusts the parent interface to 1508.
-
So I worked this out in the end. On OPNSense (not sure if it is a change or not), when using a PPPoE setup, it creates a WAN interface against pppoe0 (igb0) - username@zen.com.
Changing the MTU to 1508 in Interfaces > WAN > MTU to 1508 changes the WAN 'interface' to 1508, and the PPPoE point-to-point device to 1500, but does nothing to the physical igb0 port.
It was at this point I realised the igb0 port was not 'assigned' in interfaces - it is just hanging around at the bottom in green as a 'new interface' - assigning it to a Nonsense ID (I used Dummy), not configuring anything at all EXCEPT changing the MTU to 1508 then changes the physical port. Everything then springs into life.
Apparently as long as you don't want to make any changes to the physical port config/parameters, not being assigned is not an issue - OPNSense magically makes it work as per the wizard config. Of course, to then change the physical port parameters, it must be assigned/exist for tinkering with!
Resultant interfaces as attached
-
Its so long since I configured pfSense I can't remember exactly how it did it, I assume it DID assign the interface as it changes the MTU automatically from just setting it in the PPPoE settings.
-
When you first install pfsense (and I think opnsense) in the initial questions it will ask you for your LAN and WAN config, if you answer those correctly, it will do the inititial interface assignment then.
Of course if you dont do this, or the configuration changes post install, then yep have to assign the physical interface to the virtual interface pfsense/opnsense makes.
-
Ah yes, that sounds about right. I honestly should remember considering I had to setup Plusnet long after and that would also be the same as setting up L2TP.
-
When you first install pfsense (and I think opnsense) in the initial questions it will ask you for your LAN and WAN config, if you answer those correctly, it will do the inititial interface assignment then.
Of course if you dont do this, or the configuration changes post install, then yep have to assign the physical interface to the virtual interface pfsense/opnsense makes.
I think OPNSense has changed the way it configures. I went through the Wizard and answered correctly, and all was good. No changes. It seems to configure the interface and sets it all up for the PPPoE virtual connection, but leaves the physical interface hanging. Note that when I 'assigned' it I couldn't assign it to the virtual interface/WAN, I had to create a new completely separate interface just for the purpose of gaining access to the MTU setting for that physical port - everything else is blank. I would have done it via the CLI, to avoid the extra superfluous interface appearing in firewall and NAT menus etc. but it doesn't stick.
Someone had a similar observation on OPNSense here https://forum.opnsense.org/index.php?topic=19747.0 & https://forum.opnsense.org/index.php?topic=11733.0 & here https://forum.opnsense.org/index.php?topic=16159.0
As long as I didn't want to meddle with the MTU, requiring a non-standard MTU to be set on the port, all was well. I guess there aren't enough people both using PPPoE and fiddling with it for OPNSense to be worried about it.
-
Well I meant the interface assignment not the MTU configuration. The initial setup asks you which physical device to assign to WAN/LAN.
Maybe a feature request could be added if MTU tinkering is needed to be done separately on the physical interface?
-
That's what I meant - in the initial setup you tell it igb0 is your WAN interface, igb1 is LAN. If OPNSense is configuring igb0 as PPPoE it doesn't actually assign the physical interface. It creates a virtual WAN (PPPoE, igb0) interface and then the point-to-point PPPoE device. You're left with a separate igb0 interface unassigned (which you can see in my screenshot - both the way the WAN interface is configured, and the previously unassigned igb0 which I had to assign to 'Dummy'). I hadn't noticed previously as everything worked.
-
So before you assigned to dummy, the igb0 was available on the bottom box?
If so that sounds like a potential bug to me.
-
I just checked on pfSense, igc0 is not assigned but PPPoE is running over igc0 with the automagically adjusted MTU of 1508.
This is not shown in Status / Interfaces due to not being assigned, you have to check from SSH.
igc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1508
options=e527bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
ether 00:e2:69:xx:xx:xx
inet6 fe80::2e2:69ff:fe59:25ee%igc0 prefixlen 64 scopeid 0x1
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
pppoe0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: WAN_ZEN
inet6 fe80::1%pppoe0 prefixlen 64 scopeid 0x11
inet6 2a02:8011:d000... prefixlen 64 autoconf
inet 82.69.xx.xx --> 51.148.xx.xx netmask 0xffffffff
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
-
For me the interface is assigned (not in unassigned box) and always was since day one, so I find that odd.
What is in your network port for your WAN Alex? because from what i can see its impossible to add a virtual interface without assigning something as a host interface.
-
So before you assigned to dummy, the igb0 was available on the bottom box?
If so that sounds like a potential bug to me.
Yes, exactly that. Shown where igb2 is in the screenshot, but with a green icon.
-
Seems you can, or at least pfSense itself can.
-
Seems you can, or at least pfSense itself can.
Yep, that's exactly the same as I had with OPNSense - the difference being that pfsense is clever enough to re-configure the interface MTU in the background, but OPNSense isn't so you have to assign it, to gain access to the interface parameters to modify them.
-
Seems you can, or at least pfSense itself can.
Not sure whats going on there, you somehow have it assigned and unassigned at the same time. igc0 is assigned to your WAN but also available to assign to a new interface.
Try adding a new interface without using up a host interface, for me its impossible.
Looks like something is broken on both opnsense and pfsense allowing these to become detached.
-
Its complicated, as I did have a VLAN assigned on that interface with untagged traffic for ppp and tagged connected to the LAN, so I could access the OpenWRT UI of the router without the risk of broadcast traffic slipping out the PTM bridge.
-
I have the same issue actually, igb2 is allocated twice in the list which is why i didnt see it under available, how odd. Although in my case everything is behaving normally, but it seems odd nevertherless.
-
It kinda makes sense on some level, as PPP is effectively a virtual interface that is created/destroyed dynamically and (as I understand it) is pretty much blind to what interface its actually running on, all it cares is packet goes out, PPP server responds and connection established.
When you think about the fact PPP can do multi-link it makes even more sense, it would have connections over multiple real interfaces that presumably show up as a single PPP interface? So it wouldn't make sense to treat PPP as taking over the interface, its not working in the same part of the network stack.
Basically, as the PPP interface is independent of the NIC itself, so far as the network stack is concerned there is no protocol running on that NIC (eg TCP/IP), so its effectively unallocated. The only caveat is changing the MTU, presumably why they decided to just include this automatically based on what you set for the PPP interface.
Its always fascinated me how this works actually and why I used VLANs to talk to my bridge-modem when on the same port. As I figure if you use it with untagged traffic too, then surely anything destined to that port will leak over the WAN bridge? Broadcast traffic specifically would surely go right out the telcos network?