[Pfsense] ExtraIP werkt niet naar behoren

[Operations]

Ik heb mijn Ziggo Zakelijk(300/40) al tijden draaien op Pfsense. Die draait virtueel via Hyper-v (Server 2016).
Dit werkt allemaal prima.

Nu probeer ik al een tijdje om een ExtraIP tunnel werkend te krijgen. Ja ik ken de Howto's van @Vorkie, sterker nog hij heeft mij geholpen met de setup. Dus Pfsense is opzich goed ingesteld.

Probleem is:

C:\Users\gebruiker>tracert -d 9.9.9.9

Tracing route to 9.9.9.9 over a maximum of 30 hops

1 1 ms <1 ms <1 ms 192.168.100.155
2 17 ms 16 ms 19 ms 185.*.*.129
3 19 ms 22 ms 18 ms 185.*.*.105
4 44 ms 25 ms 25 ms 193.*.*.123
5 20 ms 19 ms * 9.9.9.9
6 18 ms 18 ms * 9.9.9.9
7 18 ms 17 ms * 9.9.9.9

Hij doet hetzelfde richting 1.1.1.1 en 8.8.8.8.
Een ping richting diezelfde adressen geeft:
reply..reply..timeout..reply..reply..timeout etc.

Iemand enig idee waardoor dit komt? ExtraIP zelf geeft aan dat de configuratie aan hun kant in orde. Wij dachten eerst namelijk dat daar het probleem zat.

Verschillende MTU waardes maakt geen verschil.

Ik hoopte dat wellicht iemand hier dit toevallig herkent.

[noskill]

Hey, leuk probleem (als geintereseerde in ieder geval haha). Ik zie zelf eigenlijk niet aan die traceroute wat er fout zou zijn gegaan? Kan je iets beter uitleggen wat je probleem eigenlijk is? Met voorbeeld IP-addressen zodat we een idee hebben welke hops binnen je netwerk liggen en welke binnen dat van ExtraIP etc.

[Verwijderd]

Idd leuk probleem zal eens kijken of ik het hier kan reproduceren, heb ongeveer dezelfde setup ziggo zakelijk maar dan met ESXi.

[DexterDee]

Je hebt dus problemen met uitgaande verbindingen via het ExtraIP?

Hoe heb je pfSense geconfigureerd zodat 'ie het verkeer via de GRE tunnel naar buiten stuurt? Je zult namelijk wat NAT rules moeten aanmaken om het verkeer een juiste kant op te sturen.

Ik weet niet of je de volgende link al kent, maar daar staat uitgelegd hoe dit werkt:
https://www.kragt-ict.nl/...en-extraip-com-dnat-snat/

[Question Mark]

Operations schreef op maandag 6 april 2020 @ 16:51:
Dus Pfsense is opzich goed ingesteld.

Da's voor ons zo niet te controleren natuurlijk... Hoe staat eea nu ingesteld?

[Verwijderd]

Hmm, hier werkt het gewoon, al heb ik wel de static route beperkt tot whatsmyip.org en ping.eu.

Heb je de interface / IP adres van ExtraIP als default gezet ( wil je dat àl je verkeer uitgaat over de ExtraIP range, of alleen verkeer wat daarvoor bestemd is). Jullie hebben niet een gateway group aangemaakt toevallig waarbij de eigen gateway en de ExtraIP gateway in een 2/1 loadbalance configuratie staan?

[noskill]

Hebben toch echt meer info nodig hehe. Als ik ook een keer kan raden, zou ook zomaar kunnen dat je modem/pfsense/clients moeilijk doen omdat verkeer binnen komt via route A (ExtraIP) en vertrekt via route B (Ziggo). Je kan dat vaak snel zien als je kijkt in diagnostics > states.

[Vorkie]

Ik ben diegene achter Kragt-ICT, PFsense staat echt goed ingericht.

Na uitvoerig troubleshooten, van het ExtraIP subnet op een ander endpoint (waar deze wel werkte!) tot uiteindelijk een fysieke machine met PFSense voorzien, komen wij uit op het Hiltron modem van Ziggo. Zo hebben wij alle lokale infrastructuur, zoals switches en servers, uitgesloten.

Na een verse installatie en configuratie van het ExtraIP subnet volgens mijn eigen handleidingen en configuraties die ik her en der al uitgevoerd hebt, blijft het probleem zich voordoen.

Na een Packet Capture op de WAN interface is te zijn dat er vanaf het modem van Ziggo is duidelijk te zien dat er vaak een bad cksum voorbij komt op de GRE tunnel, waarbij het source mac adres, logischerwijs, het modem is.

code:

18:16:33.385047 f0:f2:49:xx:xx:xx > 2c:27:d7:xx:xx:xx, ethertype IPv4 (0x0800), length 84: (tos 0x48, ttl 246, id 49195, offset 0, flags [none], proto GRE (47), length 70, bad cksum b032 (->b07a)!)
    185.x.x.x > 92.x.x.x: GREv0, Flags [none], proto IPv4 (0x0800), length 50
    (tos 0x0, ttl 56, id 44872, offset 0, flags [none], proto ICMP (1), length 28)
    159.x.x.x > 185.x.x.x: ICMP echo request, id 47246, seq 16240, length 8

