UDM SE firewall gehannes na modem vervanging en bridge modus activatie

[MinddiggerNL]

Weet iemand hoe ik de firewall in mijn UDM SE een schop geef?

Ik heb sinds afgelopen weekend een nieuw Ubee modem van Ziggo, nadat ik "geklaagd" had dat ik de per juli opgehoogde snelheid niet meer haalde met mijn oude Cisco modem. Door vervanging van het modem haal ik nu wél de geadverteerde snelheden, maar verder kan ik helaas nog niet echt spreken over vooruitgang...

Na plaatsing van het Ubee modem kwam ik er nl. achter dat hairpin NAT niet meer werkte, waardoor ik mijn NAS vanuit het LAN niet meer kon benaderen via het WAN adres / public DNS name met specifiek poortnummer. Ik begreep van de behulpzame mensen op de Ziggo Community dat het Ubee modem geen hairpin NAT ondersteunt i.t.t. mijn oude Cisco modem. Hmm, ok, minder, dus vervolgens het modem dan maar in bridge modus gezet zodat de UDM SE de hairpin NAT zou overnemen. Helaas...werkte nog steeds niet!?
Zoeken, zoeken, zoeken... de hints op deze pagina hielpen helaas niet. Vervolgens dit topic gevonden en n.a.v. de hint van UI-Marcus m.b.t. inter-VLAN blocking mijn eerder aangemaakte firewall rule t.b.v. het blokkeren van inter-VLAN verkeer uitgeschakeld. Et voila, hairpin NAT werkte weer!
Die firewall rule zag er ongeveer zo uit als scenario 2 op deze pagina. Dat heeft altijd perfect gewerkt en ervoor gezorgd dat clients in verschillende VLAN's niet bij elkaar konden komen. Nu doe ik weliswaar momenteel niet veel met verschillende VLAN's, maar ik wil wel de mogelijkheid behouden om dit zo te kunnen gebruiken. Nu de hairpin NAT is geoffload van het modem naar de UDM SE, kan dit niet meer in combinatie met inter-VLAN blocking werken? Weet iemand hoe dat zit?

Volgende issue...mijn NAS was inmiddels binnen het LAN weer bereikbaar o.b.v. WAN adres / public DNS name met specifiek poortnummer, maar extern (via bijv. 4G, in elk geval buiten mijn LAN) nog steeds niet!? Erg onpraktisch aangezien ik uiteraard dezelfde URL in sync apps als DS Note, Enpass e.d. wil kunnen gebruiken, ongeacht of ik thuis ben of niet.
Van alles geprobeerd en gecontroleerd middels port scans en firewall logging (die ik laat wegschrijven naar mijn NAS). Alle bestaande én nieuwe (test) port forwarding regels werken, behalve die waarmee ik verwijs naar het poortnummer van mijn NAS: 6367. Als ik een test regel aanmaak met 18579 extern naar 6367 intern, werkt het gewoon. De UDM SE laat het verkeer dus door en mijn NAS laat het verkeer toe. Enkel wanneer ik extern poortnummer 6367 gebruik, dan werkt het niet!?
In de logging zie ik ook géén hit wanneer ik mijn NAS van extern op poort 6367 probeer te bereiken, wél als ik dat van intern doe. Als ik hem via extern poortnummer 18579 probeer te bereiken, zie ik hits zowel vanuit intern als extern.

Ik snap er geen jota meer van, waarom echt specifiek die ene regel c.q. dat ene poortnummer gewoon níet doorkomt. Een port scan blijft ook aangeven "closed". Het enige dat voor de UDM SE staat, is het modem en dat staat zoals gezegd in bridge modus. De UDM SE heeft dan ook mijn Ziggo IP op de WAN interface.

IPS heb ik overigens ook aan staan incl. geo blocking. Het was de laatste tijd erg stil qua intrusion detections, maar nu ik door de modem vervanging een nieuw WAN IP heb, krijg ik weer diverse meldingen. Overigens niet enkel van inkomend verkeer, maar óók van uitgaand verkeer. Mijn rsync backup vanuit de NAS naar Hidrive van Strato werkte niet meer omdat de UDM SE firewall het verkeer zag als "possible information leak". Hoezo dat dan ineens, dat verkeer ging voorheen ook gewoon naar buiten!? Ik heb het destination IP maar op de whitelist gezet en nu werkt het weer.

