Wireguard Allowed-IPs

[entest]

Servus Community, vielleicht kann mir hier jemand helfen. Habe ich hier einen Denkfehler?

Ich habe eine Wireguard-VM mit Debian. Soweit so gut. In der UI habe ich als "postup"

iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

stehen. Damit kann ich, wenn ich dem Client unter "Allowed IPs" ein spezifisches Netz gebe (oder 0.0.0.0/0) in alle oder in diese Netze routen. Mein Problem ist jetzt das wenn ich demClient zb nur "192.168.1.2/32" einrichte und sich der User dann in der Config am PC einfach 0.0.0.0/0 einträgt er TROTZDEM in alle Netze kommt. Wozu gibt es dann die "Allowed IPs" wenn ich sie clientseitig überschreiben kann? Ich könnte natürlich die Client-IPs dann per iptables einschränken aber das kann doch nicht Sinn der Sache sein.

Übersehe ich hier etwas?

Gruß entest

 

[TheCadillacMan]

AllowedIPs dient eigentlich nur dazu Routen zu erzeugen und nicht als Firewall/Zugriffsschutz.
Da alle Clients bei WG sowieso statische IPs haben, sind entsprechende Firewall-Regeln am Server ja kein Problem.

 

[entest]

HI, danke für die Antwort. Ja, blöd halt nur der doppelte Verwaltungsaufwand. Wenn die Serverseite nur A propagiert aber der Client sich dann B und C eintragen kann sehe ich das eher nicht so toll. Muss ich mal schauen wie ich das lösen kann.

Edit: Im Client kann man auch seine eigene IP ändern, toll. (Aber dann geht das Routing nicht. Gut, muss ich das über die Firewall lösen).

 

[foofoobar]

Schau mal in dieses Paper, insbesondere Kapitel 2:

https://www.wireguard.com/papers/wireguard.pdf

 

[entest]

@foofoobar . Danke, hab ich mir mal angesehen. Soweit ich verstanden habe soll das Cryptokeyrouting sicherstellen das der Client nur dorthin darf wo er hin soll.

Mein Problem ist aber das es das eben nicht tut. Am Server steht "Allowed IP 192.168.1.1/32" zb. und am Client stelle ich mal auf "Allowed IP 192.168.1.2/32" um, so kommt er auf die 1.2 obwohl er es ja serverseitig gar nicht dürfte. Wie blocke ich das? Mit ufw komme ich am Server auch nicht weiter. Mein Client hat 10.252.1.1, ich sage:

ufw deny in from 10.252.1.1 to 192.168.1.2
und
ufw deny outfrom 10.252.1.1 to 192.168.1.2
aber es ändert sich nix.

liegt es am WG-Postup-Script?

iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Habe ich da einen Denkfehler? Ich dachte das nur vom Server eingerichtete "Allowed IPs" zugelassen werden.

 

[chrigu]

Wie ist den der Server angebunden? Alles in einem Netzwerk mit verschiedenen subnetze oder über wan/vlan?

 

[Pete11]

Habe ich da einen Denkfehler?

Die Information zum Zugriff auf Dein Netzwerk über Wireguard gibst Du ja nicht jedem (normalerweise nur Dir, damit Du von Außen in Dein Netzwerk kommst). Wenn Du befürchtest, daß jemand den Wireguard-Zugriff mißbraucht, dann solltest Du demjenigen keinen Wireguard Zugriff geben.

 

[entest]

@chrigu . Der Server ist hinter einem NAT mit Portforwarding eingrichtet. Intern hat er dann Zugriff in alle Netze. Durch das Masquerading macht er dass dann auch als Gateway für die Wireguardclients.

wg0:

# This file was generated using wireguard-ui (https://github.com/ngoduykhanh/wireguard-ui)
# Please don't modify it manually, otherwise your change might get replaced.

# Address updated at:     2022-09-28 09:53:29.302506648 +0000 UTC
# Private Key updated at: 2023-06-15 08:07:21.3894167 +0000 UTC
[Interface]
Address = 10.252.1.0/24
ListenPort = 51820
PrivateKey = xxx

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


# ID:           xxx
# Name:         test
# Email:
# Created at:   2023-06-15 08:12:13.8100007 +0000 UTC
# Update at:    2023-06-19 07:06:59.54336605 +0000 UTC
[Peer]
PublicKey = xxx
PresharedKey = xxx
AllowedIPs = 10.252.1.1/32

Client:

[Interface]
Address = 10.252.1.1/32
PrivateKey = XXX
DNS = 192.168.1.1

[Peer]
PublicKey = xxx
PresharedKey = xxx
AllowedIPs = 192.168.1.1/32
Endpoint = fqdn:51820
PersistentKeepalive = 15

Warum komme ich dann wenn ich am CLient "Allowed IPs = 192.168.1.2/32" oder "Allowed IPs = 192.168.2.1/32" auf die IP oder gar in dieses Netz?

Ergänzung (6. Juli 2023)

Die Information zum Zugriff auf Dein Netzwerk über Wireguard gibst Du ja nicht jedem (normalerweise nur Dir, damit Du von Außen in Dein Netzwerk kommst). Wenn Du befürchtest, daß jemand den Wireguard-Zugriff mißbraucht, dann solltest Du demjenigen keinen Wireguard Zugriff geben.

Es sind mehrere User und mehrere Netze. Wenn der WG-Server seine für den Client freigegebenen Routen ignoriert ist das für mich eigentlich eine Sicherheitslücke.

