Bizar: website belastingdienst doet het niet totdat...

[Urk]

Ik heb bij en klant echt een bizar probleem waarvan ik echt niet begrijp hoe het ontstaat. Deze klant heeft een Sonicwall TZ570 firewall met diverse security services aanstaan. De website van de Belastingdienst doet het daar meestal niet, zodra ze een laptop niet via bekabeld netwerk maar via een 5G hotspot verbinden werkt de website prima. Zodra ze koppelen aan het bedrade netwerk weer niet. ECHTER, zodra ik op mijn iPhone die aan de WiFi hangt van de klant de website van de belastingdienst opvraag duurt het enkele seconden en laadt hij prima in (iOS 18.5 - Safari). Daarna werkt de website voor ongeveer een half uur (niet echt exact getimed) ook weer op alle systemen via het bedrade netwerk. En daarna herhaalt het probleem zich steeds opnieuw. Na ongeveer een half uur werkt de site niet meer en zodra ik hem dan weer op mijn iPhone open werkt hij weer bij iedereen.... Doe ik niets op mijn iPhone dan blijft de site bij iedereen onbereikbaar. Zo
Het lijkt geen DNS issue te zijn want belastingdienst.nl blijft steeds correct resolven. Het lijkt ook dat de Sonicwall hem niet blokkeert gezien daar niets over wordt gelogd in de Sonicwall logs....
Dit issue speelt ook al meer dan 8 weken, het is dus niet iets tijdelijks.

Iemand ooit zoiets meegemaakt of een idee in welke hoe ik dit moet zoeken...?

[Jan-man]

Heb zoiets meegemaakt met Microsoft sites. Bleek dat de MTU waarde verkeerd te staan..... Alles werkte daar direct behalve Microsoft/mail/teams...... Die laden traag of niet en dan weer wel, precies wat jij beschrijft.

[ Voor 21% gewijzigd door Jan-man op 18-07-2025 13:10 ]

[Urk]

Jan-man schreef op vrijdag 18 juli 2025 @ 13:09:
Heb zoiets meegemaakt met Microsoft sites. Bleek dat de MTU waarde verkeerd te staan..... Alles werkte daar direct behalve Microsoft/mail/teams...... Die laden traag of niet en dan weer wel, precies wat jij beschrijft.

Dank voor je snelle reactie! Ja maar dan zou hij toch helemaal niet moeten werken todat de MTU is aangepast? Nu je het zegt heb ik wel een keer vreemd webinterface gedrag meegemaakt bij een andere klant met een Hikvision recorder waar de MTU op de recorder verkeerd ingesteld stond. Toen dat was aangepast deed de site het prima...

Ik neem aan dat je ook bedoeld de MTU van de WAN connectie op de Sonicwall?

[ Voor 5% gewijzigd door Urk op 18-07-2025 13:15 ]

[Reptile209]

Urk schreef op vrijdag 18 juli 2025 @ 13:15:
[...]

Dank voor je snelle reactie! Ja maar dan zou hij toch helemaal niet moeten werken todat de MTU is aangepast? Nu je het zegt heb ik wel een keer vreemd webinterface gedrag meegemaakt bij een andere klant met een Hikvision recorder waar de MTU op de recorder verkeerd ingesteld stond. Toen dat was aangepast deed de site het prima...

Ik neem aan dat je ook bedoeld de MTU van de WAN connectie op de Sonicwall?

Tenzij de iPhone een lagere/andere MTU op het netwerk forceert, die dan na een tijdje weer vervalt als de iPhone niet actief (meer) is. Geen idee of dat zo werkt overigens, maar kan een verklaring zijn. .

[Urk]

Reptile209 schreef op vrijdag 18 juli 2025 @ 13:17:
[...]

Tenzij de iPhone een lagere/andere MTU op het netwerk forceert, die dan na een tijdje weer vervalt als de iPhone niet actief (meer) is. Geen idee of dat zo werkt overigens, maar kan een verklaring zijn. .

