Uitgaande SMTP-poort (25) is geblokkeerd behalve via Security level Standard met de KPN Box 12

Poort 25 wordt volgens mij bij alle providers op netwerk niveau geblokkeerd (dus aan de kant van KPN). Dit is een dusdanig gevaarlijke poort (net als Samba 138 e.d.) dat deze dus op hoger niveau geblokkeerd wordt. 

Heel raar dat dat bij jou wel werkt.

Overigens is inkomend poort 25 wel toegestaan. 

Edit: ik zie inderdaad dat poort 25 gewoon toegestaan is. Nooit gedacht dat dat toch kon bij KPN.

Ze waren het wel gefaseerd aan het uitschakelen maar dat was al een jaar geleden het geval. 

​@Dmitry ​@rvk01 

Als je poort 25 wil gebruiken dan zeg je in feite dat je geen versleuteling wil toepassen. Het gebruik van poort 25 wordt daarom stukje bij beetje door de KPN onmogelijk gemaakt / uitgeschakeld. Hoever de KPN hiermee gevorderd is weet ik niet. Ik persoonlijk zou gewoon het zekere voor het onzekere nemen en poort 25 uitzetten, ook in de KPN Box 12. En er niet meer over zeuren.

Ik ging er vanuit dat ie al dicht stond 😉

Via bijv. box 12 loopt de communicatie van jouw thuisnetwerk met het internetnetwerk buiten. Er kunnen misschien nog providers zijn die poort 25 gebruiken / toestaan. Ik denk dat daarom je in de Box 12 poort 25 nog kunt aan- en uitzetten maar bij de KPN wil men poort 25 gefaseerd onmogelijk maken. Gefaseerd om de KPN klantenservice niet teveel te belasten.

Ook vorig jaar waren er nog een aantal mensen die zich meldden op dit forum, die nog poort 25 gebruikten en daarom plotseling geen email meer konden versturen. Zie ook mijn vorig antwoord.

​@rvk01 

Ook voert de KPN - stukje bij beetje - de verplichting in om bij de “uitgaande server” (SMTP) authenticatie te gebruiken. Ook daar weet ik niet hoe ver de KPN daar mee gevorderd is. Ook daar waren er in de laatste ca. 14 maanden nog diverse klachten over hier op het forum.

Authenticatie moet je al gebruiken als je via het netwerk van provider A contact wil leggen met de emailservers van provider B (bijv. KPN).

En ik heb het zware vermoeden dat de KPN nog meer technische aspecten van het emailverkeer langzaam aan het “uitfaseren” is. De huidige technische situatie bij de KPN is het resultaat van vele overnames uit het verleden en die technische soepzooi kun je niet in één keer veranderen. (denk opnieuw: KPN klantenservice).

Ik draai al sinds 2005 mijn eigen mailserver dus dit is bij mij allemaal al wel bekend 😉 Alleen verbaasde het mij toen Dmitry (TS) zei dat uitgaande poort 25 nog gewoon open stond. KPN lijkt mij daarmee een van de weinige providers waarbij dit (in sommige gevallen) nog niet dicht getimmerd is. Zelfs bij Xs4all op ADSL is het op een gegeven moment dicht gezet.

Nu gebruik ik voor de uitgaande mail al jaren geen poort 25 meer (sinds Ziggo het is gaan blokkeren) dus voor mij maakt dat niet zoveel uit. Maar het verbaasde mij dus dat het bij mijn terugkomst bij KPN dus wel open stond.

Ik denk dat ook bij XS4all en Ziggo het “uitzetten” van poort 25 over een langere periode is “uitgesmeerd”. Maar KPN Box 12 is natuurlijk iets anders dan de KPN emailservers.

Nee hoor. Bij Ziggo was het pats boem afgelopen in 2011 😁
(in ieder geval over een zeer korte periode is dat dichtgezet)

Maar dit is inderdaad iets anders dan het probleem van Box 12.

Ik vraag me wel af wat de vinkjes in Custom betekenen als er “Block all” gekozen is.
Worden de aangevinkte poorten dan toegestaan of juist tegengehouden?
Misschien dat hier een interpretatie fout gemaakt wordt.

Dat is onjuist, omdat het SMTP-protocol STARTTLS (zie RFC 3207) ook op poort 25 toestaat.
Ik zie geen enkele reden waarom men poort 25 zou moeten blokkeren. Alles komt neer op een correcte configuratie van de doel-SMTP-server (encryptie / authenticatie).

