Waarom faalt HTTPS verkeer naar ASUS router in DMZ op self-signed certificaat van Zyxel T-50?

En als je de server via het directe IP Adres bezoekt van de Pi werkt het wel?

Ik vermoed dat het komt door Nat-Loopback, misschien zou je eens kunnen kijken of je ook een foutmelding krijgt als je het publieke IP-Adres bezoekt via je smartphone (waarop Wi-Fi dan wel is uitgeschakeld).

Op mijn MacBook Pro (in het lokale netwerk): 

➜ curl -X POST https://server.domein.mijn:443/hook -H 'Content-Type: application/json' -d '{"a": "b"}'
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

➜ curl -X POST https://192.168.1.219:443/hook -H 'Content-Type: application/json' -d '{"a":"b"}'
curl: (7) Failed to connect to 192.168.1.219 port 443 after 9 ms: Connection refused

Op een andere poort (> 1024) dan 443 werkt het trouwens wel (bij gebruik van de domeinnaam; IP adres kan volgens mij ook niet werken, omdat het SSL certificaat voor een domein is; niet voor een IP adres), maar daar lijkt de third-party server die de webhooks genereert helaas niet mee overweg te kunnen (lijkt alleen poort 443 te ondersteunen?).

In Blink (SSH terminal voor iOS) op mijn iPhone over cellular (WiFi uit):

➜ curl -X POST https://server.domein.mijn:443/hook -H 'Content-Type: application/json' -d '{"a": "b"}'
curl: (35) Server aborted the SSL handshake

De vinkjes bij Extern Beheer staan uit voor WAN. Ze staan aan voor LAN/WLAN. Als ik die uitzet voor HTTPS krijg ik de foutmelding niet meer, maar lijken de calls te “hangen”. Ik zie ze niet binnenkomen op de server en er komt dan (uiteraard) ook geen antwoord terug.

De informatie die over de lijn gaat is niet heel erg gevoelig, dus als het echt niet anders kan zal ik terugvallen op HTTP, maar ik hoop met jullie hulp HTTPS werkend te krijgen.

@sublimerote Zou je screenshots kunnen delen van de relevante instellingen? Dat maakt het hopelijk wat makkelijker om een oorzaak te vinden. Misschien heeft iemand op basis daarvan nog een suggestie.

Mocht het relevant zijn; dit was de melding die Shodan vorige week gaf:

// Trigger: new_service
// Port: 443 / tcp
// Hostname(s): <mijn-IP-adres>.ftth.glasoperator.nl

Ik heb de datum en tijd even weggelaten, maar het was op een tijdstip dat ik niet eens thuis was…

Aangezien ik Extern Beheer via WAN heb uitstaan (zie screenshots) is het waarschijnlijk geen wijziging van mij die dit alert triggerde?

Hi @sublimerote, merci voor de aanvullingen! Super dat er al zo met jou mee is gedacht. Ik wil heel graag @Gerrit078, @TMTV en @Hidden.nld vragen of jullie hier nog een tip/advies voor hebben? Ik had je heel graag het antwoord willen geven, maar dit gaat mijn pet te boven. Excuses! 

➜ wget https://mijn.domein
--2022-08-21 23:26:37--  https://mijn.domein/
Resolving mijn.domein (mijn.domein)... <mijn IP adres>
Connecting to mijn.domein (mijn.domein)|<mijn IP adres>|:443... connected.
ERROR: cannot verify mijn.domein's certificate, issued by ‘CN=ZyXELcert,OU=ZyXELcert,O=ZyXEL,ST=TWN,C=TW’:
  Self-signed certificate encountered.
    ERROR: certificate common name ‘ZyXELcert’ doesn't match requested host name ‘mijn.domein’.
To connect to mijn.domein insecurely, use `--no-check-certificate'.

➜ wget https://mijn.domein:443
--2022-08-21 23:28:12--  https://mijn.domein/
Resolving mijn.domein (mijn.domein)... <mijn IP adres>
Connecting to mijn.domein (mijn.domein)|<mijn IP adres>|:443... connected.
ERROR: cannot verify mijn.domein's certificate, issued by ‘CN=ZyXELcert,OU=ZyXELcert,O=ZyXEL,ST=TWN,C=TW’:
  Self-signed certificate encountered.
    ERROR: certificate common name ‘ZyXELcert’ doesn't match requested host name ‘mijn.domein’.
To connect to mijn.domein insecurely, use `--no-check-certificate'.