Hm, ja zoiets lijkt het te zijn, maar weet ook niet of dat zo kan werken? De MTU op de Sonicwall WAN connectie staat trouwens instesteld op 1492. Zou hem eens op 1500 kunnen zetten in overleg met de provider....

[Edit] Zojuist geprobeerd in overleg met de provider om MTU op WAN om te zetten van 1492 naar 1500 maar site van belastingdienst blijft niet werken. Ook stond in de Sonicwall WAN connectie de optie "Fragment non-VPN outbound packets larger than this Interface's MTU" aan maar ook die uitzetten maakt geen verschil.
De provider herkende dit verhaal ook niet en hebben ook geen idee...

Edit2 Dit probeem is trouwens ook iets van de laatste maanden, daarvoor hebben we dit probleem nooit gehad...

[ Voor 31% gewijzigd door Urk op 18-07-2025 13:30 ]

[Jan-man]

Urk schreef op vrijdag 18 juli 2025 @ 13:18:
[...]

Hm, ja zoiets lijkt het te zijn, maar weet ook niet of dat zo kan werken? De MTU op de Sonicwall WAN connectie staat trouwens instesteld op 1492. Zou hem eens op 1500 kunnen zetten in overleg met de provider....

Vraag even na bij je provider welke je moet hebben (kpn lijnen 1500). Bij ons stond ie ook op 1492 en de lokale provider gebruikte 1500. Was een verhuizing waarbij de router was mee verhuist en het dus verkeerd stond omdat de oude lijn wel 1492 was.

[Urk]

Jan-man schreef op vrijdag 18 juli 2025 @ 13:31:
[...]


Vraag even na bij je provider welke je moet hebben (kpn lijnen 1500). Bij ons stond ie ook op 1492 en de lokale provider gebruikte 1500. Was een verhuizing waarbij de router was mee verhuist en het dus verkeerd stond omdat de oude lijn wel 1492 was.

Tnx, zojuist gedaan, zie edits hierboven. Server MRU staat ook op 1492 (neem aan dat de PPPoE server dat doorgeeft) en provider zegt dus ook dat 1492 prima moet zijn.

[Edit] We hebben wel een aantal maanden geleden, maar naar mijn gevoel langer geleden dan dat dit issue ging ontstaan het subnet mask van ons netwerk omgezet van 255.255.255.0 naar 255.255.254.0 gezien de DHCP scope niet meer toereikend was. Ik zie nu dat zowel de subnet mask van de LAN zijde in de Sonicwall netjes staat ingesteld op 255.255.254.0 en ook de IP's op mijn laptop en mijn iPhone vallen beiden nog in de oorsprokelijke reeks (192.168.66.x) en ook bij beide DHCP clients is het subnet 255.255.254.0....

[ Voor 32% gewijzigd door Urk op 18-07-2025 13:36 ]

[The Eagle]

Ik ben geen netwerk expert, maar ik zit aan twee richtingen te denken om te onderzoeken:
1. Web framework in gebruik bij BD. ZIjn er andere site met het zelfde framework die de zelfde isues opleveren? Geen idee hoe je dat kunt zien btw. Maar heb zoiets soortgelijks eens meegemaakt toen flash geblockt werd. En de BD is dermate oud dat het me niet zou verbazen als er bepaalde elementen in zitten die de sonicwall uit vorozorg al standaard blockt

2. Interface settings van de firewall, icm subnetting van wifi en bekabeld lan.
Plaatje zegt meer dan 100 woorden, dus: https://docs.pi-hole.net/ftldns/interfaces/
Bij mijn pihole heb ik dit. Permit all origins heb ik aan staan, omdat mijn VPN op een apart subnet staat en ie bij de eerste twee opties slechts 1 hop afstand accepteert, Dat projecterend op jouw situatie: Sonicwall in het wifi subnet, LAN apart subnet (oid, hoeft niet specifik subnet als oorzaak te zijn), teveel aan hops is bork. Op LAN werkt het niet, schakel naar wifi: werkt wel, blijft het doen. DNS / ARP cache dan even lokaal voor een half uur en daarna invalid, dus opnieuw opvragen. Maar dan zit je alweer op LAN --> borked.

