Freedom glasvezel - eigen PFsense server instructies

Ik heb online verschillende beschrijvingen van mensen gevonden hoe je je glasvezel verbinding aan de praat krijgt met pfSense. Maar voor Freedom hebben we dit nog niet. Ook vind ik sommige handleidingen erg onduidelijk, daarom hierbij een die voor iedereen volgbaar zou moeten zijn hoop ik :slight_smile:

Ik ben geen netwerk engineer en ik ga er vanuit de mensen die dit lezen dat ook niet altijd zijn. Waarschijnlijk heb ik wel zaken verkeerd gedaan en als er tips zijn dan zie ik graag jullie comments.

Setup:

  • A2SDI-4C-HLN4F Moederbord met 4 Intel NICs
  • Ik heb de UTP kabel direct uit de glasconverter in mijn pfSense server zitten

Daarnaast is het belangrijk om de settings van Freedom er bij te houden. Die staan hier:
Algemene instellingen | Freedom

1. Interface Assignments hernoemen
Zorg eerst dat je de benamingen van de NICs goed hebt zodat je deze makkelijk kunt herkennen.

  • ix0 : WAN
  • ix1 : LAN
  • ix2 : IPTV_LAN (deze gebruik ik niet in deze handleiding)

Om de interface namen aan te passen klik je op de interface naam en verander je de inhoud van Description
image

2. VLANs aanmaken

Om een VLAN aan te maken ga je onder interfaces naar VLANs


Klik hier op add om een VLAN aan te maken

Selecteer onder Parent Interface de NIC voor je WAN, in mijn geval is dat ix0
VLAN Tag moet 6 zijn
laat VLAN Priority leeg
en vul bij Description een makkelijk te herkennen naam in voor dit VLAN, ik heb hem “INTERNET_VLAN” genoemd

Klik dan op save

Herhaal de stap met VLAN 4 tag als je ook IPTV hebt van Freedom.

3. PPPs
Ga in Interfaces nu naar PPPs en klik op add om een PPPoE link aan te maken.
De instellingen die Freedom zelf beschrijft zijn als volgt:

Mode: PPPoE
VLAN: 6 (802.1Q)
PPP authenticatie: PAP
Gebruikersnaam: fake@freedom.nl
Wachtwoord: 1234

Vul de configuratie velden in zoals hierboven in de afbeelding
Link Type : PPPoE
Link Interface : selecteer de VLAN die je hiervoor hebt aangemaakt voor de internet connectie
Description : vul hier een makkelijk te herkennen naam in. ik heb hem “Freedom FTTH” genoemd
Username : fake@freedom.nl
Password : 1234
Laat de rest van de instellingen ongemoeid

4. Interface Assignments toekennen
Onder Interface Assignments selecteer je nu de PPPoE connectie bij je WAN NIC die je net hebt aangemaakt.

5. Check verbinding

Als het goed is zie je nu op de dashboard pagina van pfSense dat je WAN verbinding een IP adres heeft gekregen en dat deze up is.

Ik heb dit ongeveer een jaar draaien, er zal vast nog iets anders moeten worden ingesteld wat ik hier niet in heb staan dat ik vergeten ben,

Toevoegingen zijn welkom :slight_smile:

Ik zal binnenkort ook een handleiding voor IPTV schrijven, dit had nog wel iets meer voeten in de aarde.

2 likes

Ik neem aan dat je met deze standaardinstellingen een MTU van 1492 op je PPPoE-interface hebt. Het zou nog mooi zijn als je dat middels RFC 4638 naar 1500 kunt krijgen. (Dus een MTU van 1508 op de netwerkadapter van je WAN-poort instellen en een MTU van 1500 op je PPPoE client interface.)

1 like

Om eerlijk te zijn snap ik hier niet erg veel van.
Zonder iets te veranderen in de initiële post van dit topic is maximale size van 1464 byte pingen

ping -f -l 1464 8.8.8.8
Pinging 8.8.8.8 with 1464 bytes of data:
Reply from 8.8.8.8: bytes=68 (sent 1464) time=1ms TTL=118
Reply from 8.8.8.8: bytes=68 (sent 1464) time=2ms TTL=118

