Meedenkvraagje: network backdoor (dmv NAT)

[ITnetadmin]

Ik zoek al een tijdje een manier om een backdoor in een (zelfbeheerd) netwerk te steken, om binnen te geraken als de voordeur router plat ligt.
Dat is handig op het werk, maar ook thuis (ik heb telenet met een modem only, maar ook op een ander netwerk kan dat handig zijn als het toestel zelf een PPPoE kan/mag aanleggen).
Voor de duidelijkheid: ik zoek geen hack, crack, of low-security doorgang.

Momenteel gebruik ik vaak gewoon een tweede router, die ook een publiek IP krijgt, en een client op het netwerk die 2 netwerkkaarten heeft.
Afhankelijk van de implementatie (die afhangt van de complexiteit van het netwerk):
- hebben die allebei een ip in dezelfde range, maar met verschillende default gateways (eentje de voordeur, eentje de achterdeur)
- hebben die ips in aparte ranges maar zonder vlan scheiding (met de voor- en achterdeur intern ook aparte ranges op 1 fysiek en logisch netwerk)
- hebben die aparte ranges en aparte vlans
Zo log ik dan op de client in (via die tweede gateway) en ga ik van daarop inloggen naar het network device dat ik nodig heb (want die rechtstreeks aanspreken gaat uiteraard niet, zij kennen de backdoor gateway niet en gaan doodleuk replies sturen naar hun gewone gateway).
Dit werkt het makkelijkst wanneer een aparte client-server VPN setup een beetje overkill is of het snel moet gebeuren.

Vorige week kwam ik op een nieuw ideetje uit, maar ik krijg het niet verwoord in de juiste technische terminologie, waardoor ik via google niet veel wijzer wordt.
Ik dacht: zou het niet makkelijk zijn, als de backdoor device (meestal een router) gewoon twee keer NAT uitvoert?
De eerste NAT op de WAN poort (as usual), en de tweede NAT op de LAN poort (zodat interne toestellen enkel een intern IP zien komen van de router en denken dat het de router is die hen contacteert, ipv een extern IP).
Dan moet ik helemaal niet meer knoeien met multiple ranges, gateways, etc...
De termen "two-way NAT" en "bidirectional NAT" echter blijken al in gebruik te zijn voor een techniek die niet direct is wat ik zoek, voor zover ik mee ben.

Zijn er toestellen die dat kunnen?

Een router "omdraaien" heeft natuurlijk geen nut, want als de WAN kant niet geNAT is krijg je interne IPs op de WAN, en dat kan de bedoeling niet zijn.

Heeft er iemand ideetjes hierover?

[Splitter]

waarom niet gewoon een mikrotik o.i.d met wan failover?
maar dan nog, je concept van een toestel te zoeken "voor als het andere toestel plat ligt" vraagt dus zelf al voor een 2-toestel oplossing.

dus ofwel: gewoon een mikrotik met dual wan & failover, ofwel voluit gaan voor een volledig redundant setup (wat wss overkill is)

[ITnetadmin]

Het gaat hem niet over het failen van (een van de) de WAN verbinding(en), maar een totale bypass van de bestaande router (omdat ook die dingen wel ns willen falen); dit is extra handig wanneer ik de bestaande router op afstand aan het (her)configureren ben, want af en toe heb je het toch wel ns vlaggen en sluit je jezelf buiten.
De oplossing moet dan ook zo geimplementeerd zijn dat er geen sporen van te vinden zijn in de config van het "echte" netwerk.

Het is dus echt een "ooh, ik moet hier effe aan de voordeur werken dus zal ik maar snel de backdoor inpluggen" oplossingkje dat ik zoek, en geen superspeciale setup met virtuele gateways die in realiteit 2 fysieke toestellen zijn.

Ipv dat met 2 toestellen te doen, zoals nu, had ik gehoopt een toestel te vinden dat NAT kan uitvoeren langs beide zijden. Dan denkt elke client aan LAN zijde gewoon dat ze gecontacteerd worden door een intern toestel (omdat de NAT aan LAN kant dan het publieke IP van mijn login zou omzetten in het interne IP van de backdoor router).

[krisken]