Als het idd de lokale DNS / ARP cache is: op een laptop het scenario naspelen, en dan nog eens 2x nadat je een flushdns resp arp cache removal hebt gedaan.

Long shot, maar misschien helpt het

[FreakNL]

Urk schreef op vrijdag 18 juli 2025 @ 13:32:
[...]

Tnx, zojuist gedaan, zie edits hierboven. Server MRU staat ook op 1492 (neem aan dat de PPPoE server dat doorgeeft) en provider zegt dus ook dat 1492 prima moet zijn.

[Edit] We hebben wel een aantal maanden geleden, maar naar mijn gevoel langer geleden dan dat dit issue ging ontstaan het subnet mask van ons netwerk omgezet van 255.255.255.0 naar 255.255.254.0 gezien de DHCP scope niet meer toereikend was. Ik zie nu dat zowel de subnet mask van de LAN zijde in de Sonicwall netjes staat ingesteld op 255.255.254.0 en ook de IP's op mijn laptop en mijn iPhone vallen beiden nog in de oorsprokelijke reeks (192.168.66.x) en ook bij beide DHCP clients is het subnet 255.255.254.0....

Wat bedoel je met je edit?

Je hebt het SN aangepast naar /23 en je clients krijgen ook /23? Dat is toch prima? Ik snap de dan ook niet.


Verder:
Wat gebeurt er als je de laptop van de klant aan de wifi hangt? (ipv kabel)
Wat gebeurt er als je een laptop van jezelf meeneemt en aan de wifi hangt of kabel?

[ Voor 9% gewijzigd door FreakNL op 18-07-2025 15:58 ]

[Frogmen]

Zou eens proberen wat er gebeurt als je een security uitzet. Welke geeft problemen en wat doet deze? Kortom elementair storing zoeken en uitsluiten.

[mrmrmr]

@Urk
Heeft de klant een Fritz!Box in gebruik voor de internetverbinding?

[BCC]

Klopt de ntp server die je krijgt via dhcp? Mogelijk dat de ssl handshake stukloopt om een of andere reden ? De iPhone default altijd naar Apple voor zover ik weet

[mrmrmr]

BCC schreef op vrijdag 18 juli 2025 @ 18:45:
Klopt de ntp server die je krijgt via dhcp? Mogelijk dat de ssl handshake stukloopt om een of andere reden ? De iPhone default altijd naar Apple voor zover ik weet

Ik verdenk ook een timingprobleem maar niet op de client of een content protocol, maar op een lager niveau in het netwerk.

Er kan een timingsprobleem zich voordoen als de firewall in tijd is teruggezet (wegens verlopen licentie?) of als de tijd niet helemaal goed verloopt (lege CMOS batterij of defecte klok) en voortdurend gecorrigeerd moeten worden. Packets worden door de firewall opnieuw opgebouwd, want NAT.

Ik heb dit soort problemen gezien bij de site van de Belastingdienst en een Fritz!Box modem (nogmaals NAT), terwijl andere sites gewoon werken. De SYN packets worden wel ontvangen maar niet doorgestuurd door de Fritz!Box.

@Urk Op sommige modems, routers en firewalls kun je netwerkverkeer opvangen (capture) en met Wireshark bekijken. Op de Fritz!Box: http://192.168.178.1/#/cap

[FredvZ]

Urk schreef op vrijdag 18 juli 2025 @ 13:07:
IDe website van de Belastingdienst doet het daar meestal niet,
[..]
Iemand ooit zoiets meegemaakt of een idee in welke hoe ik dit moet zoeken...?

