Conditional DNS in Unifi

[ibmpc]

Ik zit met een probleem met een supersimpel netwerkje. Toch krijg ik het niet voor elkaar.

Alle devices zijn Entra Joined, op twee devices na die in een legacy ADDS hangen. Dit is vanwege een legacy applicatie met kernelhardwaretoegang en een Kerberos Azure Files.

Lokaal netwerk:
192.168.111.0/24
Unifi IP: 192.168.111.1

Azure subnet:
192.168.112.0/24
DNS server: 192.168.112.4 (tevens ADDS, maar is nu niet relevant)

Tunnel is up. DHCP DNS staat op 192.168.112.4, maar dat is een dubbele SPOF (afhankelijk van tunnel en van single DNS). Maar alles resolved wel gewoon. Clients kunnen immers babbelen met 192.168.112.4. Maar ik wil geen SPOF, dus ik heb de unifi op Auto DNS gezet (DHCP DNS is dan 192.168.111.1) en een Conditional DNS ingesteld voor xxx.file.core.windows.net naar 192.168.112.5 en corp.xxx.com naar 192.168.112.4.

Dit werkt niet. Clients resolven niet meer naar alle interne adressen, wel naar publieke adressen. 192.168.112.4 is gewoon pingable vanaf clients. De S2S tunnel geeft ook weer als online. Maar wat ik ook doe, niets resolved. Als ik met SSH inlog op de Unifi dan kan ik alles publiek pingen maar niets pingen in 192.168.112.0/24.

Als ik een Public IP toewijs aan 192.168.112.4, ik het publieke IP adres van lokaal whitelist en ik stel als Conditional DNS het publieke IP adres van de DNS server in Azure in, dan resolved alles gewoon prima.

Alles duidt erop dat 192.168.111.2 t/m 192.168.111.254 wel een route naar 192.168.112.0/24 weet, maar 192.168.111.1 niet, terwijl 192.168.111.1 toch echt de device is die de S2S met Azure regelt.

Wat kan ik verder onderzoeken om aan 192.168.111.1 kenbaar te maken dat er een route is naar 192.168.112.0/24?

[FredvZ]

Is die tunnel een tunnel vanaf je clients of vanaf je UDM?

[ibmpc]

Basic SKU. Volgens mij ondersteunt die geen client VPN. Denk je dat ik naar VpnGw1 moet?

[FredvZ]

Ik heb 0,0 inzicht in de verschillende Azure-producten, dus daar kan ik weinig zinnigs over roepen.

Als je clients in 192.168.111.0/24 een route hebben naar 192.168.112.0/24 dan is er in theorie ook voor 192.168.111.1 een route naar 192.168.112.0/24. Het verkeer kan dan eventueel nog wel worden tegengehouden in de firewall van de UDM: Mag het verkeer van de UDM de tunnel in? En zo ja: met welk source IP gebeurd dat?

Gebruik je NAT in de tunnel of routeer je het verkeer direct? In het laatste geval: is er ook een route terug van 192.168.112.0/24 naar 192.168.111.0/24?

[Kabouterplop01]

FredvZ schreef op zaterdag 21 september 2024 @ 11:38:
Ik heb 0,0 inzicht in de verschillende Azure-producten, dus daar kan ik weinig zinnigs over roepen.

Als je clients in 192.168.111.0/24 een route hebben naar 192.168.112.0/24 dan is er in theorie ook voor 192.168.111.1 een route naar 192.168.112.0/24. Het verkeer kan dan eventueel nog wel worden tegengehouden in de firewall van de UDM: Mag het verkeer van de UDM de tunnel in? En zo ja: met welk source IP gebeurd dat?

Gebruik je NAT in de tunnel of routeer je het verkeer direct? In het laatste geval: is er ook een route terug van 192.168.112.0/24 naar 192.168.111.0/24?

Juist, dus zal er een tracert gedaan moeten worden (zowel heen als terug). Als er een route is, dan zit het hoger in de stack. (ACL...)

[ibmpc]

Kabouterplop01 schreef op zaterdag 21 september 2024 @ 14:21:
[...]


Juist, dus zal er een tracert gedaan moeten worden (zowel heen als terug). Als er een route is, dan zit het hoger in de stack. (ACL...)

Route vanaf een werkstation:

code:

C:\Windows\System32>tracert 192.168.112.4

Tracing route to 192.168.112.4 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  unifi.corp.xxx.com [192.168.111.1]
  2    19 ms    23 ms    23 ms  192.168.112.4

Trace complete.

Route vanaf de Unifi:

code:

traceroute to 192.168.112.4 (192.168.112.4), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Route vanaf een device in Azure naar de Unifi:

code:

C:\Windows\system32>tracert 192.168.111.1

Tracing route to 192.168.111.1 over a maximum of 30 hops

  1    22 ms    24 ms    23 ms  192.168.111.1

Trace complete.

Ping vanaf een device in Azure naar de Unifi:

code:

C:\Windows\system32>ping 192.168.111.1

Pinging 192.168.111.1 with 32 bytes of data:
Reply from 192.168.111.1: bytes=32 time=23ms TTL=64
Reply from 192.168.111.1: bytes=32 time=34ms TTL=64
Reply from 192.168.111.1: bytes=32 time=33ms TTL=64
Reply from 192.168.111.1: bytes=32 time=23ms TTL=64

Ping statistics for 192.168.111.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 23ms, Maximum = 34ms, Average = 28ms

Ping vanaf een device in Azure naar een device onprem:

code:

C:\Windows\system32>ping 192.168.111.3

Pinging 192.168.111.3 with 32 bytes of data:
Reply from 192.168.111.3: bytes=32 time=24ms TTL=127
Reply from 192.168.111.3: bytes=32 time=22ms TTL=127
Reply from 192.168.111.3: bytes=32 time=25ms TTL=127
Reply from 192.168.111.3: bytes=32 time=24ms TTL=127

Ping statistics for 192.168.111.3:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 22ms, Maximum = 25ms, Average = 23ms

Ping vanaf een device onprem naar een device in Azure:

code:

C:\Windows\system32>ping 192.168.112.4

Pinging 192.168.112.4 with 32 bytes of data:
Reply from 192.168.112.4: bytes=32 time<1ms TTL=128
Reply from 192.168.112.4: bytes=32 time<1ms TTL=128
Reply from 192.168.112.4: bytes=32 time<1ms TTL=128
Reply from 192.168.112.4: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.112.4:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