Edit: Wie es aussieht ist dem Server nur die Allowed-IP des Clients (also die 10.252.1.x) wichtig, nicht was in der Clientconfig steht. Das finde ich schon gruselig.

 

[Pete11]

Schau mal hier, vielleicht hilft das etwas:
https://www.procustodibus.com/blog/2021/03/wireguard-allowedips-calculator/

 

[TheCadillacMan]

Warum komme ich dann wenn ich am CLient "Allowed IPs = 192.168.1.2/32" oder "Allowed IPs = 192.168.2.1/32" auf die IP oder gar in dieses Netz?

Weil du mit der Regel in PostUp dem Server sagst, dass er alles weiterleiten und NATen soll was über den Tunnel kommt.

Wenn der WG-Server seine für den Client freigegebenen Routen ignoriert ist das für mich eigentlich eine Sicherheitslücke.

Ich glaube da gibt es ein allgemeines Missverständnis wie das Routing in WireGuard funktioniert.
Es gibt keine "für den Client freigegebenen" Routen. Jeder Peer (inkl. dem Server) bestimmt seine Routen selbst. Ob der andere Peer das dann weiterleitetet ist nicht die Sache von WireGuard.
AllowedIPs am Client bestimmt was über den Tunnel zum Server geschickt wird. AllowedIPs am Server bestimmt was über den Tunnel zum Client geschickt wird.
Deshalb kann der Client seine IP zwar einseitig ändern aber dann funktioniert das Routing nicht mehr, weil der Server nicht die passende Route für den Client hat.

Den Namen AllowedIPs finde ich etwas unglücklich, weil er eine Zugriffssteuerung impliziert, die es nicht gibt. "Routes" wäre meiner Meinung nach passender.

 

[foofoobar]

Edit: Wie es aussieht ist dem Server nur die Allowed-IP des Clients (also die 10.252.1.x) wichtig, nicht was in der Clientconfig steht. Das finde ich schon gruselig.

Es gibt keinen Client und keinen Server bei Wireguard, lediglich Peers.

 

[entest]

@foofoobar In der Wiregaurd UI steht "Wiregaurd Clients" . Wie gesagt finde ich es sehr merkwürdig wenn ein Client, sorry, Peer einfach selbst sein routing ändern kann. Über ufw habe ich es probiert einzuschränken für die WG-IP, aber ohne Erfolg.

 

[foofoobar]

Welche Wireguard UI?

 

[entest]

Na, DIE Wireguard-UI ^^ https://github.com/ngoduykhanh/wireguard-ui .

Egal. Ich hab es jetzt geschafft über die "Extra Allowed IPs" IPs oder Blöcke zu sperren. Ist zwar nicht das gelbe vom Ei aber so klappt es.

 

[foofoobar]

Irgendjemand schreibt eine Software für irgendwas und das soll dann für die andere Software maßgeblich sein?

Ansonsten suchst du wahrscheinlich eine Funktion die es bei wireguard nicht gibt.
Kein wireguard-peer hat eine Kontrolle über den anderen peer.
Das ist eine typische Funktion von "Road-Warrior-VPNs" was wireguard nicht ist.

 

[entest]

Wireguard kennt keine Benutzer im eigentlichen Sinn, deshalb gibt es auch keine Authentifizierung über Kennwörter. Ob die Geggenstelle nun "Peer", "Client", "Endpoint" oder "Gummibärchen" heißt ist doch wohl egal.

Klar, WG löst alles ab, deshalb gibt es ja Clients für so ziemlich alle Betriebssysteme und wird ua in den Fritzboxen integriert. Die wenigsten werden es wohl als Site2Site-Lösung nutzen, dafür hat man IPSEC seit Jahrzehnten. Wenn ich aber einen Tunnel möchte der über labbrige LTE-Verbindungen den ganzen Tag offen bleibt, kostenlos ist (ists ja bei den meisten kommerziellen VPN-Lösungen ja nicht), auf iOS zb on-demand-dialup unterstützt, dann nehm ich Wireguard 🤷‍♂️.

 

[foofoobar]

IPSEC is to complex to be secure! ( https://www.schneier.com/wp-content/uploads/2016/02/paper-ipsec.pdf )

Funktionen von "Road-Warrior-VPNs" kann man on top drauf programmieren, das ist dann aber nicht mehr "wireguard" sondern "wireguard-foo".

 

[entest]

Ja, muss man halt dementsprechend einschränken. Wenn ich nur gewisse Cypher zulasse und nur vordefinierte Gegenstellen geht das schon aber ja, IPSEC ist riesig.

Also über die Extra-IPs geht es doch nicht, damit legt er das Routing lahm (ist ja eigentlich auch dafür gedacht soweit ich gesehen habe). Meine Frage wäre jetzt wie ich die IPs korrekt einschränke. Der Client hat 10.252.1.1 und wie oben geschrieben habe ich es über ufw versucht, die Regeln zeigt er auch an aber egal was ich blocke, es geht immer durch.

 

[foofoobar]

iptables -A INPUT -i wgx ......
iptables -A FORWARD -i wgx ......

https://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html

 

[entest]

So wäre auch die Idee gewesen. Geht nur irgendwie nicht. Hab das Interface auch weggelassen:

iptables --append FORWARD --src 10.252.1.0 --dst 192.168.1.2 --jump DROP
iptables --append INPUT--src 10.252.1.0 --dst 192.168.1.2 --jump DROP