Welke foutmelding geeft de browser?

[Dracoz]

Even een wilde gedachte, kan dit wellicht te maken hebben misschien met IPv4 en IPv6?

[Urk]

Dracoz schreef op vrijdag 18 juli 2025 @ 20:35:
Even een wilde gedachte, kan dit wellicht te maken hebben misschien met IPv4 en IPv6?

Hmmm, goeie maar intern gebruiken we voornamelijk IPv4. Alle servers hebben wel een statisch IPv6 adres. Publiek naar buiten alleen IPv4 maar neem aan dat de belastingdienst site prima werkt met IPv4 only toch? Of bedoel je het anders? 😬

[Urk]

FredvZ schreef op vrijdag 18 juli 2025 @ 20:06:
[...]

Welke foutmelding geeft de browser?

Er gebeurd eigenlijk niks, blijft laden en dan een time out niet gevonden...

[Urk]

FreakNL schreef op vrijdag 18 juli 2025 @ 15:56:
[...]


Wat bedoel je met je edit?

Je hebt het SN aangepast naar /23 en je clients krijgen ook /23? Dat is toch prima? Ik snap de dan ook niet.


Verder:
Wat gebeurt er als je de laptop van de klant aan de wifi hangt? (ipv kabel)
Wat gebeurt er als je een laptop van jezelf meeneemt en aan de wifi hangt of kabel?

Ah sorry ik bedoelde dat de subnetting gewoon goed ingesteld staat en daarom dit gedrag heel vreemd blijft...

Als de laptop met de bedrijfsimage aan de wifi hangt ontstaat hetzelfde gedrag. Dus site doet het niet zodat ik op m'n iPhone de site inlaadt en dan doet hij het op de laptop op WiFi opeens ook.
Met mijn eigen laptop die niet in het domein van de klant hangt gebeurd ook hetzelfde... Zowel op kabel als wifi...

[Urk]

Frogmen schreef op vrijdag 18 juli 2025 @ 16:47:
Zou eens proberen wat er gebeurt als je een security uitzet. Welke geeft problemen en wat doet deze? Kortom elementair storing zoeken en uitsluiten.

Volgens mij heb ik dit de nodige weken geleden ook geprobeerd en blijft niet werken...

[Urk]

mrmrmr schreef op vrijdag 18 juli 2025 @ 18:39:
@Urk
Heeft de klant een Fritz!Box in gebruik voor de internetverbinding?

Nee geen Fritzbox, alleen Sonicwall en regelt LAN en WAN. Dus zit geen router/modem meer voor...

[Urk]

BCC schreef op vrijdag 18 juli 2025 @ 18:45:
Klopt de ntp server die je krijgt via dhcp? Mogelijk dat de ssl handshake stukloopt om een of andere reden ? De iPhone default altijd naar Apple voor zover ik weet

Hmmm, NTP is een interne server en krijgen alle clients via GPO uitgedeeld. Tijd sync loopt overal prima. Lijkt geen tijd issue te zijn...

[Urk]

mrmrmr schreef op vrijdag 18 juli 2025 @ 19:20:
[...]


Ik verdenk ook een timingprobleem maar niet op de client of een content protocol, maar op een lager niveau in het netwerk.

Er kan een timingsprobleem zich voordoen als de firewall in tijd is teruggezet (wegens verlopen licentie?) of als de tijd niet helemaal goed verloopt (lege CMOS batterij of defecte klok) en voortdurend gecorrigeerd moeten worden. Packets worden door de firewall opnieuw opgebouwd, want NAT.

Ik heb dit soort problemen gezien bij de site van de Belastingdienst en een Fritz!Box modem (nogmaals NAT), terwijl andere sites gewoon werken. De SYN packets worden wel ontvangen maar niet doorgestuurd door de Fritz!Box.

@Urk Op sommige modems, routers en firewalls kun je netwerkverkeer opvangen (capture) en met Wireshark bekijken. Op de Fritz!Box: http://192.168.178.1/#/cap