1 byte groter haakt ie af

ping -f -l 1465 8.8.8.8
Pinging 8.8.8.8 with 1465 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Nu zet ik MTU en MSS correct voor PPPoE

En op jou aanraden de MTU van de NIC op 1508

maximale size dat ik nu kan pingen is 1472 byte geworden.

De NIC geeft wel aan dat de MTU nu 1500 is

PPPoE ook

Geen idee of dit nu klopt of niet

2 likes

Uitgaand pingen over IPv4 met 1472 bytes klopt. Je hebt een overhead van 20 bytes voor de IP-header en 8 bytes voor de ICMP-header. Dus als je een payload van 1472 bytes hebt plus een header van 28 bytes, kom je uit op een MTU van 1500 bytes.

Wanneer je geen RFC 4638 gebruikt, zou je niet verder komen dan 1464 bytes.

Bij IPv6 is de IP-header 40 bytes, dus kom je op een totaal van 48 bytes aan overhead. Zodoende moet je over IPv6 dus pingen met een payload van 1452 bytes, en zou je anders blijven steken op 1444 bytes.

Oftewel:

ping4 -M do -s 1472 freedom.nl
ping6 -M do -s 1452 freedom.nl

Ga ik daar overheen, dan krijg ik dit:

local error: message too long, mtu: 1500

Heb je trouwens IPv6 ook werkend? Daarvoor zou je een DHCPv6-PD-request moeten doen op je PPPoE-interface, en daarvan een subnet moeten toewijzen aan je LAN-interface.

1 like

Ik heb IPv6 ook maar ingesteld.
Als ik in Windows 10 de maximale packet size selecteer gaat dat gewoon goed

ping -6 -l 65500 freedom.nl

Pinging freedom.nl [2a10:3780:2:53:185:232:98:8] with 65500 bytes of data:
Reply from 2a10:3780:2:53:185:232:98:8: time=4ms
Reply from 2a10:3780:2:53:185:232:98:8: time=4ms
Reply from 2a10:3780:2:53:185:232:98:8: time=4ms
Reply from 2a10:3780:2:53:185:232:98:8: time=4ms

Ping statistics for 2a10:3780:2:53:185:232:98:8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 4ms, Maximum = 4ms, Average = 4ms

Merk wel dat de pingtijden achteruit gaan. zonder een size aan te geven gaat het terug naar 1ms. Dus het werkt wel degelijk blijkbaar.

ping -6 freedom.nl

Pinging freedom.nl [2a10:3780:2:53:185:232:98:8] with 32 bytes of data:
Reply from 2a10:3780:2:53:185:232:98:8: time=1ms
Reply from 2a10:3780:2:53:185:232:98:8: time=2ms
Reply from 2a10:3780:2:53:185:232:98:8: time=1ms
Reply from 2a10:3780:2:53:185:232:98:8: time=1ms

Ping statistics for 2a10:3780:2:53:185:232:98:8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 2ms, Average = 1ms

IPv6 stellen in pfSense is gelukkig niet zo moelijk. Onderstaande instellingen waren voldoende.

Ik heb daarnaast een firewall rule gemaakt om alle IPv6 adressen toe te staan om te connecten met internet te connecten.
IPv6 is helemaal nieuw voor mij, maar wat ik heb gedaan is de laatste 20 digits van een toegekend IPv6 adres 0 van te maken en de 48 range te selecteren. Ik denk dat het klopt.

Bij grotere hoeveelheden data gaat je latency uiteraard omhoog, want er moeten meer pakketten heen en weer gezonden worden. Verder vind ik 1ms wel behoorlijk laag hoor. Ik kom niet verder dan 4.4ms naar freedom.nl en terug.

Maar goed, je wilt gewoon een MTU van 1500 op je PPPoE link (en de DHCPv6 link), zodat er in ieder geval geen fragmentatie ontstaat wanneer er 1500 byte pakketten worden verstuurd en je router maar 1492 accepteert.

