Port forwarding op Unifi USG in DMZ

[Sam___D]

Het lukt mij niet om port forwarding aan de praat te krijgen via mijn Unifi USG. De USG zelf staat in de DMZ op Mijn Telenet. De forwarding is van een publieke poort naar een Docker container op het macvlan netwerk op mijn Synology NAS, wat een fixed intern IP heeft.

Lokaal kan ik perfect aan de poort aan, maar via mijn extern IP niet. Het lijkt me niet aan het hele macvlan gebeuren te liggen aangezien dat op LAN flawless werkt.

TL;DR

INTERNET --> TELENET PUBLIEK IP --> DMZ --> UNIFI USG --> SYNOLOGY NAS --> MACVLAN NETWERK --> DOCKER

IP configuratie van lokale IPs:

- Telenet LAN: 192.168.5.0/24

- DMZ: 192.168.5.10 (Unifi USG WAN 1)

- LAN: 192.168.10.0/24 (Unifi USG LAN 1)

- USG: 192.168.10.1

- macvlan net: 192.168.10.40/29

- Docker container fixed IP: 192.168.10.44

Via alle apparaten binnen LAN kan ik in 2 richtingen communiceren met de container.

Ping vanop USG naar de container werkt.

Zelf geen firewall rules aangemaakt, staat nog op default en de USG heeft er zelf eentje toegevoegd voor de port forwarding rule.

[igvfer]

@Sam___D  Domme vraag voorzeker. Moet je niet ergens een routing instellen?

[Sam___D]

Good point! Alle macvlan stuff enz. draait op mijn Synology. Ik dan eerst eens proberen om op de Synology een reverse proxy op te zetten en dan de port forwarding naar de proxy te doen.

[Arnie]

Ik begrijp je subnetting logica niet helemaal.
Je hebt op de USG LAN het subnet 192.168.10.0 / 24

Waar bevindt zich juist het macvlan net 192.168.10.40 / 29 ?
Wanneer een host binnen dat subnet ook het /29 subnet mask gebruikt zal deze alleen de IP adressen 192.168.10.41 t/m 192.168.10.46 direct kan aanspreken.
Het adres 192.168.10.1 valt buiten dit subnet en zal dan niet bereikbaar zijn.

Het is onbevolen om binnen een subnet overal hetzelfde subnetmask te gebruiken.

192.168.10.44 /29 zal namelijk een router nodig hebben om 192.168.10.1 te kunnen bereiken.

192.168.10.1 /24 zal echter denken het adres 192.168.10.44 rechtstreeks te kunnen bereiken.

[Sam___D]

macvlan is niet echt een subnet als in dat het aparte routing etc. heeft, het maakt deel uit van het gewone LAN met het verschil dat adressen niet van DHCP komen (die range is 192.168.10.100 tot .200) maar van Docker: https://blog.oddbit.com/post/2018-03-12-using-docker-macvlan-networks/

[Sam___D]

zelfs met de reverse proxy lijkt het niet te werken, lokaal ook weer wel

de situatie is nu iets simpeler dus met dat ik gewoon naar het IP van mijn NAS moet gaan en de NAS zelf zorgt er dan weer voor dat de HTTP proxying doorloopt

lokaal werkt alles natuurlijk weer zonder issues... het is enkel de port forwarding die niet lukt

over enkele weken verhuis ik naar een nieuwe woning waar ik de E-Router heb staan en de USG gewoon in bridge kan zetten wat het hopelijk oplost, zou leuk zijn als het echter nu al lukt

[Arnie]

Okay, duidelijk ivm macvlan: /29 slaat dus op de netwerk definitie, niet op het gebruikte netmask. Dat is dan in orde.

De port-forwarding van de USG kun je het beste eerst uit testen door eens vanaf het Telenet LAN netwerk te proberen de docker host te contacteren. Dus één keer port-forwarding in het traject, enkel de USG.

Heb je een PC of laptop die je eens aan het 192.168.5.0/24 netwerk kunt koppelen?

Vanaf daar zou je dus via 192.168.5.10:443 een verbinding moeten kunnen maken naar 192.168.10.44:8123 volgens je configuratie.

Heb je wellicht port en forward port per ongeluk ongewisseld?

Eenmaal dat dit werkt kun je en stapje verder gaan en de portforwarding via de Telenet HGW testen.

[Sam___D]

Vanop Telenet subnet (5.0/24) kan ik eraan via het WAN IP van de USG (5.10). Dat IP staat in DMZ en VPN (van de USG zelf) werkt zonder issues.

Vanop internet (Proximus via de smartphone) krijg ik dus steeds de connection reset error in mijn browser. Met tcpdump even gekeken op alle interfaces en de pakketjes vanop internet geraken wel tot aan hun eindbestemming. Lijkt dat ze misschien geen antwoord terug krijgen? Waaraan kan dat liggen? Ergens iets in de USG firewall?  

[Arnie]

Wat bedoel je met "staat in VPN"?

[Sam___D]

Oei, ongelukkig verwoord. Dat IP staat in DMZ.

En de VPN op de USG werkt zonder issues (ik moet geen port forward instellen of zo)

[Arnie]

Ah, OK. Inderdaad als je USG direct vanaf het internet bereikbaar is, zonder port-forwarding regels is dat een teken dat DMZ effectied werkt.

Vreemd, je kunt dus vanaf het internet je USG bereiken voor VPN, omdat de USG ingesteld is als DMZ-host in mijn telenet.

Je kunt ook vanaf het telenet LAN via 192.168.5.10:443 je internet docker applicatie aanspreken die luistert op 192.168.10.44:8123.

Het volledige trajekt in één keer werkt echter niet, dus:

<publiek-ip-addr>:443  =>  192.168.5.10:443  =>  192.168.10.44:8123

Correct?

[Sam___D]

Volledig correct.

Ik heb de poort ondertussen op elk niveau naar 8123 veranderd zodat het geen chaos is in tcpdump als je puur op poort 443 luistert.

En via tcpdump zie ik dus wel pakketjes binnen komen op de Synology (die als reverse proxy werkt)

Om het helemaal verwarrend te maken, heb ik het volgende gemerkt:

- op mijn thuisnetwerk kan ik naar mijn domeinnaam/extern IP+poort surfen en laadt alles perfect in

- via Proximus op mijn gsm lukt dat niet (connection timed out, maar ik zie dus wel iets gebeuren in tcpdump)

[Arnie]

Kan het iets basic zijn dat de docker geen default route heeft? Kun je vanuit de docker host het internet bereiken (bijvoorbeeld ping vanaf docker)?

Of heb je een firewall in de docker (iptables) die traffic beperkt tot 192.168.0.0/24 of zoiets?

Het is namelijk vreemd dat je ziet dat het verkeer wel toekomt, maar er geen antwoord op volgt.