Ping vanaf de Unifi naar een device in Azure:

code:

PING 192.168.112.4 (192.168.112.4) 56(84) bytes of data.
^C
--- 192.168.112.4 ping statistics ---
33 packets transmitted, 0 received, 100% packet loss, time 33244ms

Relevante data van de routetabel op de Unifi:

code:

192.168.112.0   0.0.0.0         255.255.255.0   U     30     0        0 vti64

FredvZ schreef op zaterdag 21 september 2024 @ 11:38:

Als je clients in 192.168.111.0/24 een route hebben naar 192.168.112.0/24 dan is er in theorie ook voor 192.168.111.1 een route naar 192.168.112.0/24. Het verkeer kan dan eventueel nog wel worden tegengehouden in de firewall van de UDM: Mag het verkeer van de UDM de tunnel in? En zo ja: met welk source IP gebeurd dat?

Waar controleer ik dit?

Gebruik je NAT in de tunnel of routeer je het verkeer direct? In het laatste geval: is er ook een route terug van 192.168.112.0/24 naar 192.168.111.0/24?

Route terug is aanwezig, zie traceroutes boven. Ik geloof routes. NAT kan toch niet in een tunnel?

[ Voor 10% gewijzigd door ibmpc op 24-09-2024 01:35 ]

[FredvZ]

ibmpc schreef op maandag 23 september 2024 @ 19:37:
Waar controleer ik dit?

Aan de kant van de UDM:
https://192.168.111.1/net...s/security/firewall-rules

Route terug is aanwezig, zie traceroutes boven. Ik geloof routes. NAT kan toch niet in een tunnel?

In de tunnel zelf niet, het is wel mogelijk dat een firewall/router aan het eind van de tunnel NAT toepast. (bijvoorbeeld door al het verkeer met eigen IP-adres als source de tunnel in te sturen)

[ibmpc]

FredvZ schreef op dinsdag 24 september 2024 @ 10:33:
[...]

Aan de kant van de UDM:
https://192.168.111.1/net...s/security/firewall-rules

Alleen de default built-in regels:

Internet
• Allow Established/Related Traffic
• Block Invalid Traffic
• Block All Other Traffic
• Allow Established/Related Traffic
• Block Invalid Traffic
• Allow IPsec
• Allow ESP
• Allow WireGuard Server
• Block All Other Traffic

LAN
• Allow Network 192.168.111.0/24 Traffic (destination: any)
• Allow Network 192.168.111.0/24 Traffic (source: any)

Tijdelijk een ander merk router neergezet. Een ping vanuit deze router gaat wel door naar devices in Azure. Het lijkt dus alsof de Unifi alleen weet hoe het verkeer moet routeren naar 192.168.112.0/24 vanaf 192.168.111.2 t/m 192.168.111.254. Een probleem in Azure is hiermee vrijwel uitgesloten.

[ Voor 19% gewijzigd door ibmpc op 24-09-2024 20:17 ]

[ibmpc]

* schopje

Iemand enig idee?
Wat meer relevante gegevens:
UDM Pro, versie 4.0.6

Ik vind het sowieso vreemd dat de route wel bekend is:

code:

192.168.112.0   0.0.0.0         255.255.255.0   U     30     0        0 vti64

Maar dat alleen 192.168.111.2 t/m 192.168.111.254 de route naar 192.168.112.0/24 weten. 192.168.111.1 is de router maar weet zelf de route niet voor zichzelf, maar wel voor alle andere devices.

Een vervangende router van een ander merk weet wel de route naar 192.168.112.0/24 voor alle devices en zichzelf. Wat kan ik nog doen? Firmware downgrades?

[ Voor 3% gewijzigd door ibmpc op 26-09-2024 23:11 ]

[ibmpc]

* schopje

Handmatig een extra route aanmaken resulteert in het volledig verliezen van de route. Verbinding blijft actief, maar traffic stopt. 192.168.111.2 t/m 192.168.111.254 kunnen dan geen route meer vinden naar 192.168.112.0/24 en 192.168.111.1 kan ook nog steeds geen route vinden.

[sjorsjuhmaniac]

Goed, hier feedback van een noob ik hoop dat ergens op slaat;

Ik ken unifi niet specifiek maar dit is high level waar ik aan zit te denken:

Als clients van de router wel de route hebben en tunnel kunnen gebruiken dan lijkt het “te werken”.


Vanuit de router zelf werkt het schijnbaar niet? Ontgaat mij even waarom dat belangrijk is maar dat terzijde. Aah ik snap m nu, je clients kunnen 112.4 wel pingen maar resolven niets.
Kan het zijn dat je tunnel interface en je 11.1 interface elkaar niet kunnen bereiken ? Zitten die in een gezamenlijke bridge? Niet toevallig speciale dns block rule in de fw? Of beter, niet vergeten dns traffic toe te staan die richting op? Geen oude dst-nats die nog actief zijn omdat je vroeger dns ergens afving ofzo?

[ Voor 22% gewijzigd door sjorsjuhmaniac op 30-09-2024 18:40 ]

[MasterL]

Misschien een long shot maar wat is het SRC IP welke de Unifi gebruikt (bijvoorbeeld met ICMP)?
Zou het kunnen dat deze een SRC IP gebruikt anders als "192.168.111.0/24" waardoor de route terug simpelweg niet meer klopt? Ik ken de firewall van de Unifi niet zo goed maar als deze IPtables based is zou ik een "output" chain verwachten. Deze zie ik niet terug in jouw firewall rules.

[ibmpc]

sjorsjuhmaniac schreef op maandag 30 september 2024 @ 18:33:
Goed, hier feedback van een noob ik hoop dat ergens op slaat;

Ik ken unifi niet specifiek maar dit is high level waar ik aan zit te denken:

Als clients van de router wel de route hebben en tunnel kunnen gebruiken dan lijkt het “te werken”.


Vanuit de router zelf werkt het schijnbaar niet? Ontgaat mij even waarom dat belangrijk is maar dat terzijde. Aah ik snap m nu, je clients kunnen 112.4 wel pingen maar resolven niets.
Kan het zijn dat je tunnel interface en je 11.1 interface elkaar niet kunnen bereiken ? Zitten die in een gezamenlijke bridge? Niet toevallig speciale dns block rule in de fw? Of beter, niet vergeten dns traffic toe te staan die richting op? Geen oude dst-nats die nog actief zijn omdat je vroeger dns ergens afving ofzo?

