De mens leert. Het mensdom niet.
Ik zou verwachten dat de WAN destination port ook 51820 zou zijn?pentode schreef op vrijdag 5 juni 2026 @ 10:49:
[...]
Bedankt @Chatslet en een ieder voor het meedenken. Uiteindelijk is het gelukt ;-) Hoe? Door een (de juiste) rule aan te maken. Waar in: Firewall: NAT: Destination NAT ja daar en alleen daar.
Iedere keer botste ik op de "Default deny / state violation rule" in de Firewall live view. En was 'gelukkig' niet de enige. Betreft de V26.1.x versie. Dit OPNsense topic door ge spitt. Hieronder de pic's van hoe de rule er uit ziet. Any, any Who the hack/fck is Any ;-P Het boven en onder deel van het rule invulvenster. Oeps options is dicht geklapt. Daar pass invoeren en wel of niet loggen bepalen. Deze rule is om Wireguard weer werkend te krijgen van af 'buiten'. Maar kan prima als voorbeeld gebruikt worden. Achteraf gezien 'simple' het venijn zit in de details.
[Afbeelding]
[Afbeelding]
Ja, maar dan komt er niets binnen. Bedoel dan kun je geen tunnel opbouwen. Zo lijkt 't. En https/443 heeft een tijdje gewerkt. Maar nu weer niet?synoniem schreef op vrijdag 5 juni 2026 @ 12:41:
[...]
Ik zou verwachten dat de WAN destination port ook 51820 zou zijn?
[ Voor 8% gewijzigd door pentode op 05-06-2026 13:01 ]
De mens leert. Het mensdom niet.
Afhankelijk van de positie van deze regel in stapel komt die 443 nu bij 51820 terecht want any port. Als je regel voor 443 als eerste in de stapel hebt zou het goed moeten gaan voor https:443. De regels worden gelezen en toegepast van n=1 tot n=laatste en zodra een regel kan worden toegepast worden de volgende regels genegeerd.pentode schreef op vrijdag 5 juni 2026 @ 12:49:
[...]
Ja, maar dan komt er niets binnen. Bedoel dan kun je geen tunnel opbouwen. Zo lijkt 't. En https/443 heeft een tijdje gewerkt. Maar nu weer niet?