Gebruik Mikrotik? Daar kan je per poort instellen of het een WAN of LAN poortje moet zijn.
Voorbeeldje : ik heb zelf een RB3011 liggen thuis met de volgende configuratie:
- Ethernet01 : Billi 1
- Ethernet02 : Billi 2
- Ethernet03 : Orange
- Ethernet04 : WirelessBelgië
- Ethernet05 : Vrij
- Ethernet06 : gerouteerd naar het intern adres van Billi1 voor configuratiedoeleinden (192.168.1.x)
- Ethernet07 : gerouteerd naar het intern adres van Billi2 voor configuratiedoeleinden (192.168.2.x)
- Ethernet08 : gerouteerd naar het intern adres van Orange voor configuratiedoeleinden (192.168.0.x)
- Ethernet09 : Vrij
- Ethernet10 : Vrij
- SFP (fiber) : naar mijn interne netwerk

Gevolg : ik kan de router (en dus ook de apparaten er achter) bereiken via het IP van Orange, het IP van WirelessBelgië en het IP van mijn gecombineerde Billi VDSL lijn.

[ITnetadmin]

Je bent niet mee, Krisken.
Het betreft een apart toestel, voor als ik mezelf uit de voordeur router lock van buitenaf, of voor als die effe platligt en ik moet "langs de achterdeur" naar binnen.
Het gaat hier *niet* om multi-wan redundantie, of het bereikbaar zijn van de provider modem vanop een andere lijn.

Ideaal gezien is de oplossing ook nog "portable", dat ik ze meesleur en gewoon inplug op het netwerk waar ik de backdoor nodig heb (waar ze dan een intern & extern IP krijgt van DHCP, of desnoods snel manueel een intern IP, maar verder minimal config changes).


Ik zoek hier dan ook specifiek antwoorden in de richting van de two-way NAT, en niet direct andere oplossingen (hoewel die altijd welkom zijn, focus ik me momenteel effe op deze mogelijke methode).

[krisken]

Iets als BlueCherry? https://www.bluecherry.io/

[ITnetadmin]

Ik wil ook effe bijvertellen dat IoT en "server-based" oplossingen waarbij ik niet alle aspecten (ie de server) onder controle heb, niet binnen de scope vallen (de S in IoT staat voor Security, nietwaar ).
Buiten de kost van het toestel mag de oplossing ook niks kosten (zeker geen recurring license kosten), want "tis uit eigen zak".

Ik zoek toch echt wel een mogelijkheid om een (klein) toestel te hebben dat NAT in beide richtingen kan uitvoeren.

Een alternatief zou zijn om 2 cheap-ass routers aan mekaar te hangen, eentje achterstevoren, en te zien of dat zou werken, maar dit correct uitvoeren is uiteraard ook een leuke challenge "om te zien of het kan".

[Splitter]

je maakt het dus wel moeilijk...

dus:

1 internetlijn => 1 modem => router A => intern netwerk
zelfde lijn => zelfde modem => router B => zelfde intern netwerk
je prult remote aan router A, die knalt eruit, dus je wil verbinden naar router B, en je devices moeten blijven denken dat je intern bent ?

zou je dan achter de routers niet gewoon een firewall appliance (al dan niet virtueel) zetten waar je naartoe VPN't ?
dan kan je verbinden met eender welke van de routers, en je zal altijd intern gezien worden... lijkt me het probleem op te lossen?

edit: en om het "portable" te maken: je neemt een appliance met 3 lan poorten, configt dat om 2 wan en 1 lan poort te hebben, zet daar een vpn op,
steekt dat tussen eender welk netwerk dat je wil (router A + router B + lan), en je hebt iets portable.
idealiter stel je dat dan nog in om een outbound verbinding op te zetten naar een colocated server van jezelf, en dan moet jij enkel verbinden naar die colo server - moet je in principe dus zelfs het public ip dat je appliance gbruikt op dat moment niet te kennen

[ITnetadmin]

Een appliance met VPN tunnel, colocated servers, etc, en *ik* maak het moeilijk omdat ik probeer iets met een two-way NATje uit te voeren dat verder geen config vereist? Wij ITers zijn toch een raar ras soms, denk ik

Nu, het ideetje van die tweerichtingsNAT zit nu "int koppeke", en dan moet dat ns geprobeerd worden

