Unifi portforwarding verbergt intern IP adres

[xilent_xage]

Hoi,

Ik heb in mijn netwerk een webserver draaien, en gebruik in mijn unifi controller portforwarding om verkeer op poort 80 en 443 daarheen te sturen. Dat werkt opzich prima.

Mijn probleem is dat ik op mijn webserver via PHP het IP adres van de bezoeker probeer uit te lezen, met $_SERVER['REMOTE_ADDR']. Voor externe bezoekers werkt dit zoals je zou verwachten, maar voor bezoekers vanuit mijn LAN zie ik het IP adres van de router ipv het IP adres van de bezoeker. Hij voegt ook geen X-FORWARDED-FOR toe of iets dergelijks.

Hoe kan ik dit fixen? Ik heb het liefst dat ie gewoon het IP van de bezoeker doorgeeft...

[Jboy1991]

Via onderstaande code moet het werken

$localIP = getHostByName(getHostName());

[hcQd]

Geen nat-loopback gebruiken maar split-dns.

[xilent_xage]

Jboy1991 schreef op woensdag 20 januari 2021 @ 07:16:
Via onderstaande code moet het werken

$localIP = getHostByName(getHostName());

Toch niet. Dit geeft 127.0.1.1 terug ipv 192.168.1.40.

[xilent_xage]

hcQd schreef op woensdag 20 januari 2021 @ 07:35:
Geen nat-loopback gebruiken maar split-dns.

Volgens mij had ik moeten vermelden dat ik gewoon een FQDN gebruik, en connect via https: lets encrypt. Ik ga ook vanuit mijn LAN via de FQDN naar de server.

[ralpje]

xilent_xage schreef op woensdag 20 januari 2021 @ 09:58:
[...]


Volgens mij had ik moeten vermelden dat ik gewoon een FQDN gebruik, en connect via https: lets encrypt. Ik ga ook vanuit mijn LAN via de FQDN naar de server.

Als je zorgt dat op je LAN de FQDN resolved naar het interne IP-adres (vandaar de split DNS ) dan ga je buiten de router om en kom je dus direct op je webserver terecht.

[laurens0619]

Ik denk dat dit een logisch gevolg is van HairPin NAT en wanneer er SrcNAT of DstNAT wordt toegepast

https://serverfault.com/q...etwork-hairpin-nat/557776

Ik weet niet zeker of dit technisch op te lossen is door zaken te tweaken in de router.
Split DNS lost het sowieso op (maar krijg je wel certificate errors omdat het verkeerde ip dan bij het cert zit)

[ralpje]

laurens0619 schreef op woensdag 20 januari 2021 @ 10:27:


Ik weet niet zeker of dit technisch op te lossen is door zaken te tweaken in de router.
Split DNS lost het sowieso op (maar krijg je wel certificate errors omdat het verkeerde ip dan bij het cert zit)

Certs kijken naar de hostname, niet naar het IP.
Als je je split DNS dus gewoon netjes inricht krijg je geen enkele certificate error.

[laurens0619]

Dit is by design, split dns is je enige optie

Ik heb het even gevisualiseerd:

Dit is nu hoe traffic binnenkomt vanaf de buitenkant



Dit is nu hoe traffic binnenkomt vanaf de binnenkant:



Dit is hoe je traffic vanaf de binnenkant wil laten lopen om je src header intact te laten:



Edit:
Ah dat symmetric routing kan niet werken helaas
the client sends a packet with a source IP address of 192.168.1.10 to a destination IP address of 1.1.1.1 on port tcp/80 to request some web resource.
the router destination NATs the packet to 192.168.1.2 and replaces the destination IP address in the packet accordingly. The source IP address stays the same: 192.168.1.10.
the server replies to the client's request. However, the source IP address of the request is on the same subnet as the web server. The web server does not send the reply back to the router, but sends it back directly to 192.168.1.10 with a source IP address in the reply of 192.168.1.2.
The client receives the reply packet, but it discards it because it expects a packet back from 1.1.1.1, and not from 192.168.1.2. As far as the client is concerned the packet is invalid and not related to any connection the client previously attempted to establish.
To fix the issue, an additional NAT rule needs to be introduced on the router to enforce that all reply traffic flows through the router, despite the client and server being on the same subnet. The rule below is very specific to only apply to the traffic that the issue could occur with - if there are many servers the issue occurs with, the rule could be made broader to save having one such exception per forwarded service.I

However, the web server only ever sees a source IP address of 192.168.1.1 for all requests from internal clients regardless of the internal client's real IP address. There is no way to avoid this without either using a router that can do application level DNS inspection and can rewrite A records accordingly, or a split DNS server that serves the internal clients the internal server IP address and external clients the external server IP address.

[ Voor 115% gewijzigd door laurens0619 op 20-01-2021 20:15 ]

[xilent_xage]

Super bedankt voor de uitgebreide en grondige reacties! Ik heb in mijn DNS server kunnen instellen dat voor LAN de FQDN direct naar het interne IP van de webserver wordt doorgestuurd. Volgens mij werkt dit goed, want als ik ping naar de FQDN kreeg ik eerst mijn externe IP adres te zien, en nu het interne IP van de webserver.

Maar... helaas. PHP ziet nog steeds het IP adres van mijn router als REMOTE_ADDR.

Doe ik iets niet goed? of zijn er nog andere ideeen?

[GlowMouse]

xilent_xage schreef op woensdag 20 januari 2021 @ 20:43:
Maar... helaas. PHP ziet nog steeds het IP adres van mijn router als REMOTE_ADDR.

