18.03.2025

676

URLs hinter IPsec Tunnel mit Wireguard VPN erreichen

Hallo,

Ich habe bei uns in der Firma einen Wireguard-Server eingerichtet (wg-easy verwaltet in einer docker compose), dieser ist installiert auf einem raspberry pi (172.16.100.230) in unserem internen Netzwerk.

Nun möchte ich gerne, dass die Mitarbeiter auch die Adressen, welche hinter einem IPseC-Tunnel liegen erreichen können. Der Tunnel wird auf einem Lancom 1793VA Router aufgebaut und ist so aufgebaut, dass wir aus all unseren internen Netzen das dorthinter liegende Netz 10.101.207.0/24 erreichen können, solange wir unsere Zugriffe maskieren als 192.168.71.9.

Wenn man vom Büro aus auf eine der URLs im Tunnel zugreift ist alles ganz normal, jetzt über Wireguard scheint aber die Maskierung nicht zu funktionieren, denn für den Router sieht es so us als kämen die Zugriffe von der internen IP des Raspberry Pi.

[IP-Router] 2025/03/18 00:54:50,420
IP-Router Rx (LAN-1, INTRANET, RtgTag: 100):
DstIP: 10.101.207.58, SrcIP: 172.16.100.230, Len: 52, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 80, SrcPort: 61245, Flags: S
Seq: 1771532036, Ack: 0, Win: 64860, Len: 0
Option: Maximum segment size = 1380
Option: NOP
Option: Window scale = 8 (multiply by 256)
Option: NOP
Option: NOP
Option: SACK permitted
Route: WAN Tx (LOTTO-BW)

[IP-Router] 2025/03/18 00:54:50,425
IP-Router Rx (IPSEC, RtgTag: 100):
DstIP: 172.16.100.230, SrcIP: 10.101.207.58, Len: 40, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 61240, SrcPort: 80, Flags: A
Seq: 1650762384, Ack: 3980152507, Win: 3535, Len: 0
Route: LAN-1 Tx (INTRANET)

[IP-Router] 2025/03/18 00:54:50,446
IP-Router Rx (IPSEC, RtgTag: 100):
DstIP: 172.16.100.230, SrcIP: 10.101.207.58, Len: 52, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 61245, SrcPort: 80, Flags: SA
Seq: 515532743, Ack: 1771532037, Win: 13660, Len: 0
Option: Maximum segment size = 1366
Option: NOP
Option: Window scale = 2 (multiply by 4)
Option: SACK permitted
Option: END
Route: LAN-1 Tx (INTRANET)

Ich habe es schon mit SNAT auf dem Pi selbst versucht, aber egal was ich tue die source ip bleibt bei der adresse des pi selbst und wird nicht als 192.168.71.9 maskiert. Auf dem Lancom Router selbst habe ich eine statische Route für die Maske hin zum Pi angelegt, aber das hat auch nix gebracht. Firewallregeln habe ich keine angelegt.

Ich hoffe jemand kann mir hierbei helfen. Wenn euch irgendwas an Infos fehlt bitte sagen, dann reiche ich es nach.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 672006

Url: https://administrator.de/forum/urls-hinter-ipsec-tunnel-mit-wireguard-vpn-erreichen-672006.html

Ausgedruckt am: 13.04.2025 um 02:04 Uhr

6 Kommentare

Neuester Kommentar

Das hiesige Wireguard Tutorial zu der Thematik hast du in aller Ruhe gründlich gelesen und entsprechend in deiner RasPi Server Konfig umgesetzt?! 🤔

Deine Beschreibung der IP Adressierung ist etwas widersprüchlich. Hier wäre es hilfreich du erklärst die nochmal ganz genau.

Welches IP Netz am lokalen, internen LAN und die dortigen IPs vom Lancom und WG Server?

Ggf. statische IP Routen dort wenn vorhanden

Welches interne IP Netz nutzt du am Wireguard VPN?
Welches remote IP Netz hängt an der IPsec Verbindung. Ggf. mit aktuellen IPsec Phase 2 SAs

Hilfreich wäre gewesen deine WG Server Konfig Datei und auf die der WG Clients hier einmal zu posten. Sehr wahrscheinlich hast du in den "AllowedIPs" der WG Clients einen Crypto Routing Eintrag für die jeweils remoten IP Netze vergessen.
Möglich auch das du vergessen hast auf dem Lancom eine statische Route auf das interne WG VPN IP Netz einzutragen? Wegen der fehlenden Konfigs kann man hier jetzt nur raten.