Een tweede router (pakweg pfsense) die een client-server NAT opzet waarbij de client een intern IP krijgt is uiteraard ook doenbaar, maar deze vraag gaat specifiek over de NAT oplossing, en minder over de generische backdoor vraag (hoewel je de ideetjes altijd mag laten komen)

Om specifiek op je vraag te antwoorden:

1 internetlijn => 1 modem => router A => intern netwerk
zelfde lijn => zelfde modem => router B => zelfde intern netwerk
je prult remote aan router A, die knalt eruit, dus je wil verbinden naar router B, en je devices moeten blijven denken dat je intern bent ?

Hier komt het idd op neer.
Ik doe dat nu al af en toe zo, maar dan moet ik nog altijd een interne client zetten (fysiek of VM) die 2 IP adressen heeft waarvan 1 met de alternatieve gateway.
Daarom dat ik de logische stap verder zette: als de backdoor gewoon op de lan kant gaat natten, dan denkt elk toestel dat het de backdoor is die hen contacteert (want intern ip), ipv een extern toestel, en maakt de gateway setting niet meer uit bij hen.

[gm123]

Bwa, moest je toevallig reeds een VPS of server ergens hebben die je voor hobby-doeleinden gebruikt dan lijkt een reverse tunnel mij toch ook een simpele oplossing. Dan kan je dat zelfs met iets cheap en klein a la raspberry pi doen die je gewoon maar in je bestaande netwerk moet pluggen wanneer je het nodig hebt en dan automatisch een tunnel opzet met de VPS/server (ok mss niet het meest betrouwbare, maar kan wel voor af en toe). En op deze manier werkt het ook op eender welk netwerk, zolang het backdoor device internet heeft en de firewall de uitgaande verbinding toelaat.

Op je client hoeft je dan niets te configureren en je netwerk weet van niks, enkel met de VPS/server verbinden en je bent binnen.

[C1nder]

Op welke manier maak je nu verbinding met die router zodat je uzelf kan uitsluiten?

Dit zou alleszins wel lukken met een device dat in het interne netwerk wordt gekoppeld en een site-to-site VPN tunnel kan opbouwen naar u. Als jij dan connectie maakt over die VPN, kan het device die connectie NAT-en over zijn eigen intern IP. Dit kan normaal wel via linux op bijvoorbeeld een raspberry pi denk ik.

Verder kan dit eventueel ook via een router of firewall die een management VPN tunnel kan opbouwen naar een soort van control center thuis of in de cloud waar u dan instellingen kan aanpassen en die gepushed worden van daar naar het device. Zo werken veel firewalls van onze klanten en we kunnen dus NAT toepassen op elke connectie waarvoor dit nodig is, zowel intern als extern.

Dit gaat natuurlijk allemaal wel enkel als internet via uw router blijft werken langs die kant Tenzij met een 4G stick of zo er nog aan als backup lijn.

[petzl]

nog nooit gehad dat ik niet meer aan mijn mikrotik kon, heb wel backup verbinding,
Teamviewer op een lokale pc is ook wel handig soms.

1 keer gehad dat een VPS raar deed en dmv broadcast het netwerk platlegde, via de naburige router op het backup circuit kon ik gelukkig nog wel zeer onstabiel telnetten om die interface uit te zetten.

[ITnetadmin]

Het leuke aan een backdoor, is dat je de voordeur kan herconfigureren zonder bang te moeten zijn iets fout te doen en jezelf buiten te sluiten.
Bv de VPN tunnel die je normaal gebruikt aanpassen, de poorten waarop je SSH'd veranderen, etc etc...
Accidentjes gebeuren al snel, en als je laat op de avond nog wat aan het prullen bent is het plezant om dat te doen met enige zekerheid dat je altijd er langs de binnenkant terug aan kan.

Raspberry pi lijkt me moeilijk geschikt, vermits dat ding maar 1 network connector heeft.


Soit, het is weer duidelijk dat userbasers onmogelijk binnen de krijtlijnen kunnen brainstormen :-p
Ik zal zelf nog ns moeten zoeken.

[raf1]

Ik snap je probleem niet helemaal. Bedoel je dit? https://wiki.mikrotik.com/wiki/Two_gateways_failover