Doe ik iets niet goed? of zijn er nog andere ideeen?

Je browser gebruikt waarschijnlijk DoH (dns over https) waarmee de DNS-server in je router wordt omzeild. Als je dat uitzet, werkt het wel.

[xilent_xage]

GlowMouse schreef op woensdag 20 januari 2021 @ 20:45:
[...]

Je browser gebruikt waarschijnlijk DoH (dns over https) waarmee de DNS-server in je router wordt omzeild. Als je dat uitzet, werkt het wel.

Ik gebruik een Pihole als DNS server, die volgens mij voor upstream DNS requests ook DoH gebruikt. Voor downstream DNS requests wordt volgens mij geen DoH ondersteund, en ik kan daar ook bar weinig over vinden. Volgens mij omdat de meeste mensen hun DNS verkeer vanuit LAN naar hun eigen DNS server wel vertrouwen.

Mijn pihole staat wel ingesteld als DNS server binnen mijn netwerk, en dat werkt goed met Chrome, anders zou ik wel meer ads te zien krijgen lijkt me.

Ik krijg in mijn Chrome settings DoH niet meer gevonden, maar dit zou het volgens mij niet moeten zijn, omdat Chrome duidelijk via mijn pihole loopt (waar ook de FQDN voor LAN ingesteld staat.)

Right?

[ Voor 0% gewijzigd door xilent_xage op 20-01-2021 20:57 . Reden: typos ]

[xilent_xage]

Sapperdeflap. Ik dacht ik doe eens een tracert om te kijken hoe de route precies loopt, blijkt ie toch via een kpn.net node te lopen. Opnieuw een ping gedaan, en ik krijg nu weer een reply van mijn externe IP, terwijl ik bij mijn weten niks veranderd heb.

Heb als een flushdns gedaan, dus....

[laurens0619]

doe eens een nslookup ipv een ping, dan kun je zien welke server dat (verkeerde) ip teruggeeft. Als dat de pi is dan moet je het daar zoeken

[xilent_xage]

laurens0619 schreef op woensdag 20 januari 2021 @ 22:14:
doe eens een nslookup ipv een ping, dan kun je zien welke server dat (verkeerde) ip teruggeeft. Als dat de pi is dan moet je het daar zoeken

Ik krijg het IP van de router terug. Maarja, daar kan natuurlijk hetzelfde probleem spelen...

[laurens0619]

Die snap ik niet
Nslookup hoort het ip van dr webserver te geven

Kun je de output hier eens posten?

[xilent_xage]

laurens0619 schreef op donderdag 21 januari 2021 @ 07:24:
Die snap ik niet
Nslookup hoort het ip van dr webserver te geven

Kun je de output hier eens posten?

Sorrie, ik krijg natuurlijk het IP van de webserver terug. Maar het antwoord komt van de router, en niet van de DNS server. Ik denk dat ik heb ingesteld dat de router zelf zijn gegevens bij de DNS server vandaan haalt, maar in het netwerk functioneert als DNS server voor alle devices?

[laurens0619]

xilent_xage schreef op donderdag 21 januari 2021 @ 09:27:
[...]


Sorrie, ik krijg natuurlijk het IP van de webserver terug. Maar het antwoord komt van de router, en niet van de DNS server. Ik denk dat ik heb ingesteld dat de router zelf zijn gegevens bij de DNS server vandaan haalt, maar in het netwerk functioneert als DNS server voor alle devices?

Doe eens een ipconfig van je pc
Het zou kunnen dat hij van pc naar router naar pi naar upstream gaat
Maar dan moet je wel de router kunnen vertrouwen dat dir alles naar de pi zet

Stel eens op je pc handmatig de dns van de pi in

Edit: ik denk nu dat je de dns als upstream in de usg hebt gezet. Je moet bij de dhcp server het dns adres van de pihole uitgeven

[ Voor 9% gewijzigd door laurens0619 op 21-01-2021 09:36 ]

[xilent_xage]

laurens0619 schreef op donderdag 21 januari 2021 @ 09:31:
[...]

Doe eens een ipconfig van je pc
Het zou kunnen dat hij van pc naar router naar pi naar upstream gaat
Maar dan moet je wel de router kunnen vertrouwen dat dir alles naar de pi zet

Stel eens op je pc handmatig de dns van de pi in

Dan gaat het goed! Hij pakt dan direct de DNS server, en in mijn $_SERVER['REMOTE_ADDR'] krijg ik ook netjes mijn LAN ip terug. Voorzichtig hoera dus.

Mijn vraag moet dan dus worden: Hoe zorg ik ervoor dat alle devices direct met de DNS server praten ipv via de router? Ik neem aan dat je dat wel ergens in unify kunt instellen, right?

[laurens0619]

xilent_xage schreef op donderdag 21 januari 2021 @ 09:37:
[...]


Dan gaat het goed! Hij pakt dan direct de DNS server, en in mijn $_SERVER['REMOTE_ADDR'] krijg ik ook netjes mijn LAN ip terug. Voorzichtig hoera dus.

Mijn vraag moet dan dus worden: Hoe zorg ik ervoor dat alle devices direct met de DNS server praten ipv via de router? Ik neem aan dat je dat wel ergens in unify kunt instellen, right?

Zie mijn edit en zie google, usg is populair ding en genoeg over te vinden

[xilent_xage]

Fixed, alles werkt nu. Het was wel een flinke omzwerving door mijn netwerk, en dan blijkt het uiteindelijk zoiets simpels! Reuze bedankt allemaal