Naar welk A-Record verwijst mijn.domein.ext ?

Bezoek je mijn.domein.ext vanuit je eigen lokale netwerk of via een externe verbinding?

Als je deze tests uitvoert vanaf je eigen verbinding komt het echt door NAT loopback, wat gebeurt er als je dezelfde test doet naar het IP-Adres van je Pi?

Ik geloof dat ik zelf een workaround heb gevonden…

Als ik de poort voor de HTTPS service bij Extern Beheer op iets anders dan 443 zet (bijvoorbeeld 9443) dan kan ik wel succesvol met de server op de Pi communiceren (remote en lokaal)!

Helaas werken de webhooks dan nog steeds niet (wel via HTTP), maar dat is waarschijnlijk een probleem van de partij die de webhooks genereert, dus ik ga daar verder kijken.

Bedankt voor het meedenken! En als jullie nog tips hebben zijn die nog steeds welkom.

Nee, dit is heel logisch. Verkeer naar het je public IP adress wordt gerouteerd naar de router, of dat van buiten komt of van binnen je netwerk maakt niet uit. Port translation kan dan dat IP pakket doorsturen naar een interne adres/port combinatie. Hairpin NAT zorgt ervoor dat dat ook werkt van binnen je eigen netwerk. 

Maar voordat port translation gebeurt kijkt de router eerst of er voor de interface waarop het pakket binnenkomt een dienst in de router is die op die port luistert (beheer). Voor verkeer van buiten zet je dat aan/uit met de boven beschreven instellingen. Voor IP-verkeer van binnen je eigen netwerk staat beheer altijd aan (anders zou je jezelf buiten kunnen sluiten). Een vraag naar  <je publieke IP>:443 kan dus voor verkeer uit je eigen netwerk door de router afgehandeld worden (beheer luister op die port) terwijl voor verkeer uit het internet beheer uitstaat bij de port translation uitkomt en netjes naar de webserver in je netwerk wordt gestuurd.

Door de port waarop beheer luistert te veranderen maak je de port 443 vrij en werkt hairpin NAT zoals gewenst: verkeer uit je eigen netwerk naar je publieke IP adres port 443 wordt netjes vertaald naar je interne host port 443.

In plaats van porttranslation kun je dus ook de DMZ functionaliteit gebruiken die de port mapping voor alle poorten doet,

DDNS kun je normaal gesproken vanaf je router of eender welke host achter de router doen zo lang de DDNS server  slim genoeg is je publieke IP uit de update request te halen. Dat is niet zo spannend.

Wat is voor jou extern verkeer? Verkeer vanuit jouw netwerk ook al is dat naar het externe IP-adres is lokaal verkeer: het stopt op de grens tussen je lokaal netwerk en het internet (je router).

Als het vanaf het internet (bijv. een mobiel met WIFI uit maar met mobiele data) inderdaad op de beheersomgeving uitkomt, ja dan heb je een bug in de Zyxel te pakken. Maar ik kan me niet voorstellen dat het geval is.

Als je extern beheer op de WAN aan hebt staan, snap ik dat de Zyxel dan het verkeer van buiten dat bestemd is voor poort 443 op een LAN-apparaat afvangt. De Zyxel heeft dan hogere prioriteit dan port forwarding. Maar dan blijft het vreemd dat als je dit uit hebt staan poort 443 toch gereserveerd blijft. Dat zou een bug kunnen zijn. Daar heb ik overigens geen last van. Ik heb extern beheer op de WAN uit staan (LAN staat wel aan), poort 443 ingevuld en toch kan ik mijn NAS op poort 443 bereiken, zowel binnen het netwerk als op 4G.

@sublimerote Dat was inderdaad de reden dat ik naar DDNS vroeg, maar zo te lezen werkt het zoals het hoort.