ubuntuusers.de

Kannst du uns mal den Output geben von:

sudo iptables-save
ip r

Aktuell sieht mir das hier alles viel nach raten aus, und wenig strukturiert.

goerdi schrieb:

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

Hm, Du benutzt ufw.
Teste mal (temporär) mit _deaktiviertem_ ufw bzw. ohne irgendeine von ufw generierte/gesetzte iptables-Regeln und setze manuell die default policy der FORWARD chain auf ACCEPT und nur die s-nat-Regel (MASQUERADE) für das Lan-Interface:

sudo iptables -t nat -I POSTROUTING 1 -o enp4s0 -j MASQUERADE

Wenn es damit so funktioniert wie Du es haben willst, kannst Du diese s-nat-Regel wieder löschen:

sudo iptables -t nat -D POSTROUTING 1

ufw aktivieren und den Fehler (bei ufw?) suchen.

Hi !

iptables-save

# Generated by iptables-save v1.8.7 on Sun Jan 21 14:18:41 2024
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [9:304]
:ufw-after-forward - [0:0]
:ufw-after-input - [0:0]
:ufw-after-logging-forward - [0:0]
:ufw-after-logging-input - [0:0]
:ufw-after-logging-output - [0:0]
:ufw-after-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-before-input - [0:0]
:ufw-before-logging-forward - [0:0]
:ufw-before-logging-input - [0:0]
:ufw-before-logging-output - [0:0]
:ufw-before-output - [0:0]
:ufw-logging-allow - [0:0]
:ufw-logging-deny - [0:0]
:ufw-not-local - [0:0]
:ufw-reject-forward - [0:0]
:ufw-reject-input - [0:0]
:ufw-reject-output - [0:0]
:ufw-skip-to-policy-forward - [0:0]
:ufw-skip-to-policy-input - [0:0]
:ufw-skip-to-policy-output - [0:0]
:ufw-track-forward - [0:0]
:ufw-track-input - [0:0]
:ufw-track-output - [0:0]
:ufw-user-forward - [0:0]
:ufw-user-input - [0:0]
:ufw-user-limit - [0:0]
:ufw-user-limit-accept - [0:0]
:ufw-user-logging-forward - [0:0]
:ufw-user-logging-input - [0:0]
:ufw-user-logging-output - [0:0]
:ufw-user-output - [0:0]
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input
-A FORWARD -j ufw-before-logging-forward
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A FORWARD -j ufw-track-forward
-A FORWARD -i wg0 -j ACCEPT
-A OUTPUT -j ufw-before-logging-output
-A OUTPUT -j ufw-before-output
-A OUTPUT -j ufw-after-output
-A OUTPUT -j ufw-after-logging-output
-A OUTPUT -j ufw-reject-output
-A OUTPUT -j ufw-track-output
-A ufw-after-input -p udp -m udp --dport 137 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 138 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 139 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 445 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 67 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 68 -j ufw-skip-to-policy-input
-A ufw-after-input -m addrtype --dst-type BROADCAST -j ufw-skip-to-policy-input
-A ufw-after-logging-forward -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-forward -j ufw-user-forward
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP
-A ufw-before-input -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-input -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A ufw-before-input -j ufw-not-local
-A ufw-before-input -d 224.0.0.251/32 -p udp -m udp --dport 5353 -j ACCEPT
-A ufw-before-input -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j ACCEPT
-A ufw-before-input -j ufw-user-input
-A ufw-before-output -o lo -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -j ufw-user-output
-A ufw-logging-allow -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
-A ufw-logging-deny -m conntrack --ctstate INVALID -m limit --limit 3/min --limit-burst 10 -j RETURN
-A ufw-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP
-A ufw-skip-to-policy-forward -j DROP
-A ufw-skip-to-policy-input -j DROP
-A ufw-skip-to-policy-output -j ACCEPT
-A ufw-track-output -p tcp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-track-output -p udp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 22 -j ACCEPT
-A ufw-user-input -p tcp -m multiport --dports 80,443 -m comment --comment "\'dapp_ApacheFull\'" -j ACCEPT
-A ufw-user-input -d 192.168.0.0/16 -j ACCEPT
-A ufw-user-input -s 192.168.0.0/16 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 51280 -m comment --comment "\'dapp_Wireguard\'" -j ACCEPT
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable
-A ufw-user-limit-accept -j ACCEPT
COMMIT
# Completed on Sun Jan 21 14:18:41 2024
# Generated by iptables-save v1.8.7 on Sun Jan 21 14:18:41 2024
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o enp4s0 -j MASQUERADE
COMMIT
# Completed on Sun Jan 21 14:18:41 2024