Het slaat denk ik wel ergens op wat je zegt. De clients kunnen 192.168.112.4 wel pingen maar ze resolven niet. De oorzaak is omdat de clients 192.168.111.1 als DNS server hebben (de Unifi) maar 192.168.111.1 kan voor zichzelf geen route vinden naar 192.168.112.4.

Als ik de clients handmatig op DNS 192.168.112.4 zet, dan werkt alles prima. Omdat de Unifi wel een route weet naar 192.168.112.4 voor alles, behalve voor zichzelf. Heel vreemd dus. En ik begin het vermoeden te krijgen dat het hier om een softwarebug gaat. Als ik er een willekeurig ander merk router tussen hang, dan routeert de router (willekeurig ander merk op 192.168.111.1) wel gewoon naar 192.168.112.4.

MasterL schreef op dinsdag 1 oktober 2024 @ 09:43:
Misschien een long shot maar wat is het SRC IP welke de Unifi gebruikt (bijvoorbeeld met ICMP)?
Zou het kunnen dat deze een SRC IP gebruikt anders als "192.168.111.0/24" waardoor de route terug simpelweg niet meer klopt? Ik ken de firewall van de Unifi niet zo goed maar als deze IPtables based is zou ik een "output" chain verwachten. Deze zie ik niet terug in jouw firewall rules.

Dit haal ik uit de IP configuratie:

code:

br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.111.1  netmask 255.255.255.0  broadcast 0.0.0.0

Is dat iets waar je iets aan hebt?

-edit-

Via een andere tech het advies dat "Tunnel IP" mogelijk zou kunnen helpen in de IPSec tunnel settings. Ik heb deze ingesteld op 192.168.229.1 met mask /24. Daarna een static route aangemaakt:
Destination: 192.168.112.0/24
Type: Next Hop
Next Hop: 192.168.229.1

Nog steeds dit resultaat:

code:

traceroute to 192.168.112.4 (192.168.112.4), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *

Met een static route zou de Unifi toch op z'n minst een volgend IP adres moeten weten? Ik heb het idee dat de Unifi z'n eigen routetabellen negeert.

[ Voor 11% gewijzigd door ibmpc op 02-10-2024 21:24 ]

[sjorsjuhmaniac]

ibmpc schreef op woensdag 2 oktober 2024 @ 21:18:
[...]

Het slaat denk ik wel ergens op wat je zegt. De clients kunnen 192.168.112.4 wel pingen maar ze resolven niet. De oorzaak is omdat de clients 192.168.111.1 als DNS server hebben (de Unifi) maar 192.168.111.1 kan voor zichzelf geen route vinden naar 192.168.112.4.

in je openingspost geef je aan dat de dhcp dns 112.4 is, niet 111.1. Waarom hebben je clients 111.1?

als je per se 111.1 voor je clients wil bijven gebruiken zal je unifi moeten snappen dat het uiteindelijk naar 112.4 moet. Dus jij moet de unifi vertellen dat het verkeer doorgestuurd meot worden naar 112.4. Standaard zal hij dat niet doen, hooguit naar de upstream aan de WAN.
Als je die optie niet hebt (dns forward) dan kan je het nog forceren op fw niveau door een nat rule aan te maken. Ik ben ook alleen maar bekend met iptables firewalls en daar hebben we deze table. Je zal in dit geval even verder moeten zoeken in de documentatie hoe dat voor unifi werkt.

Als ik de clients handmatig op DNS 192.168.112.4 zet, dan werkt alles prima. Omdat de Unifi wel een route weet naar 192.168.112.4 voor alles, behalve voor zichzelf. Heel vreemd dus.

houd 2 dingen goed uit elkaar:
- een pakketje met dest-ip 112.4 komend van een client gaat CORRECT door de unifi heen. Die klopt met de route
- een dns request naar 111.1 heeft dus GEEN dest-ip van 112.4. De unifi zal zelf moeten bepalen dat dns verkeer doorgestuurd moet worden naar 112.4

Je opmerking "behalve voor zichzelf" begrijp ik nu steeds minder. Ik vermoed namelijk dat je zelf bovenstaande 2 puten mixt en niet goed voor jezelf uit elkaar houdt.

En ik begin het vermoeden te krijgen dat het hier om een softwarebug gaat. Als ik er een willekeurig ander merk router tussen hang, dan routeert de router (willekeurig ander merk op 192.168.111.1) wel gewoon naar 192.168.112.4.

bug zou kunnen. maar mogelijk dat de andere merken routers zonder config, aannmen dat de dns nu op 112.4 zit? Ik heb mikrotik routers, die nemen 0,0 aan en ik moet ze alles zelf vertellen. Mijn kpn standaard router deed veel standaard dingen ook 'goed' zonder dat ik dat moest configuren

[...]

Dit haal ik uit de IP configuratie:

code:

br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.111.1  netmask 255.255.255.0  broadcast 0.0.0.0

Is dat iets waar je iets aan hebt?

Nee niet echt. het verteld dat je interface, met address 111.1, een birdge is (br0 == bridge 0) dus dat is de gehele bridge. Geeft wel een hele grote kans dat je hardware interface en de tunnel wel in dezelfde bridge hangen omdat pingen van clients naar 112.x subnet wel lukt

-edit-

Via een andere tech het advies dat "Tunnel IP" mogelijk zou kunnen helpen in de IPSec tunnel settings. Ik heb deze ingesteld op 192.168.229.1 met mask /24. Daarna een static route aangemaakt:
Destination: 192.168.112.0/24
Type: Next Hop
Next Hop: 192.168.229.1

Nog steeds dit resultaat:

code:

traceroute to 192.168.112.4 (192.168.112.4), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *

Met een static route zou de Unifi toch op z'n minst een volgend IP adres moeten weten? Ik heb het idee dat de Unifi z'n eigen routetabellen negeert.

Waar wordt bovenstaande tracetoure op uitgevoerd? op de unifi router dmv een console interface?
Zoals @MasterL aangaf, vanaf welk ip/interface wordt er nu een pakketje gestuurd naar 112.4? weet je zeker dat dit vanaf de br0 (111.1) is?
Wat is thet 229.1 subnet? is dat ook een subnet wat in je lans actief is? Ik heb beter gelezen en zie dat 229.1 je tunnel ip is. wat je hier bedoel is denk ik het ip van je tunnel interface. Allemaal prima maar je tunnel functioneerde want je kon pingen. Ik zou even wegblijven van meer van dergelijke aanpassingen net zoals routes en proberen een dns forward in te stellen als je per se 111.1 als dns aan je clients wil blijven geven.