[ubremoved_539]

Het leuke aan een backdoor, is dat je de voordeur kan herconfigureren zonder bang te moeten zijn iets fout te doen en jezelf buiten te sluiten.

Daarvoor hebben routers normaal twee configuraties zodat je altijd kan terugvallen op de laatste goede configuratie.

Mikrotik heeft hier bijvoorbeeld de "safe mode" voor die zelfs een rollback doet als je je console sessie verliest.

Soit, het is weer duidelijk dat userbasers onmogelijk binnen de krijtlijnen kunnen brainstormen :-p

Ik denk dat je zelf te ver buiten de krijtlijnen zit te denken... meestal is KISS niet slecht hoor.

[ITnetadmin]

Ik snap je probleem niet helemaal. Bedoel je dit? https://wiki.mikrotik.com/wiki/Two_gateways_failover

Nee.
Ik wil een config maken waarin zowel op de WAN poort geNAT wordt naar buiten (zodat het interne netwerk verborgen is achter het WANIP van de router), maar ook op de LAN poort geNAT wordt naar binnen (zodat het externe, publieke, netwerk verborgen is achter het LANIP van de router).

Met zo'n config kan elke router als backdoor dienen in een netwerk zonder dat je in dat netwerk nog extra configs moet aanpassen, want hierdoor moet je geen extra gateways opgeven, alle communicatie lijkt nl van dit toestel te komen, zowel intern als extern.

Daarvoor hebben routers normaal twee configuraties zodat je altijd kan terugvallen op de laatste goede configuratie.
Mikrotik heeft hier bijvoorbeeld de "safe mode" voor die zelfs een rollback doet als je je console sessie verliest.

Niet elke router die ik tegenkom kan dat, en niet elk netwerk waar ik op moet zijn is volledig onder mijn controle qua router.

Soit, het is weer duidelijk dat userbasers onmogelijk binnen de krijtlijnen kunnen brainstormen :-p

Ik denk dat je zelf te ver buiten de krijtlijnen zit te denken... meestal is KISS niet slecht hoor.

KISS is relatief he; 2-richtings-NAT vs een VPN tunnel, die VPN tunnel is ook al niet meer KISS he, gewoon meer gestandardiseerd qua gebruik.
En ja, nu dit ideetje in mijne kop zit, gaat het eerder over "can we do this" dan "is this feasible for longterm use"; dat komt later wel (grootste probleem als je van je hobby je beroep maakt natuurlijk ).

Ik bedoelde met die comment vooral dat als je hier pakweg vraagt naar (en ik citeer de titel) "network backdoor dmv NAT", dat er vooral meegedacht wordt over andere vormen van backdoors, en niet over de NAT-vorm
It's like herding cats in here :-p

[selder]

"Verplaats" je het (mogelijk) probleem niet gewoon door zo'n setup? Je gaat in dergelijke setups toch nog altijd 1 apparaat hebben dat de gateway is, en dat apparaat is dan toch ook gewoon een single point of failure?

In een originele normale setup met 1 gateway (dat probably ook gewoon de modem is) wil je opvangen dat je van remote nog aan je intern netwerk kan als de gateway eruit ligt.
In zo'n setup met 2-weg nat ga je toch nog altijd 1 apparaat hebben dat de gateway is, als dat apparaat eruit ligt dan kan je toch ook niet aan je interne netwerk vanuit het internet?

[Sinna]

Ik zie het probleem eigenlijk niet: als ik via OpenVPN inlog op het bedrijfsnetwerk dan hebben verbindingen vanaf/via de VPN-server het LAN-IP-adres van die VPN-server en niet het adres van waar ik verbind. Die VPN-server is niet de gateway op het netwerk en toch kan ik overal aan...
Als je een extra dynamisch IP-adres kan inzetten dan zou een router die ook als VPN-server dienst kan doen, moeten volstaan.

[selder]

Passeert jouw traffic van je VPN verbinding naar je werk via de gateway waarmee het interne netwerk van je werk aan het internet hangt? Als die gateway er dan uitvalt, dan kan jij ook niet meer via VPN verbinden ... Ik vermoed dat het dat is dat de TS wil opvangen met zijn gewenste setup...

[ubremoved_539]

