Skip to main content

Hallo,

 

Ik ben vandaag aan het testen geweens and ik zie dat KPN inbound port 25 tegenhoud.

Ik heb namelijk 2 Nat rules aangemaakt als test

Inkomend port 25 → Lan IP port 3389   verkeerd wordt niet door gelaten. Telnet mislukt

Inkomend port 26 → Lan IP port 3389 verkeerd komt binnen. Telnet success.

Nu is de vraag, waarom? Uitgaand verkeer via port 25 werkt pirma, ik heb een exchnage server draaien intern en een spamfilter in de cloud. Alle mails die naar mijn domeind komen gaan via de spamfilter en komen dan binnen via port 25, echter werkt dit niet meer sinds de overstap van Ziggo.

Met ziggo had ik het probleem juis anderson port 25 naar binnen werkte wel, port 25 naar buiten niet. Maar dat was te verhelpen via een smarthost dus verzende ging prima.

Ik begreep dat KPN helemaal geen porten blokkeerder, echter kom ik er dus nu achter dat dat dus wel gebeurt.

 

zodra ik ook maar iest probeer op port 25 via NAT dan werkt het niet meer (zie test boven).

Iemand enig idee hoe dit op te lossen?

 

Hemant

 

 

 

 

 

 

 

Nog eens geprobeert vanaf een AWS instance (us-east-1) en dat werkt dus ook gewoon. Ik begin te twijfelen aan met poging van gisteren alhoewel ik toch eigenlijk zeker weet dat ik hetzelfde moet hebben geprobeerd.

Maar in elk geval werkt het voor mij vanaf Simyo en vanuit AWS.


Tot de conclusie dat de blokkade bij het netwerk van het werk zit was ik inmiddels ook gekomen.


@Hemant, Test jij ook via 4G en niet vanaf het netwerk van jouw werkgever?