[ Voor 4% gewijzigd door sjorsjuhmaniac op 02-10-2024 21:48 ]

[ibmpc]

sjorsjuhmaniac schreef op woensdag 2 oktober 2024 @ 21:40:
[...]


in je openingspost geef je aan dat de dhcp dns 112.4 is, niet 111.1. Waarom hebben je clients 111.1?

Omdat ik wil dat alle DNS traffic naar 1.1.1.1 en 1.0.0.1 gaat. Er is een conditional DNS regel naar 192.168.112.4 voor twee domeinen (corp.xxx.com en xxx.file.core.windows.net).

DNS is niet de issue, de issue is dat de UDM niets kan bereiken op 192.168.112.0/24. Alle devices in 192.168.112.0/24 kunnen echter wel pingen naar 192.168.111.1. 192.168.111.1 kan niet pingen naar 192.168.112.0/24 maar 192.168.111.2 t/m .111.254 kunnen wel alles pingen in 192.168.112.0/24.

houd 2 dingen goed uit elkaar:
- een dns request naar 111.1 heeft dus GEEN dest-ip van 112.4. De unifi zal zelf moeten bepalen dat dns verkeer doorgestuurd moet worden naar 112.4

Klopt, er is een conditional DNS forwarder naar 192.168.112.4. Maar DNS is niet de issue, de issue is dat de UDM niets over de tunnel kan bereiken (dus ook geen DNS, maar eigenlijk helemaal niets).

Je opmerking "behalve voor zichzelf" begrijp ik nu steeds minder. Ik vermoed namelijk dat je zelf bovenstaande 2 puten mixt en niet goed voor jezelf uit elkaar houdt.

UDM negeert de tunnel voor zichzelf, maar gebruikt de tunnel wel voor alle devices. UDM is wel bereikbaar vanuit Azure.

bug zou kunnen. maar mogelijk dat de andere merken routers zonder config, aannmen dat de dns nu op 112.4 zit? Ik heb mikrotik routers, die nemen 0,0 aan en ik moet ze alles zelf vertellen. Mijn kpn standaard router deed veel standaard dingen ook 'goed' zonder dat ik dat moest configuren

Dat zou kunnen, maar ook een statische route naar 192.168.112.0/24 helpt de UDM niet.

Waar wordt bovenstaande tracetoure op uitgevoerd? op de unifi router dmv een console interface?
Zoals @MasterL aangaf, vanaf welk ip/interface wordt er nu een pakketje gestuurd naar 112.4? weet je zeker dat dit vanaf de br0 (111.1) is?
Wat is thet 229.1 subnet? is dat ook een subnet wat in je lans actief is? Ik heb beter gelezen en zie dat 229.1 je tunnel ip is. wat je hier bedoel is denk ik het ip van je tunnel interface. Allemaal prima maar je tunnel functioneerde want je kon pingen. Ik zou even wegblijven van meer van dergelijke aanpassingen net zoals routes en proberen een dns forward in te stellen als je per se 111.1 als dns aan je clients wil blijven geven.

Met SSH op 192.168.111.1 wordt de traceroute uitgevoerd. Dat 192.168.229.1 subnet is een "Tunnel IP" setting in de UDM wat ik als test even had aangezet. Staat inmiddels weer uit. Verandert niets.

Hoe kan ik controleren of, als ik met SSH op 192.168.111.1 inlog, dat mijn icmp traffic origineert uit 192.168.111.1 en niet een of ander andere interface? Want ik denk dat wat je zegt weleens zou kloppen, de UDM gebruikt misschien een totaal andere interface die helemaal niet bij de tunnel kan komen?

[sjorsjuhmaniac]

ibmpc schreef op woensdag 2 oktober 2024 @ 22:27:
[...]
Omdat ik wil dat alle DNS traffic naar 1.1.1.1 en 1.0.0.1 gaat. Er is een conditional DNS regel naar 192.168.112.4 voor twee domeinen (corp.xxx.com en xxx.file.core.windows.net).

aah yes sorry, dat is waar. Was ik vergeten. dus het zit echt alleen in de UDM die niet naar de 112.4 kan connecten.

Met SSH op 192.168.111.1 wordt de traceroute uitgevoerd. Dat 192.168.229.1 subnet is een "Tunnel IP" setting in de UDM wat ik als test even had aangezet. Staat inmiddels weer uit. Verandert niets.

Hoe kan ik controleren of, als ik met SSH op 192.168.111.1 inlog, dat mijn icmp traffic origineert uit 192.168.111.1 en niet een of ander andere interface? Want ik denk dat wat je zegt weleens zou kloppen, de UDM gebruikt misschien een totaal andere interface die helemaal niet bij de tunnel kan komen?

kan je pakketjes capturen? op de unifi of met wireshark ergens? anders zou ik het ook niet weten tbh.

[ Voor 3% gewijzigd door sjorsjuhmaniac op 02-10-2024 22:58 ]

[sjorsjuhmaniac]

als ik ff google zou je tcpdump op de udm moeten hebben. Je kan dan bv eens filteren op alles naar en alles van 112.4

Bash:

$ tcpdump host 192.168.112.4

of alleen op dns poort 53 als je te veel traffic ziet

Bash:

$ tcpdump host 192.168.112.4 and tcp port 53 or host 192.168.112.4 and udp port 53

[ Voor 32% gewijzigd door sjorsjuhmaniac op 02-10-2024 23:12 ]

[ibmpc]

sjorsjuhmaniac schreef op woensdag 2 oktober 2024 @ 22:57:
[...]


aah yes sorry, dat is waar. Was ik vergeten. dus het zit echt alleen in de UDM die niet naar de 112.4 kan connecten.

Precies dit

kan je pakketjes capturen? op de unifi of met wireshark ergens? anders zou ik het ook niet weten tbh.

Ik moest je commando iets aanpassen want anders pakt hij niets:

code:

tcpdump host 192.168.112.4 and icmp --interface vti64

vti64 is de VPN interface.

Dit kwam er terug toen ik van een device in het lokale netwerk de DNS server ging pingen:

code:

16:59:52.745813 IP 192.168.111.3 > 192.168.112.4: ICMP echo request, id 1, seq 15, length 40
16:59:52.774728 IP 192.168.112.4 > 192.168.111.3: ICMP echo reply, id 1, seq 15, length 40
16:59:53.758643 IP 192.168.111.3 > 192.168.112.4: ICMP echo request, id 1, seq 16, length 40
16:59:53.782700 IP 192.168.112.4 > 192.168.111.3: ICMP echo reply, id 1, seq 16, length 40
16:59:54.774368 IP 192.168.111.3 > 192.168.112.4: ICMP echo request, id 1, seq 17, length 40
16:59:54.798598 IP 192.168.112.4 > 192.168.111.3: ICMP echo reply, id 1, seq 17, length 40
16:59:55.777199 IP 192.168.111.3 > 192.168.112.4: ICMP echo request, id 1, seq 18, length 40
16:59:55.794539 IP 192.168.112.4 > 192.168.111.3: ICMP echo reply, id 1, seq 18, length 40

Netjes een reply terug. Maar, hierna snap ik het niet meer, wanneer ik een tweede SSH naar de UDM open en een ping naar 192.168.112.4 probeer vanaf de UDM:

code:

16:59:59.730758 IP xxx-xxx-xxx-xxx.isp.net > 192.168.112.4: ICMP echo request, id 17736, seq 1, length 64
17:00:00.732347 IP xxx-xxx-xxx-xxx.isp.net > 192.168.112.4: ICMP echo request, id 17736, seq 2, length 64
17:00:01.745367 IP xxx-xxx-xxx-xxx.isp.net > 192.168.112.4: ICMP echo request, id 17736, seq 3, length 64
17:00:02.775447 IP xxx-xxx-xxx-xxx.isp.net > 192.168.112.4: ICMP echo request, id 17736, seq 4, length 64
17:00:03.815393 IP xxx-xxx-xxx-xxx.isp.net > 192.168.112.4: ICMP echo request, id 17736, seq 5, length 64

De publieke WAN IP DNS naam/adres heb ik vervangen door xxx-xxx-xxx-xxx.isp.net in dit deze copypaste.

Wat ik hier uit begrijp is dat de UDM een ping uitgaand probeert te sturen vanaf het IP adres van de WAN interface als afzender? Waarom zie ik de uitgaande traffic (zonder reply) dan op de vti64 (VPN) interface?

[sjorsjuhmaniac]

ibmpc schreef op donderdag 3 oktober 2024 @ 00:09:
[...]

Ik moest je commando iets aanpassen want anders pakt hij niets:

code:

tcpdump host 192.168.112.4 and icmp --interface vti64

vti64 is de VPN interface.

Dit kwam er terug toen ik van een device in het lokale netwerk de DNS server ging pingen:

code:

16:59:52.745813 IP 192.168.111.3 > 192.168.112.4: ICMP echo request, id 1, seq 15, length 40
16:59:52.774728 IP 192.168.112.4 > 192.168.111.3: ICMP echo reply, id 1, seq 15, length 40
16:59:53.758643 IP 192.168.111.3 > 192.168.112.4: ICMP echo request, id 1, seq 16, length 40
16:59:53.782700 IP 192.168.112.4 > 192.168.111.3: ICMP echo reply, id 1, seq 16, length 40
16:59:54.774368 IP 192.168.111.3 > 192.168.112.4: ICMP echo request, id 1, seq 17, length 40
16:59:54.798598 IP 192.168.112.4 > 192.168.111.3: ICMP echo reply, id 1, seq 17, length 40
16:59:55.777199 IP 192.168.111.3 > 192.168.112.4: ICMP echo request, id 1, seq 18, length 40
16:59:55.794539 IP 192.168.112.4 > 192.168.111.3: ICMP echo reply, id 1, seq 18, length 40

Netjes een reply terug.

dit ziet er goed/normaal uit. Kan je voor de zekerheid ook nog eens capturen voor een dns request? op linux hosts kan je op de cli de dns server aangeven voor een enkele request bv dns resolve voor google.nl door dns-server 8.8.8.8

Bash:

host google.nl 8.8.8.8
# of
dig +short @8.8.8.8 google.nlf
# dus dan wordt het
host je.speciale.domein.dat.naar.112.4.moet.gaan 192.168.112.4

Windows heb ik geen verstand van.

Vergeet niet om je ICMP filter weg te halen

Maar, hierna snap ik het niet meer, wanneer ik een tweede SSH naar de UDM open en een ping naar 192.168.112.4 probeer vanaf de UDM:

code:

16:59:59.730758 IP xxx-xxx-xxx-xxx.isp.net > 192.168.112.4: ICMP echo request, id 17736, seq 1, length 64
17:00:00.732347 IP xxx-xxx-xxx-xxx.isp.net > 192.168.112.4: ICMP echo request, id 17736, seq 2, length 64
17:00:01.745367 IP xxx-xxx-xxx-xxx.isp.net > 192.168.112.4: ICMP echo request, id 17736, seq 3, length 64
17:00:02.775447 IP xxx-xxx-xxx-xxx.isp.net > 192.168.112.4: ICMP echo request, id 17736, seq 4, length 64
17:00:03.815393 IP xxx-xxx-xxx-xxx.isp.net > 192.168.112.4: ICMP echo request, id 17736, seq 5, length 64

De publieke WAN IP DNS naam/adres heb ik vervangen door xxx-xxx-xxx-xxx.isp.net in dit deze copypaste.

Wat ik hier uit begrijp is dat de UDM een ping uitgaand probeert te sturen vanaf het IP adres van de WAN interface als afzender? Waarom zie ik de uitgaande traffic (zonder reply) dan op de vti64 (VPN) interface?

Mooi, dit bevestigd dus dat wat je test iig niet vanaf interface 111.1 naar je tunnel gaat nu kun je mooi zien dat hij via de wan 112.4 zoek, gaat m niet lukken natuurlijk omdat er geen route terug is naar je WAN, vanaf de DNS server. Technisch gezien zou je het kunnen oplossen door voor je wan ip een route aan te maken aan de andere kant van je tunnel maar dat is gepruts. De request zou niet vanaf je wanip moeten komen.

Als ik het goed begrijp draait de udm DNSMASQ als dns server.

Post je routes eens aub.

Bash:

$ route

Mogelijk door al het ge-probeert dat je routes niet meer kloppen?