ip r

default via 192.168.63.254 dev enp4s0 proto static
192.168.63.0/24 dev enp4s0 proto kernel scope link src 192.168.63.1
192.168.66.0/24 dev wg0 proto kernel scope link src 192.168.66.1

Ciao Gerd

encbladexp schrieb:

Kannst du uns mal den Output geben von:

sudo iptables-save
ip r

Aktuell sieht mir das hier alles viel nach raten aus, und wenig strukturiert.

Du hast eine MASQUERADING Regel auf enp4s0, alle Pakete von diesem Interface, werden immer die IP von diesem Interface haben.

encbladexp schrieb:

Du hast eine MASQUERADING Regel auf enp4s0, alle Pakete von diesem Interface, werden immer die IP von diesem Interface haben.

Dem TE geht es aber um die IP vom WG-Interface (und nicht um die IP vom enp4s0-Interface), denn er schreibt in seinem 1. Beitrag:

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.

Hi !

Hier mal eine Übersicht von meinem Netz

OVPN  192.168.99.0/24                                            PC 192.168.63.XX/24
OVPN  192.168.64.0/24     Router 192.168.63.254/24               PC 192.168.63.1/24  | 192.168.66.1/24	
Internet                              

Die Routen sind im Router und in einigen PCs für 192.168.66.0/24 hinterlegt. bei den OVPN netzen klappt das ja anstandslos weil halt der router eh das Gateway ist. Und auch werden im OVPN Netz auch die IPs aus der 192.168.63.XX richtig angezeigt (das macht aber der Router) leider ist es nicht moeglich Wireguard auf dem Router (ipfire) laufen zu lassen. auf der 192.168.63.1 laufen auch normalerweise ufw und fail2ban weil da noch ein paar Serverdienste laufen.

Meine Schwierigkeit ist nun die Pakete von Wireguard (192.168.66.0/24) korrekt durchs netz zu bringen... Es kann ja schon möglich sein das ufw mir da einen "Streich" spielt weil es "denkt" es würde auch einen Gateway (Internet router ) laufen. Evtl. muss mal ufw stilllegen oder so abändern das es keine Masquerading mehr macht.

in UFW steht aber schon als rule

Zu                         Aktion      Von
--                         ------      ---
192.168.0.0/16             ALLOW       Anywhere
Anywhere                   ALLOW       192.168.0.0/16

Gruss Gerd

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

Korreliert "IP des Wireguard Servers" mit der IP von enp4s0?

Hi !

Wie meinst du das ?

enp4s0 ⇒ 192.168.63.1/24 wg0 ⇒ 192.168.66.1/24

Gruss Gerd

Der Wireguard Server, hängt im Netz 192.168.63.0/24, die Wireguard Clients bekommen aus dem VPN eine IP vom Netz 192.168.66.0/24. Dein Problem ist, das wenn ein Wireguard Client, per VPN, auf einen Dienst im Netz 192.168.63.0/24 zugreift du dort die IP 192.168.63.1 siehst, aber du die von 192.168.66.0 sehen möchtest, korrekt?

Eventuell bin ich schwer von Begriff, und du kannst mir da helfen 😉

encbladexp schrieb:

Dein Problem ist, das wenn ein Wireguard Client, per VPN, auf einen Dienst im Netz 192.168.63.0/24 zugreift du dort die IP 192.168.63.1 siehst, aber du die von 192.168.66.0 sehen möchtest, korrekt?

Nein. Er sieht eine IP aus dem VPN-Netz (192.168.66.0/24), aber es ist nicht die IP vom WireGuard-Client (der per VPN zugreift), sondern die IP vom WireGuard-Server (als gateway im/des VPN).

