Meerdere externe poorten naar zelfde interne poort

[TtomtomT]

Mijn vraag
Ik probeer op mijn Ziggo ConnectBox twee regels te maken als volgt:
1. NAS IP - interne poort 450 - externe poort 443
2. NAS IP - interne poort 450 - externe poort 8448

Nu krijg ik, als ik de tweede regel probeer op te slaan, de melding ''Deze regel bestaat al" bij de interne poort. Het klopt dat er al een regel is waarbij deze interne poort gebruikt wordt (regel 1), maar het lijkt me dat dit gewoon hoort te kunnen. De modem hoeft alleen bij extern->intern verkeer de port forwarding regels te volgen en in deze situatie is er geen verwarring over waar het verkeer heen moet, zoals dat wel zou zijn als ik de externe poort naar twee verschillende interne poorten zou laten leiden.

Zie ik hier wat over het hoofd of is dit gewoon een fout in de ConnectBox?

Relevante software en hardware die ik gebruik
Modem is ConnectBox van Ziggo.

Wat ik al gevonden of geprobeerd heb
Heb vrij weinig relevante info over vergelijkbare problemen kunnen vinden, vooral veel tutorials over hoe port forwarding werkt dus ik hoop dat ik niet gewoon iets over het hoofd zie

Ik heb nagedacht over beide externe poorten in een enkele regel te verwerken, maar je kan alleen ranges aangeven en dan zou 450 t/m 8448 open moeten staan.

Alvast bedankt!

[Frogmen]

Maar waarom zou je dit willen het slaat nergens op en het is ook vreemd voor de NAS. Ik denk dat je ergens in config iets vreemds hebt zitten en poorten hebt gewijzigd.

[TtomtomT]

Ik probeer een Matrix server op te zetten en volg de documentatie:
https://matrix.org/faq/#w...obal-matrix-federation%3F
Het verhaal daar vind ik niet heel duidelijk, maar denk dit er uit op te maken.

Daarnaast wordt het op het Unraid forum ook genoemd:
https://forums.unraid.net...i-video-conference-setup/

Firewall Setup:

You'll need the following ports forwarded from you WAN to you Unraid server:
LetsEncrypt: WAN TCP 80 -> LAN 180 , WAN TCP 443 -> LAN 1443, WAN TCP 8448 -> LAN 1443, all on your Unraid server IP

- 80: Used by LetsEncrypt to validate your certificate signing request -- this can be disabled after setup, then only enabled when you need to renew a certificate.

- 443: LetsEncrypt proxy for encrypted web, duh

- 8448: Matrix Integrations port for enabling plugins. Also proxied via LetsEncrypt. Make sure this points to 1443, not 8443!

Poort 1443 is in mijn geval poort 450.

[ Voor 5% gewijzigd door TtomtomT op 21-08-2021 15:22 . Reden: miste eerste regels van de quote ]

[Brahiewahiewa]

TtomtomT schreef op zaterdag 21 augustus 2021 @ 15:21:
Ik probeer een Matrix server op te zetten en volg de documentatie:
https://matrix.org/faq/#w...obal-matrix-federation%3F
Het verhaal daar vind ik niet heel duidelijk, maar denk dit er uit op te maken.

Daarnaast wordt het op het Unraid forum ook genoemd:
https://forums.unraid.net...i-video-conference-setup/


[...]

Poort 1443 is in mijn geval poort 450.

Kennelijk heeft Ziggo besloten dat je niet twee externe poorten naar dezelfde interne poort kunt forwarden.
An sich niet logisch, want het moet wel kunnen, idd. Klinkt als een bug; ik zou het op het ziggo forum aankaarten.

Misschien kun je er omheen werken door de NAS als DMZ-host op te geven. Dan moet je NAS wel goed dicht zitten, want al het overige verkeer komt dan op je NAS terecht. Ander alternatief is om een andere router te gebruiken, waarop je de port forwarding configureert

[Frogmen]

Ik lees nergens een dubbeling is ook logisch want op de server wil ieder protocol of service toch zijn eigen poort hebben anders gaat het niet werken.

[jurroen]

Frogmen schreef op zaterdag 21 augustus 2021 @ 16:14:
Ik lees nergens een dubbeling is ook logisch want op de server wil ieder protocol of service toch zijn eigen poort hebben anders gaat het niet werken.

Duurde ook even voordat ik 'm spotte. Maar:

TtomtomT schreef op zaterdag 21 augustus 2021 @ 15:21:
WAN TCP 443 -> LAN 1443, WAN TCP 8448 -> LAN 1443