Hmmm interessant echter loopt de datum en tijd op de Sonicwall goed volgens mij maar kan ik nogmaals checken later. Ja heb dacht ik ook al een keer een capture laten lopen maar zou ik samen met Sonicwall support nog eens kunnen doorlopen. Ook bij hen een ticket aangemaakt...
Er zijn geen licentie issues geweest op de Sonicwall

[Dracoz]

Heb je toevallig ook Deep packet inspection aan staan op de SonicWall? Je zou een exclude kunnen toevoegen voor de belastingdienst of dit eens tijdelijk uit kunnen zetten.

[FredvZ]

Urk schreef op vrijdag 18 juli 2025 @ 22:52:
Er gebeurd eigenlijk niks, blijft laden en dan een time out niet gevonden...

Ik neem aan de dat je de volgende basics ook hebt gedaan:

Dus een nslookup van de belastingdienst werkt wel?
Kan je de site van belastingdienst wel pingen?
Wat levert een traceroute op?

Ik zie twee mogelijke oorzaken:
- pakketten naar de website van de BD worden tegengehouden in de firewall
- pakketten naar de website van de BD worden de verkeerde kant op gestuurd.

Is je IPv6 configuratie op orde?

[BCC]

Drie - ssl handshake lukt niet ivm protocols , timing, time of mitm grappen die de belastingdienst niet tof vindt

[ Voor 58% gewijzigd door BCC op 19-07-2025 14:04 ]

[Urk]

Ik heb inmiddels een reactie op het ticket bij Sonicwall. Blijkbaar was ik niet de enige maar ligt het niet bij Sonicwall maar blijkbaar bij de DDOS protectie van de Belastingdienst?? Hier de reactie van Sonicwall support:

"I am letting you know that this website was reported by multiple customers on our end. After intense troubleshooting, we did not find any problem with the Sonicwall firewall on any of them. No dropped packets, no blocked connections.

However, I have advised one of them to check with the website support, to see if there is anything wrong on their end, since on our end we could not really find anything.

After checking with the website tech support team, they have found that the DDoS protection measures were set a bit too high (on the websites end) and therefore it was blocking the connection.

My advice here is to raise a case on the website to have this checked."

[Urk]

FredvZ schreef op zaterdag 19 juli 2025 @ 12:19:
[...]

Ik neem aan de dat je de volgende basics ook hebt gedaan:

Dus een nslookup van de belastingdienst werkt wel?
Kan je de site van belastingdienst wel pingen?
Wat levert een traceroute op?

Ik zie twee mogelijke oorzaken:
- pakketten naar de website van de BD worden tegengehouden in de firewall
- pakketten naar de website van de BD worden de verkeerde kant op gestuurd.

Is je IPv6 configuratie op orde?

Klopt, allemaal geprobeerd. Nslookup resolved correct en ping krijgt geen reactie. Traceroute weet ik niet meer uit m'n hoofd en zou ik moeten checken maar gezien zijn vorige reactie wordt het waarschijnlijk daar tegen gehouden.

[Urk]

Dracoz schreef op zaterdag 19 juli 2025 @ 11:49:
Heb je toevallig ook Deep packet inspection aan staan op de SonicWall? Je zou een exclude kunnen toevoegen voor de belastingdienst of dit eens tijdelijk uit kunnen zetten.

Nee staat nu uit en meeste security services dus ook tijdelijk uitgezet maar maakte geen verschil.

[UTMachine]

Urk schreef op zaterdag 19 juli 2025 @ 14:16:
Ik heb inmiddels een reactie op het ticket bij Sonicwall. Blijkbaar was ik niet de enige maar ligt het niet bij Sonicwall maar blijkbaar bij de DDOS protectie van de Belastingdienst?? Hier de reactie van Sonicwall support:

