ubuntuusers.de

Hi !

Ich habe wireguard am laufen und aktuell ist ja alles wie in den Tutorials so eingestellt das die WG IPs genattet werden. sprich ich sehe in Logs bei Zugriffen in anderen Resourcen die IP des Wireguard servers statt die des Wireguard Clients. Wie muss ich den PostUp Und PostDown aufruf ändern wenn ich das so wollte wie beschrieben

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

alles nach dem ; wegzulassen passt irgendwie nicht...

Gruss Gerd

goerdi schrieb:

Wie muss ich den PostUp Und PostDown aufruf ändern wenn ich das so wollte wie beschrieben

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

Hast Du evtl. auch für das wg0-Interface Source-NAT/MASQUERADE konfiguriert?
Wie sind die Ausgaben von:

sudo iptables-legacy -nvx -L -t nat
sudo iptables -nvx -L -t nat

(oder gleichwertig)?

EDIT:

Welche Tutorials hast Du benutzt?

Hi !

# Warning: iptables-legacy tables present, use iptables-legacy to see them
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
       5      824 MASQUERADE  all  --  *      enp4s0  0.0.0.0/0            0.0.0.0/0           

Welches ? Kann ich dir nicht genau sagen, aber eben einen wo mit PostUp und PostDown gearbeitet wird

Gruss Gerd

goerdi schrieb:

# Warning: iptables-legacy tables present, use iptables-legacy to see them

Ja, und wie ist die Ausgabe von:

sudo iptables-legacy -nvx -L -t nat

? (.... denn z. B. systemd kennt bis jetzt nur das (alte) iptables-legacy und nicht iptables oder nftables 😉 ).

Hi

hier bitte