Daarnaast, het wil niet zeggen dat als je via ssh inlogt, dat je dan exact hetzelfde doet als wanneer de router pakketjes afhandelt, maar dat is iets voor later om te valideren.

Heb je een andere manier op cli op de router te krijgen? op de mikrotiks kan ik via de admin interface een shell krijgen via de webinterface. Heb je op de UDM ook zoiets?

[ Voor 6% gewijzigd door sjorsjuhmaniac op 03-10-2024 00:55 ]

[ibmpc]

sjorsjuhmaniac schreef op donderdag 3 oktober 2024 @ 00:36:
[...]


dit ziet er goed/normaal uit. Kan je voor de zekerheid ook nog eens capturen voor een dns request? op linux hosts kan je op de cli de dns server aangeven voor een enkele request bv dns resolve voor google.nl door dns-server 8.8.8.8

Bash:

host google.nl 8.8.8.8
# of
dig +short @8.8.8.8 google.nlf
# dus dan wordt het
host je.speciale.domein.dat.naar.112.4.moet.gaan 192.168.112.4

Bij deze requests:

code:

host xxx.file.core.windows.net
connection timed out; no servers could be reached

host computernaam.corp.xxx.com
connection timed out; no servers could be reached

Krijg ik dit:

code:

16:05:52.725560 IP xxx-xxx-xxx-xxx.isp.net.52685 > 192.168.112.4.domain: 54766+ A? xxx.file.core.windows.net. (51)
16:06:04.467055 IP xxx-xxx-xxx-xxx.isp.net.52486 > 192.168.112.4.domain: 46663+ A? computernaam.corp.xxx.com. (45)

Mooi, dit bevestigd dus dat wat je test iig niet vanaf interface 111.1 naar je tunnel gaat nu kun je mooi zien dat hij via de wan 112.4 zoek, gaat m niet lukken natuurlijk omdat er geen route terug is naar je WAN, vanaf de DNS server. Technisch gezien zou je het kunnen oplossen door voor je wan ip een route aan te maken aan de andere kant van je tunnel maar dat is gepruts. De request zou niet vanaf je wanip moeten komen.

Ik heb een tijdelijke workaround door gewoon TCP en UDP/53 open te zetten in Azure met een IP restrictie voor het WAN IP adres van de UDM, en dan stel ik op de UDM het externe IP adres van de DNS server in Azure in. Dan resolvt hij natuurlijk wel gewoon, alleen dan gaat de traffic over het blote internet. Het bevestigt in ieder geval dat conditional DNS werkt en dat de toegang tot de tunnel vanaf de UDM het probleem is.

Als ik het goed begrijp draait de udm DNSMASQ als dns server.

Post je routes eens aub.

Bash:

$ route

Mogelijk door al het ge-probeert dat je routes niet meer kloppen?

Ik ga alle customizations controleren. Het is een supersimpel netwerk, geen static routes en alleen twee conditional DNS forwarders. En een IPSec tunnel naar Azure (Basic SKU). Dus op twee dingen na gewoon een huis-tuin-en-keuken-netwerk.

Dit is de routetabel:

code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
[public IP]     0.0.0.0         255.255.255.240 U     0      0        0 eth8
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth7
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wgsrv1
192.168.1.2     0.0.0.0         255.255.255.255 UH    0      0        0 wgsrv1
192.168.1.3     0.0.0.0         255.255.255.255 UH    0      0        0 wgsrv1
192.168.1.4     0.0.0.0         255.255.255.255 UH    0      0        0 wgsrv1
192.168.111.0   0.0.0.0         255.255.255.0   U     0      0        0 br0
192.168.112.0   0.0.0.0         255.255.255.0   U     30     0        0 vti64

Moet heel eerlijk zeggen dat ik 192.168.0.0/24 en 192.168.1.0/24 niet herken.

Maar, vraag:
Als een interne device gewoon z'n eigen interne IP mee geeft bij een ping naar 192.168.112.4:

code:

16:59:52.745813 IP 192.168.111.3 > 192.168.112.4: ICMP echo request, id 1, seq 15, length 40
16:59:52.774728 IP 192.168.112.4 > 192.168.111.3: ICMP echo reply, id 1, seq 15, length 40

Maar de UDM geeft z'n WAN IP adres mee:

code:

16:59:59.730758 IP xxx-xxx-xxx-xxx.isp.net > 192.168.112.4: ICMP echo request, id 17736, seq 1, length 64

Hoe weet Azure dan waar het verkeer terug naartoe moet? Stuurt Azure het verkeer misschien terug naar de WAN interface van de UDM omdat de UDM het WAN IP adres mee geeft als afzender?

Daarnaast, het wil niet zeggen dat als je via ssh inlogt, dat je dan exact hetzelfde doet als wanneer de router pakketjes afhandelt, maar dat is iets voor later om te valideren.

Heb je een andere manier op cli op de router te krijgen? op de mikrotiks kan ik via de admin interface een shell krijgen via de webinterface. Heb je op de UDM ook zoiets?

Ik heb eigenlijk geen idee, ik werk voor het eerst met UDM... Ik ga op zoek

[ibmpc]

sjorsjuhmaniac schreef op donderdag 3 oktober 2024 @ 00:36:
[...]

Mooi, dit bevestigd dus dat wat je test iig niet vanaf interface 111.1 naar je tunnel gaat nu kun je mooi zien dat hij via de wan 112.4 zoek, gaat m niet lukken natuurlijk omdat er geen route terug is naar je WAN, vanaf de DNS server. Technisch gezien zou je het kunnen oplossen door voor je wan ip een route aan te maken aan de andere kant van je tunnel maar dat is gepruts. De request zou niet vanaf je wanip moeten komen.

Fixed.

Ik heb iets heel controversieel gedaan. Ik heb Wireshark op de DNS server 192.168.112.4 geinstalleerd en ben gaan packetmonitoren. Wat blijkt, alle verkeer van 192.168.111.2 t/m 111.254 komt gewoon binnen op 192.168.112.4, zoals verwacht.

Mijn vermoeden was dat verkeer van 192.168.111.1 wel binnen zou komen, maar met een verkeerd reply adres. Dat was een verkeerd vermoeden. Het verkeer kwam gewoon helemaal niet binnen.