Aangezien de tunnel op andere verbindingen wel werkt en het gedrag op alle mogelijke manieren ik binnen @Operations zijn netwerk (zelfs erbuiten ) kan reproduceren, lijkt het probleem zich te richten op het modem, dat is namelijk het enigste wat nog overblijft...

Ziggo heeft natuurlijk geen idee.... dus misschien iemand anders hier?

[Verwijderd]

Zoals ik aangaf heb ik ook Ziggo zakelijk, en bij mij is recent het Hitron modem vervangen door een Ubee modem, vanwege aanpassing van het netwerk.

Ik moet eerlijkheidshalve wel erbij vermelden dat ik ook een /29 van Ziggo afneem en daarnaast even een ExtraIP testrange heb geconfigureerd volgens de handleiding op jouw site met een static route voor een beperkt aantal destination ip's . Mijn natting staat in HybridMode, waarbij het verkeer wat via de GRE tunnel uitgaat ook het interface Ip krijgt.

Ondanks dat ik Quad9 op de lijst voor de static route heb geplaats, blijft deze wel via mijn "default" ziggo gateway lopen, ping.eu en (www.)whatsmyip.org staan ook op de lijst, en deze gaan idd wel netjes via de ExtraIP gateway zoals het hoort.

one.one.one.one reageert niet op ICMP (althans hier niet).

-edit-

De modem wijziging was destijds nodig vanwege de abonnements aanpassing naar 300/40

-edit2-

Na het disablen van de Block private and loopback adressen en Bogon networks, en het re-enablen ervan (re-enablen van het blokkeren dus) pakt hij wel de juiste route op naar Quad9.
Alles zonder verdere issues

[ Voor 15% gewijzigd door Verwijderd op 07-04-2020 22:14 ]

[Operations]

Verwijderd schreef op dinsdag 7 april 2020 @ 22:01:
Zoals ik aangaf heb ik ook Ziggo zakelijk, en bij mij is recent het Hitron modem vervangen door een Ubee modem, vanwege aanpassing van het netwerk.

Ik moet eerlijkheidshalve wel erbij vermelden dat ik ook een /29 van Ziggo afneem en daarnaast even een ExtraIP testrange heb geconfigureerd volgens de handleiding op jouw site met een static route voor een beperkt aantal destination ip's . Mijn natting staat in HybridMode, waarbij het verkeer wat via de GRE tunnel uitgaat ook het interface Ip krijgt.

Ondanks dat ik Quad9 op de lijst voor de static route heb geplaats, blijft deze wel via mijn "default" ziggo gateway lopen, ping.eu en (www.)whatsmyip.org staan ook op de lijst, en deze gaan idd wel netjes via de ExtraIP gateway zoals het hoort.

one.one.one.one reageert niet op ICMP (althans hier niet).

-edit-

De modem wijziging was destijds nodig vanwege de abonnements aanpassing naar 300/40

-edit2-

Na het disablen van de Block private and loopback adressen en Bogon networks, en het re-enablen ervan (re-enablen van het blokkeren dus) pakt hij wel de juiste route op naar Quad9.
Alles zonder verdere issues

Op een ander adres met zelfde abonnement en ook een Ubee modem werkt het zonder problemen. Het wil echt alleen vanaf mijn eigen adres niet.

Ander modem is niet mogelijk volgens Ziggo, zou komen doordat het oud UPC gebied is. Of een ander modem de oplossing is, is uiteraard niet 100% zeker.

[ Voor 5% gewijzigd door Operations op 07-04-2020 23:18 ]

[moppentappers]

Verwijderd schreef op dinsdag 7 april 2020 @ 22:01:
Zoals ik aangaf heb ik ook Ziggo zakelijk, en bij mij is recent het Hitron modem vervangen door een Ubee modem, vanwege aanpassing van het netwerk.

Ik moet eerlijkheidshalve wel erbij vermelden dat ik ook een /29 van Ziggo afneem en daarnaast even een ExtraIP testrange heb geconfigureerd volgens de handleiding op jouw site met een static route voor een beperkt aantal destination ip's . Mijn natting staat in HybridMode, waarbij het verkeer wat via de GRE tunnel uitgaat ook het interface Ip krijgt.

Ondanks dat ik Quad9 op de lijst voor de static route heb geplaats, blijft deze wel via mijn "default" ziggo gateway lopen, ping.eu en (www.)whatsmyip.org staan ook op de lijst, en deze gaan idd wel netjes via de ExtraIP gateway zoals het hoort.

one.one.one.one reageert niet op ICMP (althans hier niet).

-edit-

De modem wijziging was destijds nodig vanwege de abonnements aanpassing naar 300/40

-edit2-

Na het disablen van de Block private and loopback adressen en Bogon networks, en het re-enablen ervan (re-enablen van het blokkeren dus) pakt hij wel de juiste route op naar Quad9.
Alles zonder verdere issues