"I am letting you know that this website was reported by multiple customers on our end. After intense troubleshooting, we did not find any problem with the Sonicwall firewall on any of them. No dropped packets, no blocked connections.

However, I have advised one of them to check with the website support, to see if there is anything wrong on their end, since on our end we could not really find anything.

After checking with the website tech support team, they have found that the DDoS protection measures were set a bit too high (on the websites end) and therefore it was blocking the connection.

My advice here is to raise a case on the website to have this checked."

Gevoelsmatig stuurt Sonicwall je het bos in met een kluitje. Ik verwacht niet dat de belastingdienst jouw unieke ip speciaal filtert qua DDoS, mits je Sonicwall of een client in je netwerk geen rare dingen doet.

Dat Sonicwall niets heeft gevonden aan hun kant, betekent niet dat de fout NIET aan hun kant. Ik heb het praktisch elke keer op mijn werk zo’n opmerking als ik een ticket opent bij mijn collega’s uit een ander land.

[FredvZ]

Urk schreef op zaterdag 19 juli 2025 @ 14:16:
Ik heb inmiddels een reactie op het ticket bij Sonicwall. Blijkbaar was ik niet de enige maar ligt het niet bij Sonicwall maar blijkbaar bij de DDOS protectie van de Belastingdienst??

Dat zou alleen hout snijden als er ook gebruik wordt gemaakt van een VPN-dienst van Sonicwall. Is dat het geval?

[Meneer9]

Hi,

Wij ervaren bij onze relaties exact dezelfde issues. Hebben jullie toevallig het probleem al weten op te lossen?

[NwbrG]