Ik wil een config maken waarin zowel op de WAN poort geNAT wordt naar buiten (zodat het interne netwerk verborgen is achter het WANIP van de router), maar ook op de LAN poort geNAT wordt naar binnen (zodat het externe, publieke, netwerk verborgen is achter het LANIP van de router).

Die moet je toch eens nader verklaren... een traditionele NAT is tussen WAN en LAN, dus wat jij vraagt is toch het standaard NAT gedrag in de normale routers ? Je NAT niet op één interface, maar tussen twee interfaces.

Langs buiten heb je één IP (je publiek), langs binnen gaat alles eveneens via één IP (je default gateway). Indien het een probleem is dat je slechts één extern IP adres hebt, iedere deftige router kan meerdere adressen hebben per interface zodat je nog steeds via het andere binnen kan (al blijft werken aan een router/firewall altijd een zeker risico inhouden).

Als die gateway er dan uitvalt, dan kan jij ook niet meer via VPN verbinden ...

Dan definieer je toch gewoon een tweede/derde/vierde/... publiek IP-adres waar je de VPN service opzet ?

[selder]

Dan definieer je toch gewoon een tweede/derde/vierde/... publiek IP-adres waar je de VPN service opzet ?

Uiteraard, maar niet op hetzelfde fysieke bak, toch? Als die bak eruit plooit dan sta je nergens.
1 gateway in je netwerk is toch altijd 1 single point of failure?

[ubremoved_539]

Als je je daar tegen wil voorzien plaats je inderdaad gewoon een tweede router/firewall (en als je het compleet wil via een andere provider technologie).

Zo log ik dan op de client in (via die tweede gateway) en ga ik van daarop inloggen naar het network device dat ik nodig heb (want die rechtstreeks aanspreken gaat uiteraard niet, zij kennen de backdoor gateway niet en gaan doodleuk replies sturen naar hun gewone gateway).

Als jij via een VPN binnen komt krijg je gewoon een local adres en hoeft het device dat je aanspreekt zelfs geen default gateway te hebben ! De connectie is trouwens geinitieerd vanuit je firewall dus er komen zelfs geen replies (alles gaat over dezelfde socket connectie).

Het probleem dat je denkt te hebben is enkel indien je device zelf connecties zou opzetten naar buiten toe (bv. jij logged aan op je VPN, start een RDP sessie naar een intern device en begint daar te surfen naar het internet). Wil je dat probleem oplossen dan definieer je gewoon twee default gateways op de clients (of werk je met een derde failover device).

[tb0ne]

Een raspberry/oude router/... die een ssh tunnel opzet?
Google maar op reverse ssh tunnelling...

[selder]

Die dan ook weeral (bij een thuisopstelling toch) zijn paketten door dezelfde "modem" en "gateway" van telenet of proximus stuurt - als dat apparaat eruit knalt (kapot of verkeerde config) dan kan die reverse SSH tunnel ook niet meer aan het internet ...

Een 4G Router met daarop een VPN of remote inlog functionaliteit is denk ik nog één van de meest simpele oplossingen voor thuis.

[ubremoved_539]

als dat apparaat eruit knalt (kapot of verkeerde config)

Ik denk niet dat de TS hiervoor een oplossing zocht... louter voor eigen misconfiguraties van z'n firewall dacht ik.

[Sinna]

Passeert jouw traffic van je VPN verbinding naar je werk via de gateway waarmee het interne netwerk van je werk aan het internet hangt? Als die gateway er dan uitvalt, dan kan jij ook niet meer via VPN verbinden ... Ik vermoed dat het dat is dat de TS wil opvangen met zijn gewenste setup...

Neen: door tussen mijn modem en de firewall een (domme) switch te plaatsen en dáár mijn VPN-routerke op aan te sluiten, omzeil ik zowat alle apparatuur (muv. de modem en die switch uiteraard). Die vlieger gaat volgens mij bij Telenet enkel op als je een modem-only hebt en op VDSL als je een extra PPPoE-sessie kan opzetten met een eigen IP-adres (dus niet bij EDPnet VDSL Pro).

[ITnetadmin]