Als het selectievakje 'blokkeren' zou aanvinken, zou ik niet op dit forum kunnen reageren, omdat poort 443 dan ook geblokkeerd zou zijn 😉

• "Block all" → checked box betekent "toestaan"
• "Allow all" → checked box betekent "blokkeren"

Hoi ​@Dmitry. Interessante case heb je hier bij de hand. Als ik je goed begrijp heb je dus alleen met poort 25 specifiek een probleem? Deze krijg je niet naar buiten toe geopend als je de firewall wat strenger zet? 

Het fijne weet ik hier niet van, want zo diep zit ik niet in deze materie. Begrijp ik je ook goed dat andere poorten wel geopend worden? Als dat het geval is, dan ga ik eens navragen of dit als designed is of dat er iets misgaat in de KPN Software. 

Ik probeer ook nog even ​@Marlon92 hier naar toe te lokken, want die heeft hier ook nog wel kijk op. En anders heb ik snel een antwoord voor je binnenkort. 

Correct. Ik heb het probleem alleen op poort 25 vastgesteld, maar ik heb niet de hele lijst grondig getest. Ik kan alleen bevestigen dat poorten 43, 53, 443 en 587 prima werken.

Hebt u bovenstaande configuratie op uw modem geprobeerd? Werkt poort 25 (= is toegestaan)?

Dat denk ik ook. Maar het zou het beste zijn om bovenstaande configuratie op een apart modem te testen om een derde mening te krijgen. Bedankt! 🤝

Ik kan bevestigen dat in de Block all mode de poort 25 toggle inderdaad niets uithaalt en de poort altijd dicht blijft. In de Allow all werkt de poort 25 toggle correct. Ik heb alleen even IPv4 getest.

Overigens... het grappige is dat bij poort 80 het net andersom is. Daar werkt de toggle prima onder Block all. Maar bij Allow all werkt de poort 80 toggle niet (hoe je de toggle ook zet, poort 80 is altijd open). Dus bij poort 80 is het probleem precies omgekeerd 🤔 O, dit is bij poort 443 ook het geval. Niet te blokkeren in de Allow all stand.

Aaaaaargh. Ja, dat werkt. Wat een maffe interface. Maar inderdaad. Bij bepaalde regels is het » en bij andere x. Dus het is inderdaad dat 'niet aan' gewoon niets doet (default=block) en wel aangevinkt doet die actie (wat standaard dus ook block is).

Je zou toch verwachten dat als je Block all mode doet, dat alle acties dan op » komen te staan (omdat x geen zin heeft omdat dit al default is) en het vinkje de uitzondering is.

Maar goed. Het is dus inderdaad geen bug in de software.

Ik ben het ermee eens, een lastige interface 😭
Nu is het duidelijk en werkt poort 25 goed 🎉

Dank aan jullie allemaal!

​@hmmsjan_2 

​@Dmitry 

​@rvk01 

Misschien willen jullie meedoen aan dit KPN programma ?

Dan kunnen jullie hopelijk ook dit soort storende dingen (/ foutjes ??) (laten) verbeteren. Bijv. ook de “maffe interface”. Daar kunnen jullie dan ook meewerken om de producten van de KPN te verbeteren.

​@Dmitry 

Kun je nog even een beter screenshot plaatsen van het eerste plaatje met een hogere resolutie ?

​@WMG-N  Daar ben ik al lid van.

De implementatie is wat verwarrend. Het groene schuifje betekent: zet deze regel in de actieve firewall.

Bij de port forwarding en ipv6 binnenkomende firewall is het eenduidig: 

de actie van een regel is “ACCEPT” en standaard is “Alles blokkeren” .

Dus: schuifje op groen betekent poort open.

Bij de uitgaande firewall ligt het anders: de actie is ACCEPT of DROP, weergegeven door “>>” en “X”, 

en de defaults zijn naar keuze alles blokkeren of alles toelaten.

Dan krijg je dus:

Om deze verwarring te voorkomen is het misschien beter in de firewall het schuifje te vervangen door een simpel vinkje met duidelijk erbij dat het “Activeer regel” betekent. Dit om onderscheid te maken tussen het schuifje bij de port forwarding dat “Open poort” betekent maar in de firewall zelfs “Sluit poort” kan betekenen. 

