TP-Link Omada routering doet gek, NGINX proxy

[iqcgubon]

Ik kom toch hier mijn licht nog eens opsteken want ik zit met een gek probleem dat *misschien* met de Omada router te maken heeft.

Ik heb een NGINX proxy manager draaien op IP 192.168.0.100. Hierop staan een hoop subdomains die ik host, app1.mijndomein.be, app2.mijndomein.be,...

Ik draai ook een lokale DNS, waar ik A records heb toegevoegd voor al deze subdomeinen die verwijzen naar 192.168.0.100.

Alle VLANS op mijn Omada router hebben mijn lokale DNS als DNS server ingesteld.

Ping, Dig, Nslookup, traceroute,... bevestigen allemaal dat "app1.mijndomein.be" verwijst naar 192.168.0.100 en dus op mijn nginx terecht komt. Mijn verwachting is dus: Als ik via mijn lokaal netwerk naar deze domeinen ga, dat ik via een lokaal IP kom (het IP mijn van notebook).

Maar toch als ik de access log van nginx kijk, kom ik altijd op de websites terecht via mijn public IP... Het is net alsof mijn Omada router er niet in slaagt om correct te routeren van mijn user VLAN naar mijn server VLAN, en dan maar gewoon naar buiten gaat. Ook al werkt een dig, nslookup,... gewoon wel. De routing table bevestigd ook dat de next-hop de lokale VLAN is, niet de default gateway.

Wat mis ik hier? Config op mijn Omada router, of toch ergens iets in mijn nginx proxy manager?

[ Voor 3% gewijzigd door iqcgubon op 09-08-2024 10:43 ]

[silentkiller]

@iqcgubon welke browser gebruik je? Toevallig een DNS server in de browser geconfigureerd zodat de DNS server meegekregen van de DHCP niet wordt gebruikt?
Heb je hetzelfde resultaat als je naar het subdomain 'surft' via curl?

[iqcgubon]

silentkiller schreef op vrijdag 9 augustus 2024 @ 11:09:
@iqcgubon welke browser gebruik je? Toevallig een DNS server in de browser geconfigureerd zodat de DNS server meegekregen van de DHCP niet wordt gebruikt?
Heb je hetzelfde resultaat als je naar het subdomain 'surft' via curl?

Verschillende browsers geven hetzelfde resultaat, ik heb inderdaad al gekeken of DNS-over-HTTP/TLS daar niet enabled is en dat die per ongeluk via een externe DNS gaan.

Een curl geeft 301 Moved Permanently (logisch denk ik) en de access log toont het public IP.

[GrtA]

Wat gebeurt er als je de WAN-kant van de router loskoppelt? Dan zou je nog steeds alle lokale domeinen moeten kunnen bereiken maar kan er geen verkeer meer van het externe IP komen.

[silentkiller]

Waarom is die 301 normaal?

Veroorzaakt dat net niet een redirect naar een adres welke niet in je interne DNS zit?
Zie je voor die 301 logging in je nginx? Welk source IP adres staat daar?

[iqcgubon]

GrtA schreef op vrijdag 9 augustus 2024 @ 11:18:
Wat gebeurt er als je de WAN-kant van de router loskoppelt? Dan zou je nog steeds alle lokale domeinen moeten kunnen bereiken maar kan er geen verkeer meer van het externe IP komen.

Dat werkt zoals verwacht. Ik kan de domeinen perfect bereiken, en de access log toont dat ik binnenkom via een lokaal IP, het IP van mijn laptop.

silentkiller schreef op vrijdag 9 augustus 2024 @ 11:21:
Waarom is die 301 normaal?

Veroorzaakt dat net niet een redirect naar een adres welke niet in je interne DNS zit?
Zie je voor die 301 logging in je nginx? Welk source IP adres staat daar?

Is dat niet hoe nginx hoort te werken? Ik kom toe via poort 80 of 443 op nginx, die ziet de request als "app1.mijndomein.be" en redirect (HTTP 301) die op zijn beurt naar bijvoorbeeld 192.168.0.150:8080.

[GrtA]

iqcgubon schreef op vrijdag 9 augustus 2024 @ 11:35:
[...]

Dat werkt zoals verwacht. Ik kan de domeinen perfect bereiken, en de access log toont dat ik binnenkom via een lokaal IP, het IP van mijn laptop.

Toont dit dan niet aan dat het iets in de router is? Dus wellicht hoe de routering van vlan-1 naar vlan-2 gaat?

Mogelijk dat dit probleem is iets dat 'hair-pinning' heet (snelle Google op het probleem) maar daarvoor rijkt mijn kennis niet ver genoeg, maar misschien dat het je helpt het probleem te vinden.