Ein detailiertes Beispiel für einen im internen LAN betriebenen WG Server und die dazu korrespondierende Route auf dem Internet Router findest du u.a. HIER.
Wichtig wäre auch die IPsec Phase 2 SAs zu kennen vom IPsec Router (Lancom), denn dort muss das interne WG Netz auch als P2 definiert sein damit Traffic dafür in den IPsec Tunnel gesendet wird.
NAT gehört keinesfalls in den Tunnel sondern wenn, dann immer auf die Firewall. Siehe WG Tutorial...

Ich habe mal Screenshots von den Einstellungen auf dem Lancom Router gemacht.

Hier der Auszug aus meiner docker compose für wg-easy:

  wg-easy:
    image: weejewel/wg-easy:latest
    container_name: wg-easy
    network_mode: "host"  
    # Damit der Container WireGuard-Schnittstellen verwalten kann:
    cap_add:
      - NET_ADMIN
#    sysctls:
#      - net.ipv4.ip_forward=1
#      - net.ipv6.conf.all.forwarding=1

    environment:
      # WG-Easy nutzt diese ENV-Variablen zur Konfiguration
      - TZ=Europe/Berlin                      # Zeitzone anpassen

      - WG_HOST=öffentliche ipv4 von unserem Büro       # Deine öffentliche Domain oder IP
      - WG_PORT=51820                         # UDP-Port
      # Optional bei Bedarf:
      # - WG_DEFAULT_ADDRESS=10.6.0.x         # Das Default-Netz für die Clients
      - WG_ALLOWED_IPS=172.16.100.0/24, 172.16.120.0/24, 10.8.0.0/24           # Standard-Routing, etc.
      - WG_DNS=172.16.100.1
      - WG_DEFAULT_DNS=172.16.100.1

    volumes:
      - ./data:/etc/wireguard                # Persistente Speicherung aller Konfigs/Keys
#    ports:
#      # 51820/udp ist der WireGuard-VPN-Port
#      - "51820:51820/udp" 
#      # 51821/tcp ist das Webinterface
#      - "51821:51821" 

    restart: unless-stopped
#    networks:
#      - webnet

  device-management:
    build:
      context: ./device-management  # Directory with your existing website's Dockerfile 
    restart: always
    expose:
      - "8080"  
    networks:
      - webnet

networks:
  webnet:
    external: true

Da ich nicht wollte, dass jeder der einen VPN Zugang erhält auch automatisch zugriff auf den Tunnel hat habe ich die Config für jene die dürfen manuell angepasst:

[Interface]
PrivateKey = kGhvdkRknXs5U9y9SgGbXdY9o/33PJT9R279du5L01k=
Address = 10.8.0.3/24
DNS = 172.16.100.1

[Peer]
PublicKey = RHDWNNk4ekACmsu36BZMf/ar5Szds6aQY9Zn9GIRs3Q=
PresharedKey = qJ2jJa5mig5lxpCdxBphprsfT/mYxVoi5bcifLM4ZdY=
AllowedIPs = 172.16.100.0/24, 172.16.120.0/24, 10.8.0.0/24, 10.101.207.0/24
Endpoint = büro:51820

Welches IP Netz am lokalen, internen LAN und die dortigen IPs vom Lancom und WG Server?
Ggf. statische IP Routen dort wenn vorhanden

Internes Lan (Büro): 172.16.100.0, 172.16.120.0 (Diese Netzt sind auch als VLANs definiert)
Wireguard Netz: 10.8.0.0
Adresse Raspberry Pi: 172.16.100.230 (Dieser ist erreichbar über das 100er Netz und hier ist der Wireguard Server installiert)
Die statischen Routen sind in den Screenshots zu sehen.

Welches interne IP Netz nutzt du am Wireguard VPN?

Das standard wireguard netz 10.8.0.0

Welches remote IP Netz hängt an der IPsec Verbindung. Ggf. mit aktuellen IPsec Phase 2 SAs

Hier wird eine Verbindung zum entfernten Netz 10.101.207.0 aufgebaut, alle unsere Zugriffe werden hinter einer IP aus einem Transport-Netz (192.168.71.9) maskiert.