En wat IPv6 betreft, dat ziet er ook goed uit. Al zou je het ook gewoon moeten kunnen schrijven als 2a10:3781:xxxx::/48. En je hoeft niet per se de hele /48 naar je LAN te routeren. OpenWrt doet standaard een /60 bijvoorbeeld, zodat er ook nog ruimte over blijft voor interne prefix delegation.

ping voor IPv4 kan ook 64K pakketten aan. Maar niet als je fragmentatie verbied.
Transmissie van 64K data duurt behoorlijk wat langer dan een pakketje van 64 bytes. Dus dat de pingtijden van 64K wat langer duren soit.
dat zijn dan ook gelijk ( 64K/1472 ) paketten = 43 + een fractie paketten. Omdat et antwoord pas komt als het hele ping pakket binnen is is er meer latency. (en het vereist ook 44 * een vergroting van de OS buffer ).
Ik gebruik zelf /64 per intern VLAN. Ik kan dus nog wat VLAN’s vooruit.

Hmm, MTU staat toch niet helemaal goed.

werk laptop kan geen VPN connectie meer maken.
packet capture geeft de volgende foutmelding:
child_sa ikev2_auth[I]: [|v2e] (len mismatch: isakmp 1764/ip 1468)

Beetje Googlen brengt me hier
[strongSwan] Timeout on the first phase using RSA
Looks like the reason of this is that udp packet exceeding MTU length

Tips?

Ik heb alle MTU instellingen verwijderd en VPN gaat nu wel weer goed.

Zat te denken of nu wel echt een MTU probleem heb.
Dus even direct vanaf de server een ping uitgevoerd om te zien wat hij doet
image

Een paar keer uitvoeren geeft soms geen packet loss, soms wel. ligt er maar net aan hoeveel packets hij transmit.

Dus nee gaat dus niet goed lijkt het. Gekke is dat VPN wel weer werkt.

Op Linux kan je testen met ping als je (ping van iputils , gebruikelijk op linux aanwezig).
ping -M do -s 1472 freedom.nl (faalt nooit als interface MTU >=1508 is)
ping -M do -s 1464 freedom.nl (faalt nooit, tenzij interface MTU < 1500)
ping -M do -s 1473 freedom.nl (faalt als interface MTU ix0 = 1508)
ping -M do -s 1465 freedom.nl (faalt als interface MTU ix0 = 1500)
-M do zet het don’t fragment bit.

voor pfsense (FreeBSD) zijn de opties: -f -l {lengte} ipv. -M do -s {lengte}

Voor windows heb ik even geen idee, ik heb geen windows machine.

Zonder het DF bit te zetten kan ping tot 64K pakketten aan.

2 likes

Hey all,

Even een hele andere vraag dan de MTU (al is die ook interessant):
Hoe hebben jullie de PFSense box aan het glas aangesloten? Ik heb nu besloten om een Intel kaart aan te schaffen met een singlemode SFP volgens de specs van Freedom. Ik heb 'm nu ingebouwd. De netwerkkaart wordt in ieder geval herkend door PFsense. So far so good. Ik zie op de CLI de SFP nog niet, maar dat kan ook liggen aan dat daar nog geen glaskabel in zit.

Hebben andere mensen het ook op deze manier gedaan of hebben jullie allemaal een mediaconverter ertussen?

Ik ben benieuwd naar de antwoorden.

PS: Maandag komt een monteur de NT ombouwen. Ik weet het antwoord dus uiterlijk maandagavond.

Grappig genoeg kan ik alvast melden dat de SFP die met de Fritzbox wordt meegeleverd en volgens AVM / Fritz ‘speciale eigenschappen’ zou bezitten die alleen in de Fritzbox zouden werken, lijkt die SFP in mijn Intel kaartje in de PFSense box gewoon herkend te worden als werkende SFP:

/root: ifconfig -v ix0
ix0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1516
options=e53fbb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
ether 80:61:*
media: Ethernet autoselect
status: no carrier
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
> plugged: SFP/SFP+/SFP28 1000BASE-LX (LC)
> vendor: ACAL BFi PN: ABSFBL3412-20DAC SN: AB21032507305 DATE: 2021-03-25

Mijn eigengekochte module heeft deze entry:

plugged: SFP/SFP+/SFP28 1000BASE-LX (LC)|
vendor: MTXNEO PN: TSBL1G20D35 SN: JS20210615042 DATE: 2017-08-09|
module temperature: 26.47 C Voltage: 3.19 Volts|
RX: 0.00 mW (-40.00 dBm) TX: 0.40 mW (-3.94 dBm)|

Ik gok dat het wel gaat werken. We gaan het morgen beleven.

1 like

Helaas gaan de dingen niet zoals ze zijn afgesproken. Een les voor iedereen die overstapt. Hou rekening met dit:

  1. Om half 10 vanmorgen ging het licht van de glasvezel lijn. Geen signaal meer. Het is nu 13.30 en er is nog steeds geen licht op de draad. Er is een call bij Freedom aangemaakt. Tot nu toe heeft dat geen resultaat gehad. Freedom wijst naar Reggefiber.
  2. De monteur die volgens de afspraak om 13:00 zou komen, belde om 12 uur dat hij vandaag om van 17:00 tot 19:00 komt. Ik: “Moment, maar de afspraak was toch 13:00?” Monteur: “Ja maar ik kan niet, dus ik heb terug gegeven dat ik pas om 17:00 kan. Dat is dan vast niet doorgegeven.” Nee inderdaad, Dat is het niet. Ik kan het waarheidsgehalte niet beoordelen maar feit is dat hij er nu niet is en hopelijk vanavond wel komt. 4 uur later.

Kort samengevat: alles ligt eruit,

Hopelijk hebben we 1. snel weer licht op de lijn en 2 komt die monteur alsnog om 17:00. Overigens, komt de monteur wel maar hebben we nog steeds geen licht, ook dan schieten we nog niks op.

Intussen alles gefixt.

Conclusie voor PFSense: de SFP module werkt als een speer. Ik kan 'm van harte aanraden.

Wat was er misgegaan? Poort in de wijkcentrale verkeerd gezet?

Exact dat. Duurde wel 1 1/2 dag voordat ze daar achter waren. Nogal irritant omdat ik 100% thuis werk.

Ik had afgelopen maart hetzelfde. Uiteindelijk zat er zelfs een weekend tussen. Gelukkig was m’n huis toen nog in aanbouw en woonde ik er nog niet.

Het is dan ook inderdaad de “schuld” van KPN NetwerkNL en Freedom kan er ook echt niets aan doen, maar die onderlinge afhandeling en spoed erbij zou toch nog wel wat beter kunnen wat mij betreft.

Nah, ik wil geen vingerwijzen. Ik denk dat alle partijen wel boter op hun hoofd hadden.

  1. De monteur die 4 uur later kwam dan afgesproken was (en niet gecommuniceerd tot de dag zelf)
  2. Dat er verkeerd aansluitmateriaal was geleverd in de doos (fiber conversion van de KPN “NT” paste niet, was voor een oudere generatie)
  3. De patch die er WEL correct door KPN (te vroeg) af was gehaald maar door Cambrium NIET was overgenomen / correct overgezet.
  4. De informatie stroom die via de helpdesk van Freedom zou moeten lopen maar eigenlijk niet veel meer deed dan mij vertellen dat ze het heel vervelend vonden dat het zo liep.

Dus zowel de partij die de monteur aanstuurt als KPN als Cambrium als Freedom hadden hier beter werk moeten (willen) leveren. Aangezien Freedom degene is met het grootste belang, zou ik verwachten dat zij voor hun klant op de bres zouden springen. Dat was helaas niet het geval. Dat vond ik dan weer ‘heel vervelend’.

On Topic: ik heb op de netwerkkaart met de SFP erin voor het glas, een MTU van 1508 gezet. In de PPPoE verbinding heb ik de MTU op 1500 gezet met de MSS Clamping op 1448. Tot nu toe werkt alles als een speer. VPN werkt.

De eerste speedtest zat op zo’n 960Mbit, give or take a few. Ik ga er daarbij vanuit dat veel speedtest stations op internet geen full gigabit vrij hebben voor een testje EN dat er onderweg altijd een paar bitjes van de wagen vallen. Overall quite good, zou ik zeggen