Categories
Computers English Networking Routers

WireGuard on OpenWrt: no IPv6 routing?

I recently configured my router to be a WireGuard gateway, so that I can dial into my home to reach my NAS. After I had set it up and all seemed to be working well, I noticed that IPv6 packets didn’t get out to the internet, when I did a ping on my laptop:

$ ping6 ipv6.example.net
PING6(56=40+8+8 bytes) fd00:9::4 --> 2a01:123:456:7890::2
^C
--- ipv6.example.net ping6 statistics ---
624 packets transmitted, 0 packets received, 100.0% packet loss

I immediately suspected a routing issue, and so I did the below test on my router:

root@gw:~# ping6 -I fd00:9::1 ipv6.example.net
PING ipv6.example.net (2a01:123:456:7890::2) from fd00:9::1: 56 data bytes
ping6: sendto: Network unreachable

This seemed to have confirmed my suspicion. But why is there a routing issue?

I remembered that the WireGuard clients are all using reserved IP addresses — both IPv4 and IPv6. For IPv4 my router is doing masquerading, but it doesn’t do so for IPv6. It passes these addresses (from public address space!) out to the internet, which is the default setup for OpenWrt.

Now, in the case of the VPN network, where reserved addresses from the range of fd00:9::1/64 are used, packets with source addresses from the reserved IP address range can’t be routed on the internet, which is why I was seeing the “Network unreachable” error message.

Categories
Communications English Networking Security Travel

Doing “IT” from Egypt

I was recently in Egypt for two weeks of vacation. As I’m running my own “bare-metal” root server, I needed to take care of it even while on vacation, to look after updates and alerts on a daily basis.

So I prepared myself well, and I would like to briefly let you know what I did, and what worked, and what didn’t work.

Preparation

First, I set up WireGuard on my server. It’s a UDP-based VPN that is very lightweight and fast. By chance I found out, though, that Egypt doesn’t work in Egypt, as it’s being blocked by Egypt’s authorities. 🙁

So I looked for alternatives and came across Outline. Outline is not actually a “real” VPN, but a proxy using the Shadowsocks protocol, which was explicitly designed to circumvent internet censorship. It can also proxy UDP traffic.

That is one amazing piece of software.

For certain Cloud Service Providers (Digital Ocean (just $4/mo.!), Google Cloud, Amazon Web Services), you can literally install it with a single click in a desktop app, the Outline Manager, which is available for Windows, macOS, and Linux.

Categories
Communications Networking

VPN-Probleme bei CGN/NAT444?

Diesen Artikel habe ich ursprünglich für unsere “Bürgerinitiative PRO Glasfaser” geschrieben. Da das Thema von allgemeinem Interesse sein dürfte veröffentliche ich ihn in leicht abgewandelter Form auch hier auf meinem Blog.


Uns haben mehrfach besorgte Interessenten angesprochen die von angeblichen “Problemen mit VPN beim Deutsche Glasfaser-Setup” gehört hatten.

Wir haben daraufhin selbst recherchiert und keine grundsätzlichen Probleme erkennen können, die auf Grund des Designs des DG-Setups zu erwarten sind.

Es handelt sich dabei um ein NAT444-Setup: Private IPv4-Adresse im Heimnetz (LAN), private IPv4-Adresse zwischen CPE (Router) und CGN sowie öffentliche IPv4-Adresse zwischen CGN und IPv4-Internet-Host. Es handelt sich nicht um Dual Stack-lite, da keine private IPv4-Adresse im LAN über IPv6 durch das CPE zum CGN getunnelt wird!

Solange “die IPv6-Migration” nicht beendet ist — sprich: Jeder Client weltweit kann IPv6 nutzen und jeder Host bietet seine Dienste ebenfalls per IPv6 an — sind Transitions-Techniken wie NAT444 von globaler Bedeutung. Daher gibt es einen eigenen RFC zu dem Thema “Einfluss von CGN auf Netzwerk-Anwendungen”: RFC-7021. Dieser RFC gibt keinerlei Hinweise dass es ein grundsätzliches Problem mit gängigen VPN-Anwendungen (NAT444-Szenario, VPN-Client im LAN, VPN-Gateway ausschließlich erreichbar über IPv4, aufgestellt in einer DMZ) geben könnte.

Wenn man (per Google) nach NAT444 sucht stößt man an prominenter Stelle auf diese Seite (die vor mehr als 4 Jahren erstellt wurde, also mittlerweile völlig veraltet ist!). Schon nach damaligem Stand ist die Seite als “dubios” zu bezeichnen.

Nach Aussage des Autors macht NAT444 “VPN” und “SSL” kaputt oder beeinträchtigt diese zumindest. In dieser Pauschalität ist die Aussage nicht sehr fundiert. Zum einen ist VPN nicht gleich VPN, es gibt diverse unterschiedliche Verfahren, die mit Sicherheit — wenn überhaupt — nicht alle gleichermaßen betroffen sind. Zum anderen ist SSL einfach nur eine Encryption Layer, die im Prinzip auf beliebige TCP-Ströme angewendet werden kann (das Protokoll bleibt aber TCP!). Wieso dieser TCP-Strom durch NAT444 beeinträchtigt werden soll erschließt sich mir nicht. Der Autor widerspricht sich mit seiner Aussage übigens selbst da er angibt, dass “Web” und “Mail” ohne Beeinträchtigung über NAT444 funktionieren sollen. Da aber auch bei Web-Anwendungen (HTTPS) und Mail-Anwendungen (SMTPS und POP3S/IMAP4S) “SSL” zum Einsatz kommt stellt sich die Frage wie das zusammen passt…

Um die Frage abschließend zu beleuchten besuchte ich am 26.06.2015 die “Deutsche Glasfaser”, um vor Ort in Heinsberg-Dremmen die beiden verbreiteten VPN-Protokolle “IPSec” (Cisco VPN Client mit XAuth) und SSL-VPN (Cisco AnyConnect) zu testen. Erwartungsgemäß konnte ich keinerlei Probleme mit den beiden o. g. VPN-Protokollen feststellen. Siehe auch diesen Artikel für weitere Infos über meinen Besuch.