Nu weet ik dat Azure tunnels best forgiving zijn en eigenlijk op iedere huis-tuin-en-keuken-router wel kan origineren, op een specifieke setting na (Azure gateways draaien gewoon op 2x een Linux VM die je als dienst afneemt in Azure). ESP lifetime moet op 27000 staan, anders kun je vreemd gedrag krijgen. Toch maar opnieuw in de IPsec settings van de UDM gekeken en wederom kom ik de setting "Tunnel IP" tegen. Geen idee wat het is. De omschrijving:

IP address used inside the VPN tunnel. Required when using OSPF. Use a private IP address that does not overlap with other networks.

Dus een random IP adres gebruikt, 192.168.229.1/24. In Azure naast 192.168.111.0/24 ook 192.168.229.0/24 gegeven. Dit is een belangrijke stap, want anders snapt Azure niet dat verkeer terug de tunnel in moet.

Ping vanaf 192.168.111.1 naar 192.168.112.4 werkt!
Conditional DNS forwarder werkt over de tunnel!

Ik heb nog steeds geen idee wat Tunnel IP is, behalve dat het een IP adres is dat blijkbaar de tunnel in kan, maar het werkt dus het gaat de documentatie in.

Traceroute naar 192.168.112.4 faalt nog steeds vanaf 192.168.111.1:

code:

traceroute to 192.168.112.4 (192.168.112.4), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *

Maar, de volgende regel:

code:

tcpdump host 192.168.112.4 and icmp --interface vti64

Geeft nu compleet ander gedrag. In plaats van een externe DNS hostname als source, staat er nu het IP adres dat ik in Tunnel IP heb opgegeven, en... een reply!

code:

23:02:55.428237 IP 192.168.229.1 > 192.168.112.4: ICMP echo request, id 43265, seq 1, length 64
23:02:55.452374 IP 192.168.112.4 > 192.168.229.1: ICMP echo reply, id 43265, seq 1, length 64

Er zijn best veel bronnen op internet die Azure tunnels op UDMs uitleggen, maar dit van de Tunnel IP wordt in geen enkele genoemd. Fixed, dus ik ben blij. Hopelijk heeft iemand anders er iets aan. Thanks!

[MasterL]

Sorry maar ik zou dit niet zo documenteren en volgens mij heb je het "echte" probleem ook niet opgelost.
Je doet een ping met als source "192.168.229.1" (UDM neem ik aan?) maar in je routing table bestaat dat netwerk helemaal niet, dit subnet gaat dus nooit functioneren.

Wat doet bijvoorbeeld:
traceroute -I br0 192.168.112.4 of traceroute -s 192.168.111.1 192.168.112.4 op de UDM?
Als dit werk werkt en een "normale" traceroute niet weet je gewoon dat de UDM het verkeerde SRC IP mee stuurt en kan je dit netjes oplossen.

De UDM zou toch normaal gewoon het Azure subnet moeten kunnen bereiken?

[ibmpc]

MasterL schreef op donderdag 3 oktober 2024 @ 14:03:
Sorry maar ik zou dit niet zo documenteren en volgens mij heb je het "echte" probleem ook niet opgelost.
Je doet een ping met als source "192.168.229.1" (UDM neem ik aan?) maar in je routing table bestaat dat netwerk helemaal niet, dit subnet gaat dus nooit functioneren.

Het echte probleem is denk ik een fout in de firmware van UDM. Van wat ik elders begrijp is Tunnel IP een nieuwe feature. Blijkbaar zitten er gewoon nog bugs in.

Enerzijds werkt Azure VPN Basic SKU prima met alle huis-tuin-en-keuken-routers. De dienst die je afneemt in Azure is op de backend gewoon 2x een Linux VM. Anderzijds is het de vraag of UDM wel de meest geschikte router is als je moet afwijken van de Microsoft documentatie.

Voor nu werkt het prima. De UDM kan z'n DNS queries voor deze subdomeinen gewoon forwarden. Ik ga deze case wel inschieten bij Unifi, want deze bug moet wel worden opgelost. Documentatie is denk ik juist bedoeld om dit soort quirks bij te houden, zodat afdeling die het straks gaat beheren kan opzoeken waarom bepaalde keuzes zijn gemaakt en er niet ineens change requests worden ingeschoten zonder de juiste informatie vooraf.

Wat doet bijvoorbeeld:
traceroute -I br0 192.168.112.4

code:

traceroute -I br0 192.168.112.4
br0: Name or service not known

traceroute -s 192.168.111.1 192.168.112.4 op de UDM?

code:

traceroute -s 192.168.111.1 192.168.112.4
traceroute to 192.168.112.4 (192.168.112.4), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Bovenstaande is trouwens met de voor mij onbekende Tunnel IP feature ingeschakeld.

Als dit werk werkt en een "normale" traceroute niet weet je gewoon dat de UDM het verkeerde SRC IP mee stuurt en kan je dit netjes oplossen.

Wat stel je voor?

De UDM zou toch normaal gewoon het Azure subnet moeten kunnen bereiken?

Nou, dat is dus precies het probleem. Ik heb een aantal merken geprobeerd en de UDM is dus de enige die het subnet niet kan bereiken voor zichzelf.

[sjorsjuhmaniac]

ibmpc schreef op donderdag 3 oktober 2024 @ 01:18:


Dit is de routetabel:

code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
[public IP]     0.0.0.0         255.255.255.240 U     0      0        0 eth8
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth7
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wgsrv1
192.168.1.2     0.0.0.0         255.255.255.255 UH    0      0        0 wgsrv1
192.168.1.3     0.0.0.0         255.255.255.255 UH    0      0        0 wgsrv1
192.168.1.4     0.0.0.0         255.255.255.255 UH    0      0        0 wgsrv1
192.168.111.0   0.0.0.0         255.255.255.0   U     0      0        0 br0
192.168.112.0   0.0.0.0         255.255.255.0   U     30     0        0 vti64

Moet heel eerlijk zeggen dat ik 192.168.0.0/24 en 192.168.1.0/24 niet herken.

Goed dat het soort van werkt maar in je routes zie ik wel je probleem terug: alles gaat naar je wan want je gw address is 0.0.0.0. Imho moet je 112 range als gw het ip van je tunnel hebben/ van je virt adapter hebben


Maar dat vind ik ook van je 111 range. Die zou een gw van je eth poort moeten hebben of je bridge

[ Voor 5% gewijzigd door sjorsjuhmaniac op 04-10-2024 08:45 ]

[MasterL]

sjorsjuhmaniac schreef op vrijdag 4 oktober 2024 @ 08:42:
[...]