De opnsense firewall zet de actie meteen aan het begin van de regel met een pass/block/reject symbooltje, door daarop te drukken wordt de regel uit- of ingeschakeld. 

Met wat goede uitleg is het wel duidelijk. Vanuit {ip,nf}tables gezien ook. Ik begrijp alleen niet waarom ze na het omschakelen naar Block all mode de regels voor x (drop) laten staan. Dat is immers default. Die kun je dan het beste uit de table verwijderen en/of de functie omschakelen naar een » (allow).

Wat ze nu doen is hetzelfde als een stel drop regels met op het einde een drop default. Niet echt logisch 😉

Het zou dus logischer zijn dat alle acties allemaal op » (allow) staan in Block all mode (want een drop regel doet niets bij activeren). En andersom in Allow mode waar het activeren van » (allow) niets doet omdat het default is.

Al die x (drop) regels hebben in Block all mode nu geen zin tenzij je ook de actie om switcht.

Dat zat ik ook te bedenken. Nu staan er een aantal zinloze regels in de lijst. Die zou je kunnen weglaten in de GUI. Maar stel dat bijv. SMTP verdwijnt en de gebruiker wil dat veranderen, kan hij niets anders dan SMTP als nieuw toevoegen. En als een gebruiker een nieuwe zinloze regel toevoegt verdwijnt die meteen weer. Iets voor een GUI specialist om zich nog eens over te buigen.

Je zou, in plaatst van hem weg te halen, ook de actie gewoon op allow kunnen zetten. 

Actie is in die hele rij dan eigenlijk niet nodig. 

Drop acties hebben n.l. geen zin in een Block all mode en Allow heeft geen zin in Allow all mode.

Dus actie zou gewoon altijd het tegenovergestelde moeten zijn van de mode. De gebruiker kan vervolgens kiezen of die regel inderdaad actief moet zijn. (Zo las ik het oorspronkelijk voordat jij wees op dat actie icoontje 😉).

Mits duidelijk in de GUI zou het zo wel overzichtelijker worden. Maar er zijn wel wat dingen om over na te denken:

KPN defaults om standaard internetten niet onmogelijk te maken, overbodig in “alles toelaten”

KPN defaults om onveilige protocollen te ontmoedigen, overbodig in “alles blokkeren” 

En een gebruiker die zorgvuldig een “alles blokkeren” firewall heeft opgebouwd moet niet alles kwijt zijn na een keer overschakelen naar een andere modus. dat wordt zeker niet gewaardeerd.  

Ook OPNsense of iptables kun je volzetten met regels die in een klap overbodig worden gemaakt door de laatste regel.   

Maar “actie tegengesteld aan mode” zou het in ieder geval overzichtelijker maken. Misschien is het voldoende om in de achtergrond de volledige tabel te bewaren, en alleen de relevante informatie in de GUI te tonen. Een nieuwe regel is dan een kwestie van service/poort selecteren en actief/inactief kiezen.

Dat ben ik met je eens. Nu is het inderdaad zo dat schakelen tussen Allow en Block all alleen alle toggles omgezet worden plus dat er een laatste regel met “DROP all” of “ALLOW all” gedaan wordt.

Maar zelf met behoud van de actie zou de interface wel duidelijker kunnen. Vooral dat icoontje zou duidelijker moeten. Al was het maar dat het geen icoontje is maar de tekst BLOCK of ALLOW o.i.d. Een icoontje is erg makkelijk over het hoofd te zien (zoals bij mij en Dmitry 😉). Maar dat is voor de GUI ontwikkelaars 😃

Ik zie dat je met “aangepaste regel toevoegen” ook DNAT kunt uitvoeren. Dat zou betekenen dat je van alles of een specifiek systeem op het LAN het verkeer kunt omleiden naar een ander systeem en/of andere poort op WAN. Daar moet ik even over nadenken wat daar de toepassingen van kunnen zijn. Maar eens testen, maar zeker niet met poort 443….

Ik heb de screenshot hier geüpload, maar daarop is poort 25 al “gefixt”.

P.S. Er zijn ook twee vermeldingen voor poort 443 (“https” en “QUIC”), wat ik ook verwarrend vind.

HTTPS is port 443 over TCP.

QUIC is port 443 over UDP.

https://wpprovider.nl/wat-is-http-3-en-quic/