Port-forwarding op een Ubiquiti UDM-SE

Sinna · 3 weken geleden

Ik ervaar een zeer vreemd fenomeen bij het instellen van port-forwarding op een Ubiquiti UDM-SE waarbij er gericht beperkt wordt welke externe IP-adressen er mogen verbinden.
Doel is om een Remote Desktop voor een beperkt aantal vaste IP-adressen beschikbaar te maken zonder dat hiervoor eerst een VPN opgezet moet worden.

Op een ZyXEL-omgeving heb ik dit al jaar en dag werkende, maar nu ik overstap naar de Ubiquiti UDM-SE, ervaar ik problemen:

De Remote Desktop lanceren vanaf een Scarlet-lijn werkt.
De Remote Desktop lanceren vanaf een Telenet-lijn (met fixed IP) werkt niet: een WireShark leert mij dat de verbinding meteen dichtgegooid wordt. In een tcpdump op de UDM zelf zie ik zelfs geen enkel packet voorbijkomen.
De leverancier waarvoor deze Remote Desktop-verbinding opgezet wordt geeft aan dat via hun VPN op kantoor de verbinding werkt, maar vanaf een Telenet-lijn via hun VPN dan weer niet.
De Remote Desktop lanceren vanaf een edpnet-lijn (met fixed IP) werkt ook niet, met een dynamisch IP dan weer wél... WEIRD!

Ik heb op de UDM een (naar mijn aanvoelen) eenvoudige port-forward ingesteld waarbij de vereiste firewall-regels automatisch mee aangemaakt worden.
Geen idee waar het dus misloopt en wat het verschil is tussen een Scarlet-lijn, die ene achter de VPN en die andere achter dezelfde VPN.
Een zoektocht naar online bronnen maakt mij helaas niet wijzer. Misschien zoek ik op de verkeerde termen, of is het weer één of andere stomme bug waar ik tegen aanloop.

silentkiller · 3 weken geleden

Hoe gebeurt de lookup van het UDM adres?
Is dat een DNS entry of connecteert men rechtstreeks op IP?
‘T heeft toch niets te maken met clients die op IPv6 proberen connecteren?

Sinna · 3 weken geleden

Om iets lower profile te blijven wordt er verbonden op IPv4-adres. IPv6 is nog niet uitgerold.

Wel een interessante denkpiste, maar hier dus niet van toepassing.

silentkiller · 3 weken geleden

Een port forwarding is een port forwarding, dat zou voor iedereen moeten werken.
Geen idee hoe uitgebreid de port forwarding opties zijn in de UDM, maar volgende moet natuurlijk goed staan:
-SRC adres voor de NATing (in simpelere configuraties is dat voor iedereen)
-Firewall op de poort, alle SRC afresszn geconfigureerd?

Dan zou op de router alles moeten werken.

Als je niet connecteert op IP adres, check dan zeker voor alle partijen of de resolving lukt

DarkV · 3 weken geleden

Sinna schreef: 3 weken geleden Op een ZyXEL-omgeving heb ik dit al jaar en dag werkende, maar nu ik overstap naar de Ubiquiti UDM-SE, ervaar ik problemen:

Als het via de ZyXEL wel prima werkt dan kan het natuurlijk niet aan de provider liggen want dat was m'n eerste idee.

Voor het overige zou ik nochtans zeggen dat als de RDP werkt voor één provider dat het dan ook voor een andere moet werken... voor de UDM maakt het geen verschil wat de source is.

Geen probleem met TCP vs UDP, juiste WAN poort/IP-adres, Src als ANY of Limited staan, ... ?

Sinna · 2 weken geleden

De ZyXEL zit op een Telenet-lijn, de UDM op een Belnet-lijn (hoger onderwijs).
Ik heb de port forwarding als volgt ingesteld:

WAN Interface: WAN1
WAN IP Address: 193.190.x.y
WAN Port: 3389
From: Limited = 84.199.z.a
Forward IP Address: 192.168.b.c, het IP-adres van de server waarmee verbonden moet worden
Forward Port: 3389
Protocol: TCP (only)

Ik blijf het uitermate vreemd vinden. Bij Scarlet wisselt mijn extern IP vrij vaak, maar zelfs in een totaal andere range blijft die gewoon werken.
In de firewall worden automatisch de overeenkomstige rules aangemaakt.

Unifi GPT wees mij op het volgende, maar ik kan mij deze beperking niet voorstellen:

Unifi GPT schreef: In Ubiquiti UniFi, it is not possible to have multiple port forwarding rules for the same destination IP/port combination.
A given WAN port can only be forwarded to a single device or service within your network.
If multiple rules are configured for the same WAN port, it will cause conflicts, and only one rule (often seemingly random) will work.

Ik lees dit als volgt: Het is niet mogelijk om meerdere port-forwardings te hebben voor dezelfde IP/poort-combinatie.
Dat zou betekenen dat er maar één regel zou mogen zijn per combinatie IP/poort, los van vanwaar de verbinding opgezet wordt.

DarkV · 2 weken geleden

Je spreekt maar van één forward rule (of heb je er meerdere naar 192.168.b.c:3389 ?) dus dat lijkt me niet het probleem te zijn.

Troubleshooting start altijd zo basic mogelijk dus haal die "from limited" er eens af en stel als protocol eens UDP/TCP in.