[ Voor 20% gewijzigd door GrtA op 09-08-2024 11:50 ]

[iqcgubon]

GrtA schreef op vrijdag 9 augustus 2024 @ 11:47:
[...]

Toont dit dan niet aan dat het iets in de router is? Dus wellicht hoe de routering van vlan-1 naar vlan-2 gaat?

Mogelijk dat dit probleem is iets dat 'hair-pinning' heet (snelle Google op het probleem) maar daarvoor rijkt mijn kennis niet ver genoeg, maar misschien dat het je helpt het probleem te vinden.

Daar lijkt het wel op maar valt dus niet te rijmen met het feit dat een traceroute vanop mijn PC naar de site gewoon werkt in 2 hops zoals verwacht: Naar de default gateway van mijn LAN, direct naar de server.

Ik durf ook niet goed een bijkomende static route aan te maken naar NGINX, want mijn Omada controller draait daar ook op (1 host met docker containers), en als er daardoor ergens een loop ontstaat kan ik er niet meer aan

Hairpinning of of NAT Loopback zou enkel een probleem zijn als je geen eigen DNS gebruikt, wat ik hier wel doe.

[ Voor 12% gewijzigd door iqcgubon op 09-08-2024 12:20 ]

[GrtA]

iqcgubon schreef op vrijdag 9 augustus 2024 @ 12:03:
[...]


Daar lijkt het wel op maar valt dus niet te rijmen met het feit dat een traceroute vanop mijn PC naar de site gewoon werkt in 2 hops zoals verwacht: Naar de default gateway van mijn LAN, direct naar de server.

Hairpinning of of NAT Loopback zou enkel een probleem zijn als je geen eigen DNS gebruikt, wat ik hier wel doe.

Deze discussie begint wellicht ook wel voorbij te gaan aan het Omada topic. Misschien heropenen/verplaatsen naar Netwerk Algemeen? Daar zit denk ik ook meer kennis verwacht ik.

[silentkiller]

iqcgubon schreef op vrijdag 9 augustus 2024 @ 11:35:
Is dat niet hoe nginx hoort te werken?

Neen, alle traffic gaat 'door' een reverse proxy. De client babbelt met nginx, nginx babbelt met de server. Net om de achterliggende server af te schermen.

Heel vreemd dat het werkt als de WAN wordt uitgetrokken.

Hairpin NAT is bedoeld om verkeer dat naar het EXTERNE adres (WAN) gaat (source = intern), direct intern te routeren (omdat het terugkomende pakket anders het internet wordt opgestuurd).
Ik zie niet in hoe je router gaat besluiten dat ie een target intern ip adres over de WAN interface gaat routeren (maar daat lijkt het wel op )

[iqcgubon]

silentkiller schreef op vrijdag 9 augustus 2024 @ 13:00:
[...]


Ik zie niet in hoe je router gaat besluiten dat ie een target intern ip adres over de WAN interface gaat routeren (maar daat lijkt het wel op )

En dan enkel HTTP(S), want icmp komt wel netjes direct op de juiste plaats terecht Ben m'n hoofd er al lang over aan het breken maar kom er maar niet uit.

[silentkiller]

Die 301 blijf ik toch ook vreemd vinden, ik zou in je browser ook eens naar de netwerk trafiek kijken via de developer tools, mogelijks geef dat je meer inzicht

[iqcgubon]

Niks bijzonders in de Dev Tools op mijn browser. Het eerste wat ik zie is GET, en krijg daarop direct een HTTP 200 terug.

Maar dit is wel interessant:

In de Omada controller kan je bij Tools een Network Check uitvoeren.

Als ik daar een ping of traceroute doe vanop een EAP of Switch, kom ik op het lokale IP uit. Maar als ik dat doe vanop de Gateway, kom ik op mijn WAN IP uit.

De router zelf lijkt dus niet de juiste DNS servers te gebruiken. Iets voor het Omada forum denk ik... Zal daar ook mijn licht nog eens opsteken.

[silentkiller]

Zou niks mogen uitmaken, je client (of brwoser) doet DNS resolving en stuurt dan het pakket naar het juiste IP.

Bij HTTP stuur je wel een HTTP header mee waar ook de 'host header' in zit, maar dat is iets op layer 7 en komt je router in principe niet aan (tenzij je daar iets van layer 7 hebt zitten?)

[Yariva]

@iqcgubon ik heb de reacties opgesplitst naar een eigen topic. Zoals eerder benoemt verdient het nu wel zijn eigen plekje en gaan veel onderwerpen wat dieper dan enkel de Omada series