Entgrenzung von Grenzregionen – Der Europäische Verbund für territoriale Zusammenarbeit (EVTZ) als Instrument der territorialen Kooperation von Kommunen in Europa

1. Einwahl ins lokale LAN hinter OPNsense
Der Zugriff auf die Geräte hinter OPNsense funktioniert bereits, nachdem man die Beschreibung bis einschließlich "Step 2b" umgesetzt hat. Man kann dann problemlos auf Geräte im lokalen Netzwerk zugreifen. Bei eingeschalteter WG-verbindung ist aber kein Zugriff (vom Client aus - getestet mit einem Macbook) auf Internet möglich.
Die Einstellungen im WG-Client haben dann keinen Einfluss darauf - was im unten markierten Bereich eingegeben wird, ist egal:

#client config macbook
[Interface]
PrivateKey = <xxx>
ListenPort = 52011
Address = 10.10.10.11/32
DNS = <x.x.x.x>

[Peer]
PublicKey = <xxx>
AllowedIPs = 0.0.0.0/0
Endpoint = my domain.com:51821
PersistentKeepalive = 25


2. Schritt 2c nicht vergessen
Ohne die unter Schritt 2c beschriebene Zuordnung zum WG-Interface funktionierte nicht mal das Routing nach außen. Kann eventuell an der Multi-WAN-Konfiguration liegen, die hier vorlag.

Befolgt man "Step 2c" (in unserem Fall bis einschließlich Festlegung des dynamischen Gateways), wird bei bestehender Verbindung ein Zugriff auf das Internet möglich - zumindest unabhängig von der Einstellung zum DNS-Server.
Verweist der DNS-Eintrag im Client (siehe oben) aber auf den lokalen OPNsense-DNS (Beispiel: 10.1.0.1), funktioniert DNS beim Client nicht. Nimmt man im Client den eigenen DNS, ist alles kein Problem:

• Zugriff auf LAN einer OPN funktioniert,
• Zugriff auf das Internet beim eingeschalteten Tunnel funktioniert,
• Internet-Zugriff scheint gar nicht über den Tunnel zu laufen (weniger Datendurchsatz, als vorher) die Daten werden doch über den Tunnel transportiert => Geschwindigkeit geringer als direkt, WG-Monitor zeigt Bewegung bei Zugriff des Clients auf das Internet. Scheint am Ende also nur ein DNS-Zugriffsproblem zu sein.

Für unseren Bedarf ist das OK, weil WG eher für sicheren Zugriff auf LAN-Geräte gedacht ist - aber sich auch für den Internet-Zugriff hinter der OPNsense zu verstecken müssen wir noch feilen...
Insofern führte die Beschreibung bei uns (multi-WAN?) zu keinem vollen Erfolg im Hinblick auf DNS.

Problem scheinbar gelöst:
=> mit der herausragenden Beschreibung in diesem Artikel konnte das Problem eingegrenzt werden. Der Unbound-DNS von OPNsense funktioniert nun einwandfrei, nachdem

• unter System => Settings => General bei
"Allow DNS server list to be overridden by DHCP/PPP on WAN" (die wohl wegen multi-AN an war (oder auch nicht)
unter "exclude interfaces" das WG-Interface ausgeschlossen wurde

• selbstverständlich dann unter VPN => WireGuard neu starten...

=> und als nach dem Neustart der OPNsense-Kiste das Internet per wireguard wieder nicht ging, musste diese Einstellung wieder rückgängig gemacht werden (nachdem die Ergänzung der firewall-rules auf dem Interface WGUARD keine Besserung brachte...);
Hier sind wir noch am rätseln, wie genau der kniff ist...
Wichtig: jegliche Änderungen der Einstellungen - auch Routen und Firewall-Regeln etc. - wirken erst dann, nachdem unter VPN => WireGuard => General die Funktionalität aus- und wieder eingeschaltet wurde...

1. Tools installieren
apt install wireguard

2. Schlüssel generieren - am besten mit folgendem Skript:
generatekeys.sh

#!/bin/bash
PRIVATE_KEY=`wg genkey`
PUBLIC_KEY=`echo $PRIVATE_KEY | wg pubkey`
echo Private Key: $PRIVATE_KEY
echo Public Key: $PUBLIC_KEY


3. Routing aktivieren
Wenn der Zugriff nicht nur auf die Maschine selbst, sondern auch auf das mit der Maschine verbundene, lokale Netzwerk erwünscht ist, muss das Routing funktionieren. Geht wie folgt:

# sudo sysctl -w net.ipv4.ip_forward=1
# vim /etc/sysctl.conf
=> net.ipv4.ip_forward=1 # (uncomment the line)


4. Konfiguration des "Servers"
D. h. in Terminologie von WireGuard => des ersten Peers unter Ubuntu erstellen - zu diesem werden Verbindungen initiiert.
Datei /etc/wireguard/wg.conf erstellen und bearbeiten:

[Interface]
Address = 10.11.10.1/24 => Adresse im WG-Netz (keines der verbundenen Netze)
# SaveConfig = true
ListenPort = 518XX => Port, mit dem der Server arbeitet
PrivateKey = <hier private key des Ubuntu-Servers>

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ens160 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ens160 -j MASQUERADE

[Peer]
PublicKey = <hier public key des 1. peers>
AllowedIPs = 10.11.10.2/32

[Peer]
PublicKey = <hier public key des 2. peers>
AllowedIPs = 10.11.10.3/32


5. Konfiguration auf jedem Peer
Die oben in den jeweiligen [Peer] - Sektionen vorgesehenen Clients, die sich verbinden sollen, müssen auch für sich konfiguriert werden. Dies geht - am Beispiel des ersten [Peer] oben - so:


[Interface]
PrivateKey = <hier private key des 1. peers>
ListenPort = 51<irgendwas>
Address = 10.11.10.2/32
DNS = <wenn auch DNS-Server hinter wireguard genutzt werden soll, dann Adresse des DNS für dieses Subnetz>

[Peer]
PublicKey = <public key des Ubuntu-Servers von oben, zu dem Verbindung aufgebaut wird>
AllowedIPs = ::/0, 0.0.0.0/0
Endpoint = ip.oder.domain.com:518XX
PersistentKeepalive = 25 (wenn client hinter NAT)


6. Router vor dem Wireguard-Peer
Falls der Wireguard-Server sich hinter einem Router "versteckt", dann muss ein passender Port geöffnet werden. Also muss

• das Forwarding zum Peer (hier: der Ubuntu-Server von oben) aktiviert werden,
• die entsprechenden Firewall-Regeln bei Bedarf angepasst werden (bei einer Fritzbox reicht zum Beispiel die Freigabe, bei Lancom-Routern müssen auch Firewall-Regeln angepasst werden)
• die Weiterleitung / Zulassung muss den Port als UDP betreffen, der oben als 518XX genannt wurde.