Hallo Zusammen,
ich bin Glasfaserkunde und somit vom CGNAT betroffen. Da ich ein paar Server zuhause betreibe, die auch aus dem Urlaub/Hotel erreichbar sein müssen, habe ich erfolgreich einen Wireguard Tunnel von meiner OPNsense zu einem VPS (Ionos) eingerichtet. Der Tunnel wird per IPv6 aufgebaut und im Tunnel wird IPv4 gesprochen. (So ähnlich wie Dennis das mal vorgestellt hat.)
An der Verbindung stört mich, daß die Clients die Tunneladresse (10.x.x.x) sehen und nicht die reale IP der Anfrage.
Also habe ich die VPS-Konfiguration wie folgt abgeändert (SNAT auskommentiert).
[Interface]
PrivateKey = <Key>
Address = 10.20.50.1/24
ListenPort = 51820
Table = off
PostUp = iptables -t nat -A PREROUTING -i ens6 -p tcp -m multiport --dport 80,443 -j DNAT --to-destination 192.168.11.1
PostUp = iptables -t nat -A PREROUTING -i ens6 -p tcp -m multiport --dport 8080,8443 -j DNAT --to-destination 192.168.11.1
PostUp = ip route add 192.168.11.1 via 10.20.50.2 dev wg0
#PostUp = iptables -t nat -A POSTROUTING -o wg0 -p tcp -m multiport --dport 80,443 -d 192.168.11.1 -j SNAT --to-source 10.20.50.1
#PostUp = iptables -t nat -A POSTROUTING -o wg0 -p tcp -m multiport --dport 8080,8443 -d 192.168.11.1 -j SNAT --to-source 10.20.50.1
PostDown = iptables -t nat -D PREROUTING -i ens6 -p tcp -m multiport --dport 80,443 -j DNAT --to-destination 192.168.11.1
PostDown = iptables -t nat -D PREROUTING -i ens6 -p tcp -m multiport --dport 8080,8443 -j DNAT --to-destination 192.168.11.1
PreDown = ip route del 192.168.11.1 via 10.20.50.2 dev wg0
#PostDown = iptables -t nat -D POSTROUTING -o wg0 -p tcp -m multiport --dport 80,443 -d 192.168.11.1 -j SNAT --to-source 10.20.50.1
#PostDown = iptables -t nat -D POSTROUTING -o wg0 -p tcp -m multiport --dport 8080,8443 -d 192.168.11.1 -j SNAT --to-source 10.20.50.1
[Peer]
PublicKey = <Key>
AllowedIPs = 0.0.0.0/0
Gleichzeitig habe ich in der OPNsense ein Gateway (10.20.50.1) angelegt und dieses Gateway als reply-to Gateway in der Firewallregel des Tunnels eingetragen. Eigentlich müsste ich auf der OPNsense eine neue Routing-Table für den Wireguardtunnel anlegen, aber das geht wohl nicht.
HTTPS-Zugriffe bleiben immer beim Handshake hängen
$ curl -v https://web.winnig.eu
* Host web.winnig.eu:443 was resolved.
* IPv6: (none)
* IPv4: 87.106.212.183
* Trying 87.106.212.183:443...
* Connected to web.winnig.eu (87.106.212.183) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/cert.pem
* CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to web.winnig.eu:443
* Closing connection
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to web.winnig.eu:443
Irgendwas wird scheinbar nicht in den Wireguard Tunnel geschoben, sondern vielleicht auf WLAN oder es wird verworfen ich weiß es nicht.
Es wäre schön, wenn mir jemand weiterhelfen könnte an welchen Schrauben der OPNsense ich drehen muss…
)