@TtomtomT ik heb wat mixed feelings bij die tutorial. Het is niet heel logisch om die poort dubbel te forwarden. Daarnaast vraag ik mij ook af hoe lekker dat alles gaat werken, zonder JVB en andere onderdelen van Jitsi.

[TtomtomT]

Bedankt voor de reacties. Ik had de dubbeling even moeten highlighten, voor de volgende keer. Ik ben het met jullie eens dat het onlogisch is, maar in de officiële documentatie hebben ze het ook over '8448 -> https (443)' forwarden volgens mij.
Het hele Jitsi gebeuren eromheen was ik niet van plan toe te passen, ik was met name nieuwsgierig om Matrix eens zelf uit te proberen dus ik wilde alleen dat gedeelte van de guide toepassen. Voor nu laat ik het even zitten, ik heb de server verder werkende gekregen alleen kan ik niet communiceren met andere Matrix servers, maar aangezien ik toch nog niet van plan ben dit echt te gaan gebruiken is het voor nu goed zo.

[Verwijderd]

TtomtomT schreef op zaterdag 21 augustus 2021 @ 15:00:
Mijn vraag
Ik probeer op mijn Ziggo ConnectBox twee regels te maken als volgt:
1. NAS IP - interne poort 450 - externe poort 443
1. NAS IP - interne poort 450 - externe poort 8448

Kan niet.

[jurroen]

TtomtomT schreef op zaterdag 21 augustus 2021 @ 23:48:
ik was met name nieuwsgierig om Matrix eens zelf uit te proberen dus ik wilde alleen dat gedeelte van de guide toepassen.

De reference implementatie is Synapse. Als je specifiek zoekt op hoe je dat kunt opzetten vind je genoeg artikelen

Wat betreft de federation, als je puur aan het testen/experimenteren/spelen bent wil je dat vermoedelijk ook niet. Federation met Matrix.org heeft een heleboel meer resources nodig.

[Brahiewahiewa]

Verwijderd schreef op zaterdag 21 augustus 2021 @ 23:53:
[...]


Kan niet.

Bij nader inzien heb je gelijk: het probleem is niet de binnenkomende pakketjes, dat kan de router prima forwarden naar de juiste poort. Het probleem is de pakketjes die teruggestuurd worden. Die komen van port 450 en de router kan geen beslissing nemen of hij die nou op poort 443 of op poort 8448 moet uitsturen

[Verwijderd]

Brahiewahiewa schreef op zondag 22 augustus 2021 @ 01:15:
[...]

Bij nader inzien heb je gelijk: het probleem is niet de binnenkomende pakketjes, dat kan de router prima forwarden naar de juiste poort. Het probleem is de pakketjes die teruggestuurd worden. Die komen van port 450 en de router kan geen beslissing nemen of hij die nou op poort 443 of op poort 8448 moet uitsturen

Nice!

In hoeverre jij het zelf uitlegd heb ik echt het idee dat jij zelf wat geleerd hebt, en dat vindt ik echt fijn.

Misschien ligt er een toekomst voor jouw als network engineer in het verschiet

[TtomtomT]

Brahiewahiewa schreef op zondag 22 augustus 2021 @ 01:15:
[...]

Bij nader inzien heb je gelijk: het probleem is niet de binnenkomende pakketjes, dat kan de router prima forwarden naar de juiste poort. Het probleem is de pakketjes die teruggestuurd worden. Die komen van port 450 en de router kan geen beslissing nemen of hij die nou op poort 443 of op poort 8448 moet uitsturen

Ik heb altijd gedacht dat de outbound port enigszins willekeurig mag zijn, dus ik ben op onderzoek uit gegaan. Hier lijkt je antwoord te worden bevestigd. Voor de TCP handshake (denk ik te begrijpen?) moet het andere systeem natuurlijk een idee hebben waarnaar het terug moet sturen, dus wordt er teruggestuurd naar de poort waarop het ontvangen is. Op die manier is het logisch, weer wat nieuws geleerd!

Edit
Mijn eerste ingeving blijkt toch juist, zie reacties hieronder.

[ Voor 5% gewijzigd door TtomtomT op 23-08-2021 08:56 ]

[laurens0619]

Zeker?

Ik heb op mn experiabox meerder poorten luisteren voor openvpn en die translaten allemaal naar hetzelfde interne ip:port

Hier doen ze ook hetzelfde toch?
https://community.cisco.c...ination-port/td-p/2174512

[Faifz]

Brahiewahiewa schreef op zondag 22 augustus 2021 @ 01:15:
[...]