Met het oude modem in router modus en de UDM SE in de DMZ werkte alles perfect. Nu volg ik netjes het algemene advies op om het modem in bridge modus te zetten en loop ik tegen issues aan

Ik kan mij voorstellen dat voorgaande wat lastig te volgen is, maar ik hoop toch dat iemand een suggestie heeft wat te doen... kan ik de firewall eens via SSH herstarten o.i.d.?

N.B. het valt mij ook op dat automatisch aangemaakte firewall rules n.a.v. toegevoegde port forwaring rules getoond blijven, ook na verwijderen van de port forwarding rule, tot de interface is herladen door bijv. te switchen tussen de legacy en new interface.

 

[Eddie the Eagle]

Mijn eerste (spontane) ingeving op je (uitgebreide) topic is......VPN ipv al die port forwards. Ik moet eerlijk zeggen dat ik de nodige port forwards heb gehad met de UDM-SE en er nooit issues mee heb gehad. Toch blijven het open poorten die ik allemaal de nek om heb kunnen draaien met VPN (nu dan Teleport, daarvoor L2TP maar vele andere mogelijkheden).

Nee, toch nog 1 port forward actief.....de Minecraft server van mijn zoon maar ook die werkt prima. Die vrienden van `m komen niet op de VPN natuurlijk.

edit: Ziggo Ubee modem in bridge (waarom zou je dat anders willen)

 

[MinddiggerNL]

Hi @Eddie the Eagle, dank voor je snelle reactie op mijn inderdaad uitgebreide verhaal

Ben het op zich wel met je eens dat een VPN oplossing veiliger is dan port forwards. Daar heb ik ook nog even aan zitten denken afgelopen dagen, maar daar wil ik nu niet toe verplicht worden. Het heeft eerder gewoon gewerkt en werkt op één poortnummer na nog steeds...ik kan uiteraard een ander poortnummer gebruiken, dan is het opgelost, alhoewel ik dat als een zwaktebod en workaround beschouw, niet als echte oplossing (ik weet dan immers nog steeds niet wat de oorzaak was).

Heb nu wel L2TP VPN naar mijn Synology NAS, maar die gebruik ik slechts in een enkel scenario. Idealiter laat ik mijn telefoon buitenshuis automatisch een VPN opzetten (waarschijnlijk dan beter naar de UDM SE i.p.v. de NAS), zodat die port forwards niet meer nodig zijn, maar heb nog geen tijd gehad om goed uit te zoeken hoe dat precies moet. Zelfde geldt voor Teleport; even kort naar gekeken, klapperde continu (nog met het oude modem) en dus weer uitgeschakeld.
Bovendien: ik krijg het mijn (schoon)ouders nog moeilijk uitgelegd hoe ze eerst een VPN verbinding opzetten voordat ze aan mijn fotoalbums komen, dus ook om die reden blijf ik vooralsnog op port forwarding hangen...

Wat betreft de bridge modus op het Ubee modem: bij dit modem wil je idd niet anders, omdat die hairpin NAT niet ondersteund wordt, maar bij het Cisco modem heb ik nooit concrete aanleiding gevoeld om af te stappen van router modus met DMZ en eigen router er achter. Werkte altijd zonder problemen. Heb dat Cisco modem ooit door Ziggo in bridge modus laten zetten en dat resulteerde in een snelheid van amper 3Mbps. Daarna kon ik weer 3 dagen wachten voor ze het terug hadden gezet naar router modus. Sindsdien was ik dus wat huiverig om dit aan te laten passen, maar bij het Ubee modem was het "realtime" gebeurd en werkt het gelukkig wel naar behoren

 

[Eddie the Eagle]

alhoewel ik dat als een zwaktebod en workaround beschouw, niet als echte oplossing (ik weet dan immers nog steeds niet wat de oorzaak was).

ben ik met je eens, het moet gewoon werken; ik heb het nooit getest met de Synology via port forward; alleen VPN (en dan heb je Quickconnect en DDNS nog van Syno zelf).

Zelfde geldt voor Teleport; even kort naar gekeken, klapperde continu (nog met het oude modem) en dus weer uitgeschakeld.

Werkt hier echt heel stabiel; mijn kinderen gebruiken het om in de schoolpauze naar Rick & Morty te kijken

Bovendien: ik krijg het mijn (schoon)ouders nog moeilijk uitgelegd hoe ze eerst een VPN verbinding opzetten voordat ze aan mijn fotoalbums komen, dus ook om die reden blijf ik vooralsnog op port forwarding hangen...

idd maar die port forward moet je ook instellen bij de client

Werkte altijd zonder problemen. Heb dat Cisco modem ooit door Ziggo in bridge modus laten zetten en dat resulteerde in een snelheid van amper 3Mbps. Daarna kon ik weer 3 dagen wachten voor ze het terug hadden gezet naar router modus. Sindsdien was ik dus wat huiverig om dit aan te laten passen, maar bij het Ubee modem was het "realtime" gebeurd en werkt het gelukkig wel naar behoren

Ik ben ook tevreden over de Ubee; een verademing tov de Connect Box

 

[MinddiggerNL]

ben ik met je eens, het moet gewoon werken; ik heb het nooit getest met de Synology via port forward; alleen VPN (en dan heb je Quickconnect en DDNS nog van Syno zelf).

Port forwarding is super simpel. En het heeft tot nu toe altijd naar behoren gewerkt met alle modem/router combinaties die ik heb gehad. Het werkt nu ook, alleen uitgerekend niet met de belangrijkste poort

Werkt hier echt heel stabiel; mijn kinderen gebruiken het om in de schoolpauze naar Rick & Morty te kijken

Ik heb Teleport zojuist nog maar eens bekeken en snap nu waarom het eerder klapperde: https://community.ui.com/questions/...2#answer/1fb59622-5256-4467-a3c9-d42eff61fbc5

Zolang dat issue niet is opgelost, heb ik er weinig aan want op mijn privé telefoon heb ik een KPN abbo en dat gaat over IPv6, waar Teleport dus nog niet stabiel mee werkt

idd maar die port forward moet je ook instellen bij de client

Ik vul 1x een poortnummer achter de hostname in de foto app in en voila, ze kunnen connecten met de NAS. Eerst een VPN connectie opzetten vinden ze lastig, al hoewel ik moet toegeven dat het met zo'n Teleport oplossing wel simpel werkt. Alleen werkt dat volgens mij niet op een Windows computer, enkel op mobiel, toch?

Ik ben ook tevreden over de Ubee; een verademing tov de Connect Box

ConnectBox heb ik gelukkig nooit gehad. Vond het wel netjes dat ik via de Ziggo Community gelijk kon kiezen voor het Ubee modem, dat als stabieler alternatief werd geadviseerd. Via Ziggo zelf kreeg ik die keuze niet.


Maar goed, we dwalen lichtelijk af van mijn vraag. Hopelijk heeft nog iemand anders een suggestie

 

[rgarretsen]

Neem aan dat je firewall rules gechecked hebt en niet de 1 de ander blokkeerd.

Staat de allow Nas port regel boven andere regels die traffic droppen (volgorde is namelijk belangrijk)

 

[MinddiggerNL]

Neem aan dat je firewall rules gechecked hebt en niet de 1 de ander blokkeerd.

Staat de allow Nas port regel boven andere regels die traffic droppen (volgorde is namelijk belangrijk)

Ik heb uiteraard de firewall rules nagekeken en zover ik kan zien, zou niets dat verkeer moeten blokkeren. Dat is nu juist het punt.

Als ik in de nieuwe interface naar Firewall & Security ga, dan:
- Staat Country restriction op block voor beide richtingen voor verkeer vanuit 6 landen (Rusland, Oekraïne, Belarus, Iran, China, Noord-Korea)

- Staat Threat Management op Detect and Block met sensitivy level op High

- Dark web blocker en malicious website blocker staan beiden op Enable

- Bij de firewall rules staan 90 rules waarvan 78 bij Internet.
Rule index 2000 t/m 2032 heeft allemaal betrekking op Internet In, verkeer wordt gedropped i.v.m. IPS block/deny.
Daarna volgen regels 3001 t/m 3012 die uitgegrijsd zijn en ik dus niet kan wijzigen; dat zijn de port forwarding regels en die accepten Internet In verkeer.
Daarna weer regels 2000 t/m 2032 om Internet Out verkeer te droppen vanwege IPS
Tot slot regels 3001 en 3002 Accept All Internet local Allow Established /Related sessions en Drop Invalid State

- Daaronder de port forwarding regels met logging actief. Zo kan ik ook in de syslog server op mijn NAS zien wanneer zo'n rule wordt gehit.

M.i. allemaal niks vreemds. Een herstart van de UDM SE heeft niet geholpen.

 

[MinddiggerNL]

Nog los van de vraag waarom die specifieke port forwarding niet werkt, ben ik ook benieuwd of iemand weet waarom hairpin NAT i.c.m. inter-VLAN blocking niet (b)lijkt te werken op een UDM SE.

 

[MinddiggerNL]

Heeft nog iemand een suggestie?

Zoals gezegd kom ik met de hints van deze pagina niet echt verder, alhoewel...ik vond dit topic nog op GoT. Lijkt toch verdacht veel op het issue dat ik ervaar. Alleen krijg ik het dus niet via de classic interface opgelost helaas.

Ik heb SSH op mijn UDM SE geactiveerd en als ik tcpdump -n -i eth8 tcp port 6367 doe, dan wordt er niks getoond. Als ik het poortnummer wijzig naar 5006 (WebDAV) en via de Enpass app op mijn iPhone (via 4G) een sync trigger, dan zie ik gelijk verkeer binnen komen. Idem wanneer ik een nieuwe port forwarding regel aanmaak met poort 55555 op de WAN en 6367 op de LAN kant; als ik het commando met poort 55555 uitvoer en mijn NAS via public DNS name met dat poortnummer aanroep, zie ik verkeer binnen komen en wordt mijn NAS login getoond.

Alleen als ik poort 6367 op de WAN kant gebruik, gebeurt er niets. Zoals ook al eerder bleek uit de logging die ik wegschrijf naar mijn NAS.
Ik heb de portforwarding rule verwijderd en opnieuw aangemaakt, maar zonder resultaat.

Volgens voornoemde pagina van Ubiquiti zou het verkeer in dit geval de WAN poort van de UDM niet bereiken en dus elders "upstream" tegengehouden moeten worden. Dat kan m.i. niet want het enige wat ervoor staat is het Ziggo modem in bridge modus.

• Heeft iemand nog een idee wat het kan veroorzaken dat een specifiek poortnummer NIET bereikbaar is van buitenaf?
  Het moet m.i. gewoon werken om zowel intern als extern eenzelfde poortnummer te gebruiken.
• Heeft iemand een idee waarom hairpin NAT enkel werkt als inter-VLAN verkeer wordt toegestaan?

 

[Hofstede]

Heb je al eens andere poorten in het 6xxx bereik geprobeerd? Bijvoorbeeld 6368?
Of is het misschien een bereik van poorten in die range dat niet werkt. Dat zou je moeten bepalen.
Kan zomaar zijn dat het Ziggo modem bepaalde bereiken blokkeert, ondanks dat die in bridge mode staat.

 

[MinddiggerNL]

Heb je al eens andere poorten in het 6xxx bereik geprobeerd? Bijvoorbeeld 6368?
Of is het misschien een bereik van poorten in die range dat niet werkt. Dat zou je moeten bepalen.
Kan zomaar zijn dat het Ziggo modem bepaalde bereiken blokkeert, ondanks dat die in bridge mode staat.

Goeie suggestie, en waarschijnlijk niet aan gedacht omdat ie zo voor de hand liggend was

Ik heb de bestaande port forwarding rule aangepast en de WAN poort op 6368 gezet, LAN kant op 6367 laten staan. En het werkt gewoon: poort scan geeft aan dat de poort open staat en NAS is via 4G bereikbaar.
Intern is de NAS vanwege hairpin NAT nu ook via poort 6368 bereikbaar.

Kortom: dit werkt zoals verwacht. Enkel niet met poort 6367
De reden dat ik hier zo halsstarrig aan vasthoud, is dat het mijn postcode is, dus lekker makkelijk te onthouden (qua security voegt het weinig toe t.o.v. de standaard poort, behalve dat ie buiten scope van standaard scanners valt).

 

[Hofstede]

Wat mij nu zo te binnen schiet. Had je toevallig eerst in het Ziggo modem al die portforwarding naar poort 6367 geactiveerd voordat je hem uiteindelijk in bridge mode liet zetten vanwege de hairpin issue? Mogelijk is dan die portforwarding in het Ziggo modem nog steeds actief, ondanks dat die inmiddels in bridge mode is gezet. En komt daardoor het verkeer op die poort niet meer aan op de WAN poort van de UDM SE omdat de Ziggo modem hem naar een ander IP doorstuurt.
Ik ken de Ziggo modems verder niet, maar mogelijk kun je hem een keer resetten naar fabrieksinstellingen?

 

[MinddiggerNL]

Zoiets moet het inderdaad wel zijn. Een simpele herstart van het modem helpt niet. Een reset kan ik via de user interface uitvoeren, maar ik weet niet of ze daar bij Ziggo vrolijk van worden. Heb geen idee of ie zijn config dan weer juist ophaalt...

Ik kan het mij niet helemaal meer herinneren, maar vermoed dat ik die port forwarding wél heb ingesteld voorafgaand aan het omzetten naar bridge modus. Zonder port forward was de NAS überhaupt niet bereikbaar, intern en extern, ook al stond de UDM SE in de DMZ van het modem. Dus toen heb ik die regel volgens mij wel aangemaakt, waarna het van extern werkte. Intern niet vanwege ontbrekende hairpin NAT functionaliteit.

Ik vrees dat die regel niet is verwijderd voordat het modem in bridge modus werd gezet. Leek mij normaliter ook niet nodig. Je zou verwachten dat het modem in bridge modus überhaupt niet meer naar port forwarding regels kijkt, maar het is bijna té toevallig dat uitgerekend deze ene poort niet werkt. Volgens mij had ik ook nog geen andere forwarding regels ingesteld.

Zal maar weer eens contact opnemen met de Ziggo Community of Ziggo klantenservice. Modem terug in router modus, forwarding regel eruit halen en terug in bridge modus. Gaat lekker zo...

 

[Hofstede]

Ziggo adviseert zelf regelmatig een reset naar fabrieksinstellingen m.b.v. de reset knop als iets niet werkt of je de inlog kwijt bent.
Moet dus gewoon kunnen.
Zie: https://www.ziggo.nl/klantenservice/internet-wifi/modem-inloggen#/

 

[edwin2019]

Goeie suggestie, en waarschijnlijk niet aan gedacht omdat ie zo voor de hand liggend was

Ik heb de bestaande port forwarding rule aangepast en de WAN poort op 6368 gezet, LAN kant op 6367 laten staan. En het werkt gewoon: poort scan geeft aan dat de poort open staat en NAS is via 4G bereikbaar.
Intern is de NAS vanwege hairpin NAT nu ook via poort 6368 bereikbaar.

Kortom: dit werkt zoals verwacht. Enkel niet met poort 6367
De reden dat ik hier zo halsstarrig aan vasthoud, is dat het mijn postcode is, dus lekker makkelijk te onthouden (qua security voegt het weinig toe t.o.v. de standaard poort, behalve dat ie buiten scope van standaard scanners valt).

Waarom geen vpn gebruiken. Waar geen gat zit kan geen ongedierte doorheen

 

[Hofstede]

Dat is al eerder gesuggereerd in dit draadje, maar niet de vraag.

 

[Eddie the Eagle]

Een reset kan ik via de user interface uitvoeren, maar ik weet niet of ze daar bij Ziggo vrolijk van worden. Heb geen idee of ie zijn config dan weer juist ophaalt...

Jawel doet ie; je modem komt ook weer in bridge mode terug; het juiste profiel wordt opgehaald

Zal maar weer eens contact opnemen met de Ziggo Community of Ziggo klantenservice. Modem terug in router modus, forwarding regel eruit halen en terug in bridge modus. Gaat lekker zo...

Ik zou eerst dus die reset doen en kijken of het dan opgelost is

 

[dbw]

Ik zou eerst dus die reset doen en kijken of het dan opgelost is

Dat zou ik ook doen. Kan nul kwaad.

 

[MinddiggerNL]

Zucht...factory reset gedaan en voila, issue opgelost!
Had ik dat maar gelijk gedaan, was sneller dan het hele epistel hier uitschrijven (en alles testen)

Dikke bug wat mij betreft, want m.i. hoort het modem dergelijke instellingen niet te onthouden als de operating modus wordt gewijzigd.

Maar goed, wat de suggestie t.a.v. VPN gebruik betreft: ik heb in elk geval nog eens naar Teleport gekeken en dat werkend gekregen (eerder issue bleek te maken te hebben met IPv6 adres via 4G). Mooie oplossing. Misschien dat ik die ook op de iPad van mijn (schoon)ouders activeer, dan is er geen noodzaak meer om poorten open te zetten.
Tevens door dit gebeuren weer wat geleerd t.a.v. troubleshooting via de commandline en syslog server...was het toch nog ergens goed voor.

Dank allemaal voor het meedenken!



N.B. Enige dat mij nog niet duidelijk is, is waarom hairpin NAT op de UDM SE niet werkt i.c.m. inter-VLAN blocking rules. Iemand daar nog een idee over?