Verder is de ultieme test natuurlijk een wireshark vóór je UDM om te kijken of het wel binnen komt... uiteindelijk vergelijk je nu appelen met peren (Telenet lijn versus Belnet lijn).

Sinna · 2 weken geleden

Een WireShark vóór mijn UDM is niet mogelijk: de glasvezelverbinding komt op de UDM aan.

Als ik een WireShark lanceer op mijn testtoestel, dan krijg ik meteen een TCP RST van de UDM terug voor IP-adressen waar het niet lukt. Ik zie de verbindingspoging niet eens verschijnen in een tcpdump op de UDM zelf. Er zit dus blijkbaar nog iets voor...

Dezelfde test, maar dan via een Telenet-lijn (met dynamisch IP) op dezelfde UDM geeft hetzelfde resultaat als via de Belnet-lijn. Er loopt dus iets mis op de UDM zelf, maar wat? Geen idee.

Ik lees dat het soms volstaat om de huidige configuratie te backuppen, de UDM te resetten en de backup daarna terug te zetten, maar die UDM draait in productie en kan ik dus niet zomaar even onderbreken.

Voor de volledigheid: ik heb meerdere forwards (voor 4 source-IPs) staan waarvan er uiteindelijk twee behouden moeten worden.

Joe de Mannen · 2 weken geleden

Het is toch geen firewall rule die de verbinding verbied ?

J.

Sinna · 2 weken geleden

Zou niet mogen. Er staan geen Block-regels boven de Allow-regels (voor deze combinatie Source-Destination-zone).

silentkiller · 2 weken geleden

Nogmaals: Connecteer je op IP adres of gebeurt er iets van resolving?

Daarnaast: heb je per source IP een NAT lijn in de UDM? En ook een algemen lijn? Bestaat er binnen UDM iets als ‘als je een match hebt op deze lijn, zoek niet verder in verdere rules’?

Geef ons eens wat meer info over hoe exact alles is geconfigureerd/geresolved, anders is het gissen

Sinna · 2 weken geleden

Sorry voor de onduidelijkheid: er wordt op IP-adres verbonden op poort 3389 (standaard RDP).
Op de UDM zelf is het ook allemaal IPv4-gebaseerd, geen network objects oid.

Ik heb enkel een Port Forwarding-regel per source-IP ingesteld, geen NAT (omdat ik dat voor die Scarlet-lijn niet nodig lijk te hebben).
Tijdens het instellen van die Port Forwarding wordt er automatisch een firewall-regel aangemaakt vanaf het IP-adres van de client die mag verbinden naar het interne IP-adres van de server waarmee verbonden moet worden. Die regel staat hoger in de lijst dan de Block-regels.

Het vreemdste blijft die TCP RST als ik probeer te verbinden vanaf een IP-adres waar het niet mee lukt: de UDM lijkt de verbinding actief te weigeren, maar geen idee waarom. Als er geen rule ingesteld staat, dan wordt de verbinding niet actief dichtgegooid voor de Scarlet-lijn en zie ik mstsc TCP Retransmissions doen.

Ik probeer te achterhalen waar het verschil zit, maar 'k vind het dus niet (anders had ik hier geen draadje geopend).

silentkiller · 2 weken geleden

Cfr de unify GPT:

Code: Selecteer alles

In Ubiquiti UniFi, it is not possible to have multiple port forwarding rules for the same destination IP/port combination.

Kan je eens proberen om 1 port forward rule te maken:
Src any , target je interne server ip:3389

Vervolgens in de firewall rules de automatisch gegenereerde eruit en een regel per toegelaten client

Je hebt dan 1 port forwarding regel (is eigenlijk ool NAT, vandaar dat ik het zo noemde) en meerdere firewall regels.

Toegevoegd na 1 minuut 31 seconden:
Of alternatief (geen idee of dat mogelijk is): 1 port forwarding regel met als source alle toegelaten adressen

Sinna · 2 weken geleden

Da's 't idiote met die UDM: het ene moment kan je verschillende IP-adressen, -ranges of network objects gebruiken, het andere moment is het puur IP.
De automatisch genereerde rules staan op slot en kan je niet zomaar verwijderen.
Toch bedankt voor het meedenken! Als ik de oorzaak vind, dan zal ik het hier zeker posten.

Joe de Mannen · 2 weken geleden

Ik geloof dat je in Settings>System kan kiezen voor legaly interface.
Als ik me niet vergis kan je dan meer met firewall rules.

J.

DarkV · 2 weken geleden

Sinna schreef: 2 weken geleden het ene moment kan je verschillende IP-adressen, -ranges of network objects gebruiken

Om je source te limiteren is het louter; a valid IPv4 address, subnet or range

Meerdere enkelvoudige IP-adressen is dus geen optie.

Sinna · 2 weken geleden

Oorzaak grotendeels gevonden: de firewall achter de IP-adressen waarvan ik testte (op kantoor) liet geen uitgaand RDP-verkeer toe...

Nu nog achterhalen waarom de leverancier niet verbonden geraakt als de medewerker van thuis uit via de VPN probeert te verbinden...
Ik vermoed een split-VPN, maar heb hiervoor nog een vraag openstaan bij de leverancier zelf.

Update: 't is dus inderdaad een split-VPN waarbij de IP-adressen nog niet opgevoerd zijn. Het feit dat er naast een nieuwe RDP ook op een IP-adres in een compleet ander IP-bereik verbonden moest worden zorgde dus voor onnodige complexiteit.

Case closed, oef.