Bij nader inzien heb je gelijk: het probleem is niet de binnenkomende pakketjes, dat kan de router prima forwarden naar de juiste poort. Het probleem is de pakketjes die teruggestuurd worden. Die komen van port 450 en de router kan geen beslissing nemen of hij die nou op poort 443 of op poort 8448 moet uitsturen

Nee, je houdt enkel alleen maar rekening met destination poorten. Je hebt ook source poorten en hier is waar een web-server op antwoordt.

Client-IP = 50.50.50.50 (iemand uit het internet)
Webserver = 80.80.80.80 (je publieke adres bedoeld voor port-forwarding)

Dus wanneer iemand surft naar de webserver of wat je ook gebruikt voor port-forwarding, heb je het volgende:

- Source address/port: 50.50.50.50:43545 en Destination address/port: 80.80.80.80:443

Wanneer de webserver antwoordt:

- Source address/port: 80.80.80.80:443 en Destination address/port: 50.50.50.50:43545

Source poorten zijn redelijk random en verschillend per sessie. Zie voorbeeld onder.

[ Voor 6% gewijzigd door Faifz op 23-08-2021 04:30 ]

[Croga]

Brahiewahiewa schreef op zondag 22 augustus 2021 @ 01:15:
[...]

Bij nader inzien heb je gelijk: het probleem is niet de binnenkomende pakketjes, dat kan de router prima forwarden naar de juiste poort. Het probleem is de pakketjes die teruggestuurd worden. Die komen van port 450 en de router kan geen beslissing nemen of hij die nou op poort 443 of op poort 8448 moet uitsturen

Nonsense. De pakketjes die terug gestuurd worden krijgen gewoon een bestemming mee die door de NAT van de router netjes naar de juiste plaats gestuurd wordt.
Mijn Ubiquiti heeft er geen enkel probleem mee om verschillende poorten naar één intern IP:Poort te sturen en mijn webserver heeft er geen enkel probleem mee om vervolgens op basis van binnengekomen poort op de router een andere website te tonen.

Dit is een Ziggo beperking, niet meer en niet minder.

[Ben(V)]

Je kunt in een Ziggo router enkel binnenkomend verkeer naar een specifiek ipadres:port forwarden.
Andersom kan niet.
Verkeer vanaf je Lan wordt naar een ipadres:port gestuurd en die Ziggo router doet daar helemaal niets mee.
Als je het naar een andere port van dat internet ipadres wilt sturen meot je dat zelf regelen, dat doet die router niet voor je.

Dit staat er op de portforward pagina van je Connectbox (let op het woord "incoming").

This function allows for incoming requests on specific port numbers to reach web servers, FTP servers and mail servers, etc:

[thof]

TtomtomT schreef op zaterdag 21 augustus 2021 @ 15:21:
WAN TCP 443 -> LAN 1443, WAN TCP 8448 -> LAN 1443

Even samenvattend, met een voorbeeld voor interne IP-adressen:

Public IP port 443 ===> 192.168.1.200 port 1433
Public IP port 8448 ===> 192.168.1.200 port 1433

Dit lijkt dus niet te werken.

Wat je zou kunnen proberen als workaround, is je NAS twee ip-adressen geven in je netwerk.
Dan heeft hij niet meer alleen IP-adres 192.168.1.200, maar ook 192.168.1.201:

Public IP port 443 ===> 192.168.1.200 port 1433
Public IP port 8448 ===> 192.168.1.201 port 1433

[Ben(V)]

Beter lezen.
Hij wil de interne port 450 naar zowel externe poort 443 als externe poort 8448 forwarden.

Uiteraard kun je een dezelfde port niet naar twee porten forwarden (zou de data twee keer verzonden moeten worden) ook al was het mogelijk om Lan poorten naar Internet poorten te forwarden wat niet kan.

[laurens0619]

Beter lezen @Ben(V)
Het is andersom, van internet naar lan

En dat kan gewoon, alleen de kreupele connectbox niet. een 2e ip toekennen aan nas lijkt mij met deze hardware de enige oplossing

[Ben(V)]

Er staat dit:

Ik probeer op mijn Ziggo ConnectBox twee regels te maken als volgt:
1. NAS IP - interne poort 450 - externe poort 443
1. NAS IP - interne poort 450 - externe poort 8448

Het zal wel aan mijn gebrekkige taal kennis liggen, maar ik lees hieruit dat hij probeert vanaf het ipadres van z'n Nas een forward te maken van NAS ipadres:450 naar zowel poort 443 als 8448 van het internet.
En dat kan niet, niet alleen volgens mij maar ook volgens de Connectbox.

En ook port forwarding vanaf het internet naar van een poort 450 naar twee poorten (of twee ipadressen) kan natuurlijk ook nooit.
Dan zou de router dat verkeer moeten gaan dupliceren( of zelf een keuze maken waarheen het moet)