Hi !

Es ist schon wie encbladexp ausführt, mit der Einstellung im ersten Post sehe ich wenn ich vom VPN auf ein Gerät im 192.168.63.0/24 zugreife die IP des Wireguards Servers und nicht die des VPN Clients. Evtl gehen wir das falsch an. Wir können ja mal ohne was starten und ich schreibe wie meinen UFW Rules aussehen, dann können wir ja daran "schrauben".

Gruss Gerd

goerdi schrieb:

Es ist schon wie encbladexp ausführt, mit der Einstellung im ersten Post sehe ich wenn ich vom VPN auf ein Gerät im 192.168.63.0/24 zugreife die IP des Wireguards Servers und nicht die des VPN Clients.

Ja, und welche IP-Adresse des VPN-Netzes (192.168.66.0/24) siehst Du? Die vom WG-Server oder die vom WG-Client?
Wo im VPN befindest Du dich? Auf dem WG-Server oder auf einem anderen WG-Client (... der nicht im Subnetz 192.168.63.0/24 ist)? Sind es verschiedene Internetanschlüsse?

goerdi schrieb:

Wir können ja mal ohne was starten und ich schreibe wie meinen UFW Rules aussehen, dann können wir ja daran "schrauben".

Warum hast Du ein Problem damit, die ufw _temporär_ zu deaktivieren bzw. nicht zu benutzen?

Hi !

IP Adresse ? keine vom VPN.... Also PC IP 192.168.63.1 ist zugleich das VPN Gateway 192.168.66.1. Verbinde ich mich jetzt auf dem Client 192.168.66.3 mit dem SSH Server von z.B. 192.168.63.90 sehe ich da die Verbindung als von der Adresse 192.168.63.1 kommend.

UFW ? Weil ich das eigentlich überall nutze, der Rechner ist zwar mitten im Netz (also nicht das gateway zum Internet) aber darauf laufen eben dievers Serverdienste welche ich mit Fail2ban schuetze und dieser wiederum mit ufw arbeitet (ich habe die gleiche Kontellation schon auf einer vps maschine laufen , da ist es für mich einfacher..

Gruss Gerd

goerdi schrieb:

IP Adresse ? keine vom VPN.... Also PC IP 192.168.63.1 ist zugleich das VPN Gateway 192.168.66.1. Verbinde ich mich jetzt auf dem Client 192.168.66.3 mit dem SSH Server von z.B. 192.168.63.90 sehe ich da die Verbindung als von der Adresse 192.168.63.1 kommend.

Ja OK, aber was hat eine SSH-Verbindung noch mit dem WireGuard-VPN zu tun? ... und noch dazu, wenn sich Client_1, Client_2 und Server im gleichen Subnetz befinden ...
Versuch mal folgende Konstellation:
WG-Client-1 ist am Internetanschluss A (Router mit dem Subnetz 192.168.61.0/24 macht NAT), WG-Client-2 ist am Internetanschluss B (Router mit dem Subnetz 192.168.62.0/24 macht NAT) und dein WG-Server ist an deinem Internetanschluss (C) (Router mit dem Subnetz 192.168.63.0/24 macht NAT).
Wenn Du jetzt via WG-VPN einen Ping vom WG-Client-1 auf den WG-Client-2 machst, welche IP-Adresse siehst Du am WG-Client-2 als source-IP-Adresse?

goerdi schrieb:

UFW ? Weil ich das eigentlich überall nutze, ...

Du darfst UFW ja auch weiter benutzen. Es geht nur um einen temporären Test und für diese Zeitdauer sollst Du UFW deaktivieren.

Hi !

Sie SSH Verbindung hat damit was zu tun dass sie von 192.168.66.3 kommt und nicht von 192.168.63.1

Temporär auszuschalten ist kein Problem

Ich mach jetzt mal folgendes 1. PostUp / PostDown aus wg0.conf raus 2. ufw stoppen

dann versuche ich mal zu verbinden (was zumindest gehen sollte da der port 51820 ja vom router auf die IP weitergeleitet wird. Danach schau ich mal was alles geht und was nicht.

Gruss Gerd