Wichtig wäre auch die IPsec Phase 2 SAs zu kennen vom IPsec Router (Lancom), denn dort muss das interne WG Netz auch als P2 definiert sein damit Traffic dafür in den IPsec Tunnel gesendet wird.

Da sind keine spezifischen Netzte hinterlegt, es existiert nur eine any<>any regel quasi

Public Keys zusätzlich zu den so oder so vorhandenen Keys zu benutzen ist ziemlich überflüssig und kannst du auch weglassen um deine Konfig zu vereinfachen.
Das ist so wenn du zum Gürtel noch den Hosenträger brauchst...also unnötig.
Du hast zudem das oben zitierte Tutorial scheinbar nicht gelesen, denn dann wäre dir aufgefallen das du eine falsche Maske fürs interne WG Netz in deiner Konfig unter AllowedIPs verwendest!

Dein Netz sollte so aussehen, ist das korrekt?

Jo, sieht überwiegend korrekt aus.

Gateway ist die 172.16.100.1 und nicht .254, ansonsten stimmt alles.

Und ja, habe das Tutorial nicht gelesen und mich auf darauf verlassen, dass da soweit alles gestimmt hat... 🙃
Sollte ich da jetzt quasi dieses cryptokey-routing in den allowedIPs aufnehmen? Wäre das dann in meinem fall die interne adresse des pis oder die Büro IP?

EDIT:
Oookay...
Weder ip vom pi noch die vom Büro, ich muss dem Wireguard Server eine IP aus dem 10.8.0.0 netz zuweisen und diese dann bei den CLients in die AllowedIPs aufnehmen?

Gateway ist die 172.16.100.1 und nicht .254

Du meinst die IP/Gateway Adresse des WG Servers? Wenn ja, welche IP hat denn der Lancom, dann passe ich das an?
Nur nebenbei:
Stimmen kann das was du sagst nicht, denn dann wäre die .1 der WG Server und im Client gibst du den DNS Server auch mit der .1 an was niemals stimmen kann, denn der WG Server arbeitet in der Regel nicht als DNS Server.
Wenn man alle DNS Anfragen der WG Clients unbedingt über einen lokalen DNS schicken will oder muss kommt da der Lancom rein oder ein ggf. vorhandener lokaler DNS Server dort. Andernfalls lässt man den DNS Eintrag im Client schlicht und einfach weg. (Siehe zur DNS Thematik auch hier im WG Tutorial)

Sollte ich da jetzt quasi dieses cryptokey-routing in den allowedIPs aufnehmen?

Nein! Das hast du ja schon gemacht, nur falsch.
Du sollst da nur die Subnetzmaske des internen IP Netzes bzw. der internen Geräte beim Crypto Routing Eintrag AllowedIPs" anpassen. Das sind doch immer /32 Hostmasken! Die sind bei dir, wie oben schon gesagt, falsch!
Es darf dort NICHT das gesamte interne IP Netz angegeben werden, sondern immer nur die dedizierten Geräte mit einer /32er Hostmaske! Leider machen das viele Laien immer und immer wieder falsch.
Wenn der WG Server intern z.B. die 10.8.0.254 bei dir hat dann sieht die von denn sinnfreien Preshared Keys befreite Client Konfig für den .3er Client so aus:

[Interface]
PrivateKey = kGhvdkRknXs5U9y9SgGbXdY9o/33PJT9R279du5L01k=
Address = 10.8.0.3/24
DNS = 172.16.100.1

[Peer]
PublicKey = RHDWNNk4ekACmsu36BZMf/ar5Szds6aQY9Zn9GIRs3Q=
AllowedIPs = 10.8.0.254/32, 172.16.100.0/24, 172.16.120.0/24, 10.101.207.0/24
Endpoint = <lancom_wan_ip>:51820

Die dazu korrespondierende Server Konfig Datei sähe dann für den .3er Client so aus:

[Interface]
Address = 10.8.0.254/24
PrivateKey = AB1234P6j2O0PH1838gYnv5p5n27HVmVWJRjZr12345=
ListenPort = 51820

[Peer]
PublicKey = 4321Abc06YX3gA4P0sQzywNX8c1sHSeu+oqsrI84321=
AllowedIPs = 10.8.0.3/32 

Eigentlich doch alles kein Hexenwerk!