Wat de Ziggo Connectbox niet kan is outbound NAT, dus verkeer dat naar een ipadres:port gestuurd wordt vanaf je Lan naar een ander Ipadres:port op het internet sturen.
Is ook een tamelijk nutteloze functionaliteit, je kunt dat verkeer net zo goed meteen naar het juiste ipadres:port sturen.

[ Voor 20% gewijzigd door Ben(V) op 23-08-2021 13:38 ]

[TtomtomT]

Nee, bij die regels geef ik geen richting aan. Ik begrijp dat je het kan lezen als 'NAS -> intern 450 -> extern 443', maar ik geef simpelweg de parameters in de volgorde dat de ConnectBox interface ze verwachtte. @laurens0619 heeft hierin gelijk. Het verkeer komt vanaf buitenaf.

Het gaat hier om inbound port forwarden, waarbij er twee externe poorten naar een enkele interne poort geforward moeten worden. Dit staat de ConnectBox niet toe, dus is er het idee om de NAS een tweede IP te geven, waarop de tweede port forward regel toegepast wordt. Hierover zal de ConnectBox niet klagen, terwijl het verkeer van beide regels wel gewoon naar hetzelfde systeem toe zal gaan.

[Faifz]

Een alias adres toevoegen aan de interface van je NAS is best wel een goed idee. Verder lees ik wel dat poort 8448 in je nginx config file wel optioneel is volgens die guide. Blijkbaar wordt het gebruikt voor 'federations' en voor zover ik begrijp is het bedoeld om mensen van verschillende servers bijeen te brengen in een single chat room. Ik weet niet of jij dat nodig hebt.

Federation is the process by which users on different servers can participate in the same room. For this to work, those other servers must be able to contact yours to send messages.

[TtomtomT]

Ik zal eens naar een alias gaan kijken. Verder is federation helaas wel belangrijk; het maakt het mogelijk dat ik met mijn lokale account op mijn eigen server kan praten met mensen en rooms op andere servers. Momenteel kan ik alleen contact leggen met mensen die ook op mijn server geregistreerd staan.

🔗 What does federated mean?

Federation allows separate deployments of a communication service to communicate with each other - for instance a mail server run by Google federates with a mail server run by Microsoft when you send email from @gmail.com to @hotmail.com.

interoperable clients may simply be running on the same deployment - whereas in federation the deployments themselves are exchanging data in a compatible manner.

Matrix provides open federation - meaning that anyone on the internet can join into the Matrix ecosystem by deploying their own server.

Bedankt voor de hulp iedereen, wordt erg gewaardeerd!

[Ben(V)]

TtomtomT schreef op maandag 23 augustus 2021 @ 13:57:
Nee, bij die regels geef ik geen richting aan. Ik begrijp dat je het kan lezen als 'NAS -> intern 450 -> extern 443', maar ik geef simpelweg de parameters in de volgorde dat de ConnectBox interface ze verwachtte. @laurens0619 heeft hierin gelijk. Het verkeer komt vanaf buitenaf.

Het gaat hier om inbound port forwarden, waarbij er twee externe poorten naar een enkele interne poort geforward moeten worden. Dit staat de ConnectBox niet toe, dus is er het idee om de NAS een tweede IP te geven, waarop de tweede port forward regel toegepast wordt. Hierover zal de ConnectBox niet klagen, terwijl het verkeer van beide regels wel gewoon naar hetzelfde systeem toe zal gaan.

Ok dan heb ik je verkeerd begrepen.

Blijft gewoon staan dat wat je wilt niet kan.
Heeft niets met Ziggo te maken, dat kan geen enkele router.
Je kunt een router zo niet gebruiken en als het wel zou kunnen wordt het onbruikbaar.
Hoe stel je, je dat voor, het verkeer naar beiden sturen?
Je krijgt dan verkeer vanaf het internet dat naar twee applicties gaat die dan beiden een connectie gaan opzetten, dat gaat niet werken.

[TtomtomT]

Je begrijpt me nogmaals verkeerd.

Het verkeer gaat naar een enkele interne poort, en dus een enkele applicatie. Het kan gewoon op twee externe poorten binnenkomen, wat geen probleem is. Je kan je afvragen waarom ze dan niet al dat verkeer over dezelfde externe poort sturen, maar hiermee geven ze je een keuze in welk deel van het verkeer je binnen wilt krijgen. Als ik geen federation wil zet ik poort 8448 gewoon niet open en werkt alles nog wel.

Het heeft dus wel met Ziggo te maken.