Ik heb ook regelmatig dat ik dit moet doen om mijn tunnel weer werkend te krijgen, ik heb een glasvezelverbinding van Routit op het caiway netwerk

[Verwijderd]

Operations schreef op dinsdag 7 april 2020 @ 23:17:
[...]


Op een ander adres met zelfde abonnement en ook een Ubee modem werkt het zonder problemen. Het wil echt alleen vanaf mijn eigen adres niet.

Ander modem is niet mogelijk volgens Ziggo, zou komen doordat het oud UPC gebied is. Of een ander modem de oplossing is, is uiteraard niet 100% zeker.

Hier ook oud UPC gebied postcode 3132

[Vorkie]

@moppentappers

Betreft het "resetten" dat is raar, ik heb dan nog niet de upgrade naar 2.5 uitgevoerd (foei), maar mijn PFsense draait nu dan 85 dagen stabiel en hoef nooit zulke acties uit te halen. Valt dan echt het hele verkeer weg?
Ik heb wel eerder iemand gehoord dat hij een ICMP/pingetje liet lopen naar de gateway of router van zijn ISP verbinding, iets in de richting met ARP tabellen, maar weet het fijne er niet meer van, maar scheen wel te helpen met iets in diezelfde trend.

@Verwijderd
Vreemd dat ie dan niet gelijk de juiste route pakt, lijkt dan eerder iets van PFsense te zijn, mijn primaire verkeer verloopt allemaal over de ExtraIP IPv4/6 subnetten, secundair gebruik ik mijn privaat Ziggo verbinding, maar moet eerlijk bekennen dat ik daar nooit echt op gelet hebt (stuur maar weinig direct Ziggo op)

Waarschijnlijk is een re-configuratie van een firewall rule (disable/enable) ook al voldoende, dat triggered een "reset" en leest dan de IPTABLES etc weer in.

Hoop dat @Operations of gewoon een nieuw modem krijgt (niet geschoten altijd mis) of een ander modem, maar dan moeten ze wel het probleem begrijpen bij Ziggo....

[MrNGm]

Verkeer van/naar Cloudflare DNS, Google DNS en Quad9 kunnen natuurlijk andere routes volgen. Tussenliggende routers kunnen ping-traffic droppen.

Ik zit via een tussenpartij op Ziggo grootzakelijk en krijg WAN via Ethernet. Traces op m'n ExtraIP-interface (Mikrotik, GRE-tunnel) richting 1.1.1.1, 8.8.8.8, en 9.9.9.9:

code:

[admin@MikroTik] /tool> traceroute interface=extraip-v4 count=5 1.1.1.1 
 # ADDRESS      LOSS SENT    LAST     AVG    BEST   WORST STD-DEV STATUS
 1 5.255.66.62      0%    5   6.5ms     7.3     6.5    10.6     1.6
 2                100%    5 timeout
 3                100%    5 timeout
 4                100%    5 timeout
 5                100%    5 timeout
 6                100%    5 timeout

code:

[admin@MikroTik] /tool> traceroute interface=extraip-v4 count=5 8.8.8.8   
 # ADDRESS         LOSS SENT    LAST     AVG    BEST   WORST STD-DEV STATUS
 1 5.255.66.62       0%    5     6ms     6.1       6     6.3     0.1
 2 185.1.95.82       0%    5 109.3ms    27.7     6.2   109.3    40.8
 3 108.170.241.161   0%    5   6.5ms     6.6     6.5     6.7     0.1
 4 108.170.236.227   0%    5   6.1ms     6.2     6.1     6.6     0.2
 5 8.8.8.8           0%    5   5.9ms     5.8     5.8     5.9       0

code:

[admin@MikroTik] /tool> traceroute interface=extraip-v4 count=5 9.9.9.9
 # ADDRESS         LOSS SENT    LAST     AVG    BEST   WORST STD-DEV STATUS
 1 5.255.66.62       0%    5   6.1ms     7.1     6.1    10.8     1.8
 2 185.40.92.105     0%    5   6.3ms     6.3     6.2     6.3       0
 3 193.239.116.123   0%    5   8.7ms    37.3     8.7    76.4    24.7
 4 9.9.9.9           0%    5    13ms    13.1      13    13.3     0.1

Voor Cloudflare gaat het niet goed, Google DNS en Quad9 werken prima.

(edit: ik ben eigenlijk wel benieuwd wat het probleem is, want voor zover ik kan zien werkt je ExtraIP-subnet prima?)

[ Voor 3% gewijzigd door MrNGm op 20-04-2020 21:56 ]

[miguelacknow]

Sinds deze week werkt ExtraIP niet meer naar behoren via Ziggo.
Je haalt nog max 20/20mbit. Erg vreemd aangezien dit voorheen wel werkte. Als je het test via T-Mobile thuis of KPN haal je volle snelheid door de GRE tunnel.

Iemand hier ook ervaring mee via Ziggo?