Passeert jouw traffic van je VPN verbinding naar je werk via de gateway waarmee het interne netwerk van je werk aan het internet hangt? Als die gateway er dan uitvalt, dan kan jij ook niet meer via VPN verbinden ... Ik vermoed dat het dat is dat de TS wil opvangen met zijn gewenste setup...

Neen: door tussen mijn modem en de firewall een (domme) switch te plaatsen en dáár mijn VPN-routerke op aan te sluiten, omzeil ik zowat alle apparatuur (muv. de modem en die switch uiteraard). Die vlieger gaat volgens mij bij Telenet enkel op als je een modem-only hebt en op VDSL als je een extra PPPoE-sessie kan opzetten met een eigen IP-adres (dus niet bij EDPnet VDSL Pro).

Ja, die setup is er ook, en was ook een gedefinieerde vereiste in de setup.

Er komt dus helemaal geen Telenet of Proximus gateway meer aan te pas.

Ik wil een config maken waarin zowel op de WAN poort geNAT wordt naar buiten (zodat het interne netwerk verborgen is achter het WANIP van de router), maar ook op de LAN poort geNAT wordt naar binnen (zodat het externe, publieke, netwerk verborgen is achter het LANIP van de router).

Die moet je toch eens nader verklaren... een traditionele NAT is tussen WAN en LAN, dus wat jij vraagt is toch het standaard NAT gedrag in de normale routers ? Je NAT niet op één interface, maar tussen twee interfaces.

Langs buiten heb je één IP (je publiek), langs binnen gaat alles eveneens via één IP (je default gateway). Indien het een probleem is dat je slechts één extern IP adres hebt, iedere deftige router kan meerdere adressen hebben per interface zodat je nog steeds via het andere binnen kan (al blijft werken aan een router/firewall altijd een zeker risico inhouden).

Ik snap echt niet wat er zo moeilijk is aan mijn uitleg.
Ik vraag het standaard NATgedrag *in beide richtingen*. Eenmaal in de normale richting, zodat publieke toestellen het interne netwerk niet zien.
En eenmaal in omgekeerde richting (reverse NAT), zodat interne toestellen niet zien dat de communicatie vanop een extern IP gestart is.

Ik denk niet dat de TS hiervoor een oplossing zocht... louter voor eigen misconfiguraties van z'n firewall dacht ik.

Yups.

Passeert jouw traffic van je VPN verbinding naar je werk via de gateway waarmee het interne netwerk van je werk aan het internet hangt? Als die gateway er dan uitvalt, dan kan jij ook niet meer via VPN verbinden ... Ik vermoed dat het dat is dat de TS wil opvangen met zijn gewenste setup...

Exact; een onafhankelijke backdoor.
Het leuke zou zijn dat als ie in beide richtingen NAT, dat interne toestellen niet merken dat ze gecontacteerd worden vanop een extern IP, en ze dus niet gaan verkeerdelijk de replies naar hun geconfigureerde gateway sturen, maar rechtstreeks naar de backdoor, die de replies terugstuurt naar buiten toe.

[ubremoved_539]

Het leuke zou zijn dat als ie in beide richtingen NAT, dat interne toestellen niet merken dat ze gecontacteerd worden vanop een extern IP, en ze dus niet gaan verkeerdelijk de replies naar hun geconfigureerde gateway sturen, maar rechtstreeks naar de backdoor, die de replies terugstuurt naar buiten toe.

Toestellen sturen replies terug over de initiele connectie zoals ik al eerder schreef... hun geconfigureerde gateway komt hieraan niet te pas (hij hoeft zelfs niet geconfigureerd te zijn !).

Bijvoorbeeld... jij doet een HTTP GET vanaf het internet, dit bereikt (via portforwarding aangezien je NAT hebt) een interne webserver op je LAN, deze stuurt het resultaat (de HTML dus) gewoon terug over diezelfde bestaande socket connectie ! Die webserver gaat dus niet opnieuw een connectie opzetten, noch kijken wat z'n default gateway is.

Ik heb de indruk dat je niet goed begrijpt hoe TCP/IP werkt op basis van je vragen.

[tb0ne]

Die dan ook weeral (bij een thuisopstelling toch) zijn paketten door dezelfde "modem" en "gateway" van telenet of proximus stuurt - als dat apparaat eruit knalt (kapot of verkeerde config) dan kan die reverse SSH tunnel ook niet meer aan het internet ...