Chain PREROUTING (policy ACCEPT 11468 packets, 3494691 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 10848 packets, 3468065 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 7907 packets, 784468 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 8092 packets, 797174 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Ciao Gerd

goerdi schrieb:

hier bitte

Sind das jetzt Ausgaben vom WD-Client oder vom WG-Server?
Wie ist auf dem WG-Server die Ausgabe von:

sysctl net.ipv4.ip_forward

?
Wird evtl. auch IPv6 für wireguard mitbenutzt?

Hi !

es ist der Server.... IPv6 wird nicht genutzt

root@capricorn:/data# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Gruss Gerd

goerdi schrieb:

es ist der Server....

Dann starte mal auf dem WG-Server und auf dem WG-Client-Nr_1:

sudo tcpdump -c 30 -vvveni wg0 icmp

und mache vom WG-Client-Nr_2 einen Ping auf die IPv4-Adresse vom wg0-Interface des WG-Client-Nr_1

ping -c 2 <IPv4-Adresse vom wg0-Interface des WG-Client-Nr_1>

Poste nach dem Ping, die Ausgabe von tcpdump vom WG-Server und vom WG-Client-Nr_1.

Hi !

Irgendwo versteh ich nicht worauf du hinauswillst. Mit der oben genannten Einstellung bei PostUp und PostDown funktioniert alles, aber eben nur dass im Netzwerk vom Server alle Zugriffe angezeigt werden als würden sie von diesem Server kommen (sprich mit einer IP aus dem "eigenen" Netz). Es sollte aber wie ganz normales routing funktionieren. Sprich greife ich vom VPN aus auf einen Rechner im Netzwerk zu dann sollte der das auch so anzeigen. Das routing intern ist keine Problem, das ist überall wo moeglich eingeschaltet und die route ist bekannt.

Gruss Gerd

goerdi schrieb:

..., aber eben nur dass im Netzwerk vom Server alle Zugriffe angezeigt werden als würden sie von diesem Server kommen (sprich mit einer IP aus dem "eigenen" Netz).

Sie kommen ja auch "über diesen" Server. 😉
Ich kann das reproduzieren (Ping mit "-c 1"!!! von .14 zu .99 via Server mit der .1). Schau dir das (auf dem Server) mal an:
- Mit S-NAT am wg0-Interface vom WG-Server:

:~# tcpdump -vvveni wg0 icmp
tcpdump: listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
10:38:52.699137 ip: (tos 0x0, ttl 64, id 3327, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.22.14 > 192.168.22.99: ICMP echo request, id 5005, seq 1, length 64
10:38:52.699277 ip: (tos 0x0, ttl 63, id 3327, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.22.1 > 192.168.22.99: ICMP echo request, id 5005, seq 1, length 64

10:38:52.706203 ip: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.22.99 > 192.168.22.1: ICMP echo reply, id 5005, seq 1, length 64
10:38:52.706240 ip: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.22.99 > 192.168.22.14: ICMP echo reply, id 5005, seq 1, length 64
^C

- Ohne S-NAT am wg0-Interface vom WG-Server:

:~# tcpdump -vvveni wg0 icmp
tcpdump: listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
21:54:16.959530 ip: (tos 0x0, ttl 64, id 31885, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.22.14 > 192.168.22.99: ICMP echo request, id 17503, seq 1, length 64
21:54:16.959629 ip: (tos 0x0, ttl 63, id 31885, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.22.14 > 192.168.22.99: ICMP echo request, id 17503, seq 1, length 64

21:54:16.963459 ip: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.22.99 > 192.168.22.14: ICMP echo reply, id 17503, seq 1, length 64
21:54:16.963497 ip: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.22.99 > 192.168.22.14: ICMP echo reply, id 17503, seq 1, length 64
^C

... und fällt dir was auf?
BTW: WG macht (auch) cryptorouting und da ist es auch wichtig was bei AllowedIPs steht.
Wenn Du nicht weiter suchen willst, dann lassen wird es.

Hi !

Aber über diesen Server ist nicht von diesem Server.. Mit NAT sieht es so aus aus wäre der Server die Quelle... ohne NAT steht dort die originale IP vom VPN.

Ich weiss ja nicht was du mich da untersuchen lassen willst wenn der Eintrag unter PostUp generell falsch ist (weil mit NAT arbeitet ) und ich aber ein Setup ohne NAT bevorzuge, weil ich wissen will wer wo rummacht.

Gruss Gerd

goerdi schrieb:

Mit NAT sieht es so aus aus wäre der Server die Quelle... ohne NAT steht dort die originale IP vom VPN.

Was genau meinst Du mit "originale IP vom VPN"? Evtl. die IP-Adresse vom wg-Interface beim source-WG-Client?

goerdi schrieb:

Ich weiss ja nicht was du mich da untersuchen lassen willst wenn der Eintrag unter PostUp generell falsch ist (weil mit NAT arbeitet ) und ich aber ein Setup ohne NAT bevorzuge, weil ich wissen will wer wo rummacht.

Der Eintrag unter PostUp muss nicht falsch sein. Warum stört dich die IP vom Server, als source-IP weil Du zwingend die IP vom Client als source-IP haben willst? Was funktioniert nicht richtig, mit der jetzigen Konfiguration deines WG-VPN?
Ich habe dir gezeigt, was Du untersuchen sollst/kannst. Denn Du hast das source-NAT beim wg0-Interface nicht konfiguriert. Es geht darum festzustellen, ob die Regeln in der FORWARD chain (die mit PostUp gesetzt werden) gleichwertig sind bzw. das bewirken was ein source-NAT beim wg0-Interface bewirkt.

Hi !

Ja ich meine die IP die der VPN Client hat .... Mit der aktuellen PostUp/PostDown wird das ja auf die Serverip maskiert.. so kann ich aber im Netzwerk nicht sehen von wem nun der connect in Wirklichkeit kommt. Was ich eigentlich gedacht habe es hat hier einer die Iptableseinstellungen dass es nicht maskiert wird. beim openvpn kommt bei mir auch alles mit der VPN Client IP rein.

Ciao Gerd

goerdi schrieb:

Mit der aktuellen PostUp/PostDown wird das ja auf die Serverip maskiert..

Bist Du dir sicher, dass es diese:

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o enp4s0 -j MASQUERADE

Einstellung ist? Denn bei meinem WG-Server hat diese Einstellung/Konfiguration keinen Einfluss auf das was Du beschreibst bzw. nicht haben willst.
Poste mal vom WG-Server die Ausgabe von:

sudo iptables -nvx -L FORWARD
sudo iptables-legacy -nvx -L FORWARD
sudo wg

Hi !

Ja ich bin sicher......

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o enp4s0 -j MASQUERADE

und nach dem login vom vpn client sagt ein anderer rechner im netz (nicht das der wg server)

Last login: Sat Jan 20 22:00:11 2024 from 192.168.63.1

welches die IP vom Wireguard server ist...

iptables -nvx -L FORWARD

Chain FORWARD (policy DROP 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
     501    82598 ufw-before-logging-forward  all  --  *      *       0.0.0.0/0            0.0.0.0/0
     501    82598 ufw-before-forward  all  --  *      *       0.0.0.0/0            0.0.0.0/0
     198    13201 ufw-after-forward  all  --  *      *       0.0.0.0/0            0.0.0.0/0
     198    13201 ufw-after-logging-forward  all  --  *      *       0.0.0.0/0            0.0.0.0/0
     198    13201 ufw-reject-forward  all  --  *      *       0.0.0.0/0            0.0.0.0/0
     198    13201 ufw-track-forward  all  --  *      *       0.0.0.0/0            0.0.0.0/0
     198    13201 ACCEPT     all  --  wg0    *       0.0.0.0/0            0.0.0.0/0

sudo iptables-legacy -nvx -L FORWARD

Chain FORWARD (policy DROP 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
     501    82598 ufw-before-logging-forward  all  --  *      *       0.0.0.0/0            0.0.0.0/0
     501    82598 ufw-before-forward  all  --  *      *       0.0.0.0/0            0.0.0.0/0
     198    13201 ufw-after-forward  all  --  *      *       0.0.0.0/0            0.0.0.0/0
     198    13201 ufw-after-logging-forward  all  --  *      *       0.0.0.0/0            0.0.0.0/0
     198    13201 ufw-reject-forward  all  --  *      *       0.0.0.0/0            0.0.0.0/0
     198    13201 ufw-track-forward  all  --  *      *       0.0.0.0/0            0.0.0.0/0
     198    13201 ACCEPT     all  --  wg0    *       0.0.0.0/0            0.0.0.0/0

wg

interface: wg0
  public key: S............Y=
  private key: (hidden)
  listening port: 51820

peer: t........=
  endpoint: XX.YYY.ZZ.V:16341
  allowed ips: 192.168.66.3/32
  latest handshake: 3 minutes, 32 seconds ago
  transfer: 35.77 KiB received, 84.75 KiB sent

Ciao Gerd