Goed dat het soort van werkt maar in je routes zie ik wel je probleem terug: alles gaat naar je wan want je gw address is 0.0.0.0. Imho moet je 112 range als gw het ip van je tunnel hebben/ van je virt adapter hebben


Maar dat vind ik ook van je 111 range. Die zou een gw van je eth poort moeten hebben of je bridge

Dit is toch niet zo raar? Dit is een interface route die hebben normaal gesproken geen gateway of anders staat hier het broadcast address.
Als ik deze route table lees zou ik juist zeggen dat al het verkeer naar 112 naar de tunnel if (vti64) wordt gestuurd, de vraag is alleen met welk src adres? Misschien geeft de UDM simpelweg het verkeerde SRC adres mee en/of is de SRCNAT/masquerade wel (onterecht) actief in de tunnel vanaf "local" traffic.
Deze link bespreekt dit probleem volgens mij:

https://community.ui.com/...e4-4240-a696-f73a12d8ba2f

TS is dit niet de enige die hier tegenaan loopt

[ibmpc]

MasterL schreef op vrijdag 4 oktober 2024 @ 09:21:
[...]


de vraag is alleen met welk src adres? Misschien geeft de UDM simpelweg het verkeerde SRC adres mee en/of is de SRCNAT/masquerade wel (onterecht) actief in de tunnel vanaf "local" traffic.

Dit bedoel je?

code:

listening on vti64, link-type RAW (Raw IP), snapshot length 262144 bytes
11:13:51.108192 IP 68.xx.xx.xx > 192.168.112.4: ICMP echo request, id 33877, seq 1, length 64
11:13:52.145373 IP 68.xx.xx.xx > 192.168.112.4: ICMP echo request, id 33877, seq 2, length 64
11:13:53.146318 IP 68.xx.xx.xx > 192.168.112.4: ICMP echo request, id 33877, seq 3, length 64
11:13:54.215383 IP 68.xx.xx.xx > 192.168.112.4: ICMP echo request, id 33877, seq 4, length 64

En een ping vanaf een computer in het netwerk:

code:

listening on vti64, link-type RAW (Raw IP), snapshot length 262144 bytes
11:15:20.196286 IP 192.168.111.180 > 192.168.112.4: ICMP echo request, id 1, seq 17, length 40
11:15:20.223447 IP 192.168.112.4 > 192.168.111.180: ICMP echo reply, id 1, seq 17, length 40
11:15:21.213806 IP 192.168.111.180 > 192.168.112.4: ICMP echo request, id 1, seq 18, length 40
11:15:21.237995 IP 192.168.112.4 > 192.168.111.180: ICMP echo reply, id 1, seq 18, length 40
11:15:22.230280 IP 192.168.111.180 > 192.168.112.4: ICMP echo request, id 1, seq 19, length 40
11:15:22.254600 IP 192.168.112.4 > 192.168.111.180: ICMP echo reply, id 1, seq 19, length 40
11:15:23.247905 IP 192.168.111.180 > 192.168.112.4: ICMP echo request, id 1, seq 20, length 40
11:15:23.275465 IP 192.168.112.4 > 192.168.111.180: ICMP echo reply, id 1, seq 20, length 40

Waarom zou de UDM een public IP willen gebruiken in de tunnel?

Deze link bespreekt dit probleem volgens mij:

https://community.ui.com/...e4-4240-a696-f73a12d8ba2f

TS is dit niet de enige die hier tegenaan loopt

Ik heb een support case geopend bij Unifi want die Tunnel IP feature die het probleem mitigeert, is er eigenlijk helemaal niet voor bedoeld. Ik heb het wel als tijdelijke workaround in onze documentatie opgenomen zodat de beheerafdeling er iets mee kan.

[MasterL]

ibmpc schreef op vrijdag 4 oktober 2024 @ 18:28:
[...]
Dit bedoel je?

Ja inderdaad! Het is ondertussen duidelijk dat een ping/traceroute vanaf een andere apparaat als de UDM wel werkt. In IPtables hit deze ook een andere "chain" namelijk de forward chain i.p.v. de output chain.

ibmpc schreef op vrijdag 4 oktober 2024 @ 18:28:
[...]

Waarom zou de UDM een public IP willen gebruiken in de tunnel?

[...]

Ik heb een support case geopend bij Unifi want die Tunnel IP feature die het probleem mitigeert, is er eigenlijk helemaal niet voor bedoeld. Ik heb het wel als tijdelijke workaround in onze documentatie opgenomen zodat de beheerafdeling er iets mee kan.

Goeie vraag! Normaal gesproken wil je dit niet. Je zou verwachten als je in de IPSEC config een local subnet opgeeft dat verbindingen naar dit remote subnet wel als SRC IP een (lokaal) geconfigureerd IP-adres pakt vanuit het local subnet. Dus of:
1: Bovenstaande gebeurt simpelweg niet.
2: Er is geen NAT exclude waardoor er soort van SRCNAT actief is binnen de tunnel wat jij in dit geval niet wil.

Het lijkt mij in ieder geval voor de Unify support niet zo ingewikkeld om op te lossen.

[ibmpc]

MasterL schreef op maandag 7 oktober 2024 @ 13:32:
[...]


Goeie vraag! Normaal gesproken wil je dit niet. Je zou verwachten als je in de IPSEC config een local subnet opgeeft dat verbindingen naar dit remote subnet wel als SRC IP een (lokaal) geconfigureerd IP-adres pakt vanuit het local subnet. Dus of:
1: Bovenstaande gebeurt simpelweg niet.
2: Er is geen NAT exclude waardoor er soort van SRCNAT actief is binnen de tunnel wat jij in dit geval niet wil.

Ik wist echt niet dat je NAT kon toepassen in een tunnel, het lijkt mij compleet overbodig

Het lijkt mij in ieder geval voor de Unify support niet zo ingewikkeld om op te lossen.

Support is er mee bezig, alleen is het licht nog niet gaan branden. Er blijft worden gehamerd op DNS, dus het is nu vooral steeds hetzelfde doen, screenshots sturen, taakjes uitvoeren, etc.

[ibmpc]

Antwoord gekregen van Unifi:

This configuration [Tunnel IP] is necessary to reach the UniFi Gateways, and it needs to be allowed at the remote site too. The tunnel IP subnet should be non-overlapping.

Dus een volledige configuratie voor een tunnel tussen UDM en Azure (of wellicht andere aanbieders), is een Tunnel IP vereist.