Als de internet toegang zelf redundant is geraakt uw backdoor ook terug naar buiten toch?
Waarom de backdoor redundant maken in dat geval?
Op basis van hetgeen ik lees is het een simpele manier om in de LAN te geraken die je toelaat om vanaf daar weer alles te doen wat je zou willen.
Als het internet kapot is of uw router kapot is wat heb je dan aan die bereikbare backdoor?

[ITnetadmin]

Het leuke zou zijn dat als ie in beide richtingen NAT, dat interne toestellen niet merken dat ze gecontacteerd worden vanop een extern IP, en ze dus niet gaan verkeerdelijk de replies naar hun geconfigureerde gateway sturen, maar rechtstreeks naar de backdoor, die de replies terugstuurt naar buiten toe.

Toestellen sturen replies terug over de initiele connectie zoals ik al eerder schreef... hun geconfigureerde gateway komt hieraan niet te pas (hij hoeft zelfs niet geconfigureerd te zijn !).

Bijvoorbeeld... jij doet een HTTP GET vanaf het internet, dit bereikt (via portforwarding aangezien je NAT hebt) een interne webserver op je LAN, deze stuurt het resultaat (de HTML dus) gewoon terug over diezelfde bestaande socket connectie ! Die webserver gaat dus niet opnieuw een connectie opzetten, noch kijken wat z'n default gateway is.

Ik heb de indruk dat je niet goed begrijpt hoe TCP/IP werkt op basis van je vragen.

Externe server stuurt request naar interne server via backdoor; interne server leest IP van source (en die ziet wel degelijk het externe IP) en stuurt reply terug... via zijn gateway.
Stel jij geen gateway in, dan ga je geen reply krijgen.
Toestellen sturen hoegenaamd de reply niet magisch terug via het toestel waarlangs de request binnenkwam.

Network misconception: "When packets take a certain route to their destination they DO NOT have to take the same route back."

[ubremoved_539]

interne server leest IP van source (en die ziet wel degelijk het externe IP) en stuurt reply terug... via zijn gateway.

Of hij het externe IP-adres ziet is afhankelijk van het type connectie, met een VPN is het helemaal zo dat je normaal een IP-adres krijgt in het lokale subnet (en je default gateway er dus niet aan te pas komt).

[ITnetadmin]

Of hij het externe IP-adres ziet is afhankelijk van het type connectie, met een VPN is het helemaal zo dat je normaal een IP-adres krijgt in het lokale subnet (en je default gateway er dus niet aan te pas komt).

Met een client-server VPN is dat idd normaal zo.
Op een standaard geNATte connectie echter ziet hij het externe IP.

Dat was echter niet je oorspronkelijke opmerking. Je zei dat connection oriented protocols hun reply op een request vanop het internet terugsturen volgens dezelfde weg als de request, en de server die de reply stuurt zelfs geen gateway nodig heeft om dit te doen. En dat is gewoon niet juist.

[ubremoved_539]

Op een standaard geNATte connectie echter ziet hij het externe IP.

Dit is afhankelijk van het type NAT... ik heb in het verleden reeds implementaties gezien waarbij in de HTTP logs enkel het IP-adres van de firewall te zien was (en dus niet het externe adres) tot mijn frustratie.

Je zei dat connection oriented protocols hun reply op een request vanop het internet terugsturen volgens dezelfde weg als de request, en de server die de reply stuurt zelfs geen gateway nodig heeft om dit te doen. En dat is gewoon niet juist.

Hier heb je gelijk (ik zat even foutief op applicatie niveau te denken)... feit blijft dat in de context van jou vraag de default gateway niet van belang is volgens mij omdat je steeds een VPN opzet.

[ITnetadmin]

Nee; dan heb je mijn context effe verkeerd begrepen, denk ik.
Ik probeer het zonder VPN te doen, eerder als een "zou dit kunnen" vraagstuk, en om mss (indien succesvol) af en toe snel te kunnen een backdoor maken die vanop alle pcs snel gebruikt kan worden zonder verdere VPN config.

Met een juiste client VPN config, krijgt de inloggende PC inderdaad een lokaal IP toegekend op zijn VPN interface en komt de gateway er niet aan te pas.