Ik wordt gek, hoe kan het dat het bij jullie werkt en bij mij niet :(

 

Nee test niet van mijn werk ik heb VM’s in Azure draaien heb US/Europe geprobeerd en geen van ze komen binnen,

Heb via me mobiel 4g gerprobeerd en kom er ook niet in.

verander ik de poort inkomend naar 26 → 25, dan kan ik er vanaf mobiel en de andere servers ook gewoon bij.

 

Hemant

 


Ik wordt gek, hoe kan het dat het bij jullie werkt en bij mij niet :(

 

Nee test niet van mijn werk ik heb VM’s in Azure draaien heb US/Europe geprobeerd en geen van ze komen binnen,

...

 

Azure an sich zal geen blokkades opwerken, maar weet je zeker of de VM's niet nog iets van anti virus software hebben draaien die kunnen blokkeren?


Ik heb overigens geen fysieke router, ik draai openwrt op ESX, maar dat zou niks moeten uitmaken.

alle andere 80 poorten werken namelijk wel.

 

Hemant


Hoi,

 

draaien allemaal Ubuntu LTS 20.04, draait vreders geen antivirus op.

Mobiel 25-25 werkt ook niet.

 


Het vreemde is als ik een portscan doe dan zie ik wel een ok:

 

 


Ik kan eigenlijk alleen maar hetgeen wat @wjb al gezegd heeft bevestigen: poorten blokkeren, zowel inkomend als uitgaand: mogen we niet, dus doen we niet.


Ik geef het op snap er niks van.

 

Port 25 krijg ik er niet doorheen.

GPON van d stekker af gehad. - zelfde probleem

Andere router (Tplink ) eraan gezet - zelfde probleem

OpenWRT - Zelfde probleem

OPNSense - Zelfde probleem

Switch 1 - restart zelfde probleem

Switch 2 restart -zelfde probleem

Via 4G - zelfde probleem

Via US Azure -Zelfde probleem

Via UK Azure Zelfde probleem

 

 

Als ik ooit een keer weer rustig tijd heb ga ik weer stoeien, wil Nu even geen ort 25 meer zien 🙂. Tenzij iemand een briljant idee heeft; altijd welkom.

 

Bedankt voor het meedenken


Er is ook al een probleem met VPN verbindingen geweest op XGS.PON verbindingen, het zal toch niet zo zijn dat iets soortgelijks hier ook speelt.


Hoi,

 

Nope geen VPN gewoon direct op de WAN IP.

Net weer even getest vanuit Azure en via 4G.

Ik heb poorten 465 SMTP(S) en Port 25 dicht gezet en extra logging op de firewall aangezet.

Als ik een Telnet doe naar port 465 dan zie ik die op de firewall terug in een denied stage.

Doe ik hetzelfde voor port 25, dan verschijnt er niks in de firewall.

 

Conclusie is dus echt dat port 25 nooit bij mijn WAN IP komt, ik kan er verder niks van maken. Anders zou ik die terug zien in mijn log. Alle andere poorten zie ik netjes wel als Pass of Deny terug in mijn logs.

 

Lijkt me dus toch iets op KPN netwerk en niet aan mijn kant.

 

Hemant

 

 


Conclusie is dus echt dat port 25 nooit bij mijn WAN IP komt, ik kan er verder niks van maken.

Dat bedoelde ik dus met mijn vorige opmerking.

Het zal toch niet zo zijn dat dit alleen optreedt op XGS.PON verbindingen, net als het eerdere issue met de VPN verbindingen die niet werkte op XGS.PON.

Ik hoop dat @Raymondt meeleest en hier toch ook zijn licht nog eens over wil laten schijnen.


Jazeker lees ik nog mee, ik heb alleen op dit moment nog niet de antwoorden waar we naar op zoek zijn. Ik ben wel bezig om e.e.a. te achterhalen, dus ik kom er zeker nog even op terug.


@Hemant ik ben nog eens aan het nadenken, je geeft aan geen fysieke router te hebben, maar esx te gebruiken. Die zou in theorie ook dingen tegen kunnen houden. Wat gebeurt er als je de experiabox van kpn aansluit en een server hierop aansluit? komt je verkeer dan wel binnen als je de poort forward in de experiabox?


Azure blokkeert standaard poort 25, zie https://docs.microsoft.com/en-us/azure/virtual-network/troubleshoot-outbound-smtp-connectivity

 

Alleen als je een Enterprise subscription hebt kan je het gebruiken na vrijgeven, voor andere geldt:

The Azure platform will block outbound SMTP connections on TCP port 25 for deployed VMs. This is to ensure better security for Microsoft partners and customers, protect Microsoft’s Azure platform, and conform to industry standards.


Hoi Raymondt,

 

Omdat uit te sluiten heb als test een TP link aangesloten en de port forward gedaan op 25 en 465.

Die geeft hetzelfde probleem. 465 werkt en 25 komt niet door.

 

Ik kan helaas niet even de KPN Box 12 aansluiten, omdat mijn IP reeks binnen een anders netwerk ligt, en ik een eigen DHCP server heb en interne servers hebben allemaal vast IP’s. dus even omzetten is niet makkelijk.

Hemant


Aanvulled,

 

Als de ESX iets zou blokken dan zou hij dat ook intern moeten doen aangezien mijn Exchange Server op die zelfde box draait.

 

Ik heb ook als test mijn synology SSH op port 25 gezet en dat werkt intern prima, maar extern ook niet met OPnsense maar ook niet met TPlink (draait orginele firmware).

 

Hemant


Ik heb trouwens een:

GMC-TK01-XGS2110-EU-1 als je er wat aan hebt.

 

Hemant


Als de ESX iets zou blokken dan zou hij dat ook intern moeten doen aangezien mijn Exchange Server op die zelfde box draait.

Hoi, die conclusie kan ik mij eerlijk gezegd nog niet in vinden, maar dat doet er voor nu ook even niet toe. Heb je ook de opmerking van @GeSp gezien?

Verder: zou je je gegevens misschien in willen vullen in je forumprofiel ? Als je dat doet in een van de velden gemarkeerd met ‘Privé’ dan kunnen alleen moderators de info zien. Ik wil graag zelf ook even wat tests doen om te kijken wat ik kan zien. En dan tevens de vraag om de port forward op poort 25 even te laten staan, en er iets achter te zetten wat ook op die poort luistert, zodat ik vanaf verschillende verbindingen eens kan testen of ik verbinding krijg.


Ok Ik heb nog wat testen gedaan om er zeker van te zijn.

 

KPN Box 12 er aan gehangen en nogeens getest met een apart netwerkt.

Vanuit Azure werk port 25 niet

Vanauit 4G werkt port 25 ook niet.

 

Ik heb het toen even andersom gedaan; port 25 open gezet op Azure.

Vervolgens Telnet gedaan vanaf thuis dat werkte

Telnet gedaan vanaf andere Azure host werkte niet

4G getest dat wrkte ook niet.

 

Blijkt dus dat mijn provider (Vodafone) dus op 4g ook port 25 blocked op outbound.

 

Heb even een online Telnet tool gepakt en die dus naar huis laten connecten, en ja hoor, ik zie netjes in de firewall een entry met port 25 en krijg een rely van mijn server op een remote IP address.

Ik was een beetje op verkeerder spoor gebracht toen Azure maar ook 4G niet werkten.

 

Conclusie, port 25  inderdaad open, maar helaas niet voor iedereen bereikbaar, weer wat geleerd.

Bedankt allemaal, en sorry voor het wantrouwen

 

Hemant

 

 

 

 

 

 


Goed dat je de plek gevonden hebt waar poort 25 geblokkeerd wordt en dat je dat met ons hebt gedeeld.

Dit is waardevolle informatie voor anderen die ook tegen dit probleem aanlopen.


Goed om te zien dat het toch boven water gekomen is! Zoals wjb al aangeeft is dit erg waardevolle informatie.