De fix bij ons is geweest om de volgende interne settings van Sonicwall aan te passen (https://ip.ad.dr.es:port/sonicui/7/m/diag)

Van:


Naar:

[Qwerty-273]

Neem gewoon contact op met de Belastingdienst (via de BelastingTelefoon). Dan kunnen ze je als het goed is de juiste kant op wijzen om met IT in contact te komen.

Nu staat er veel info op de website van de Belastingdienst maar als je op de onderstaande link kijkt dan zie je de tekst: "Voor minder urgente veiligheidszaken kunt u contact opnemen met de BelastingTelefoon."
https://www.belastingdien...misbruik-computersystemen

Verder kan TCP sequence number randomization inderdaad door sommige oplossingen als apart worden geclassificeerd en als er iets te strak staat afgesteld dat de toegang geweigerd wordt. Maar dat zou je op je Sonicwall moeten zien dat de Belastingdienst niets stuurt of de connectie reset.

[BCC]

Tja, dat is een beetje twee zijden van de medaille - aan de kant probeer je injection attacks te voorkomen
en de belanstingdienst detecteert het daarom als een injection attack en blokeert het

[pauldaytona]

was goedkoper geweest om ergens daar een oude Iphone weg te leggen die zorgt dat het blijft werken?

[KinGuiN]

NwbrG schreef op vrijdag 1 augustus 2025 @ 09:29:
De fix bij ons is geweest om de volgende interne settings van Sonicwall aan te passen (https://ip.ad.dr.es:port/sonicui/7/m/diag)

Van:
[Afbeelding]

Naar:
[Afbeelding]

Dit is de oplossing. Zojuist bij drie klanten met dit probleem doorgevoerd, alle drie kunnen direct weer de website van de Belastingdienst bezoeken. Leuker kunnen we het niet maken...

[Freeaqingme]

Als het daadwerkelijk een MTU issue is zou je wel nog wat dingen kunnen proberen. Bijvoorbeeld, een request te doen naar http://belastingdienst.nl ipv https:// . Dan krijg je een betrekkelijk kleine response terug, en kan je zien of die dat wel doet. Daarbij valt op dat de BD een IPv6 configuratiefout heeft voor poort 80:

code:

curl -6 http://belastingdienst.nl -v
*   Trying [2a04:9a01:1002::33]:80...
* Connected to belastingdienst.nl (2a04:9a01:1002::33) port 80 (#0)
> GET / HTTP/1.1
> Host: belastingdienst.nl
> User-Agent: curl/7.88.1
> Accept: */*
> 
* Recv failure: Connection reset by peer
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer

Terwijl met IPv6:

code:

curl -4 http://belastingdienst.nl -v
*   Trying 85.159.98.33:80...
* Connected to belastingdienst.nl (85.159.98.33) port 80 (#0)
> GET / HTTP/1.1
> Host: belastingdienst.nl
> User-Agent: curl/7.88.1
> Accept: */*
> 
* HTTP 1.0, assume close after body
< HTTP/1.0 302 Moved Temporarily
< Location: https://belastingdienst.nl/
< Server: BigIP
* HTTP/1.0 connection set to keep alive
< Connection: Keep-Alive
< Content-Length: 0
< 
* Connection #0 to host belastingdienst.nl left intact

Wellicht kan je kijken wat het resultaat is van precies deze 2 linux commando's?

Als het inderdaad een MTU probleem zou zijn, kan je ook nog eens kijken of je iets van MSS clamping kan aanzetten in je router.

[Urk]

KinGuiN schreef op dinsdag 5 augustus 2025 @ 15:23:
[...]


Dit is de oplossing. Zojuist bij drie klanten met dit probleem doorgevoerd, alle drie kunnen direct weer de website van de Belastingdienst bezoeken. Leuker kunnen we het niet maken...

Top! Bij mijn klant werkt de site met deze Sonicwall aanpassingen ook. Heel fijn @NwbrG

[Goudhaar]

NwbrG schreef op vrijdag 1 augustus 2025 @ 09:29:
De fix bij ons is geweest om de volgende interne settings van Sonicwall aan te passen (https://ip.ad.dr.es:port/sonicui/7/m/diag)

Van:
[Afbeelding]

Naar:
[Afbeelding]

Dank! Ook bij ons heeft dit het probleem verholpen.

[c-nan]

Nevermind

[ Voor 96% gewijzigd door c-nan op 25-08-2025 16:52 ]

[Zenomyscus]

NwbrG schreef op vrijdag 1 augustus 2025 @ 09:29:
De fix bij ons is geweest om de volgende interne settings van Sonicwall aan te passen (https://ip.ad.dr.es:port/sonicui/7/m/diag)

Van:
[Afbeelding]

Naar:
[Afbeelding]

Waarom werkt deze aanpassing? Alsin, waarom zou de site van de belastingdienst het niet doen met de eerste set instellingen? Ik probeer het te begrijpen, maar ik zie niet waarom dit een verschil maakt. Zeker omdat andere sites wel werken.

[Urk]

Zenomyscus schreef op maandag 25 augustus 2025 @ 17:02:
[...]

Waarom werkt deze aanpassen? Alsin, waarom zou de site van de belastingdienst het niet doen met de eerste set instellingen? Ik probeer het te begrijpen, maar ik zie niet waarom dit een verschil maakt. Zeker omdat andere sites wel werken.

Ja, daar ben ik ook wel benieuwd naar. Lijkt wel of de site headers van de belastingdienst malformed zijn ofzo? En waarom alleen bij de belastingdienst? En waarom alleen bij Sonicwall?

[mrmrmr]

Ik zag dit probleem met verkeer dat door een bepaalde router (inmiddels vervangen) ging en daarna door een Fritz!Box niet gerouteerd werd en ander verkeer wel. De ipv4 packets zijn gecaptured op de Fritz!Box en die zaten niet in het uitgaande verkeer.

Na laden in Wireshark gaf die geen foutmeldingen op de TCP SYN packets. De checksums zijn correct. Er is mogelijk een timing element, hoewel er geen timestamp in de packet aanwezig is. Soms werkt het een periode (maanden/weken) lang wel, en soms een periode lang niet. De SYN packet is 66 bytes groot. MSS 1460. SACK permitted.