21.03.2024

1360

S2S VPN zwischen vServer und Firewall - MASQUERADE

Hallo allerseits,

ich habe mal wieder ein Anliegen.

Um dies alleine zu lösen reicht mein Verständnis leider nicht aus, und ich bin auf Hilfe angewiesen.

Folgendes:

Bei ionos habe ich einen vServer der mittels iptables alle Anfragen an 443 über einen S2S VPN Tunnel an meinen
NgnixRP weiterleitet. Funktioniert prima.

Jetzt möchte ich aber Fail2Ban einsetzen auf dem vServer um meine Dienste noch weiter abzusichern.
Die Logs werden vom Vaulwarden-Server an den vServer gesendet.
Auf dem Vaultwarden-Server sehe ich ja immer nur die Tunnel Adresse wenn eine Verbindung eingeht.
Schlägt Fail2Ban an, dann blockt es mir ja genau die IP vom VPN-Transfer-Netz. Nicht gut!

Ich glaube zu wissen, das ich mit iptables auf dem vServer das MASQUERADE ausschalten muss,
so das die richtige Absender-Adresse am Vaulwarden-Server zu sehen ist. An der Firewall muss ich den ins Internet gehenden Traffic des Vaultwarden-Server's auf den VPN Tunnel umleiten, so das der Vaultwarden-Server quasi über den vServer ins Internet geht..

Soweit die Theorie. Wie ich das allerdings praktisch umsetze.. keinen blassen Schimmer.

So schaut auf dem vServer die iptables aus:

root@vserver-ionos-vpn:~# iptables -t nat -vnL

Chain PREROUTING (policy ACCEPT 48 packets, 2616 bytes)
 pkts bytes target     prot opt in     out     source               destination
 112 DNAT       tcp  --  ens192 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:25 to:172.16.70.1:25 
5804 DNAT       tcp  --  ens192 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443 to:172.16.20.5:443

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

Chain OUTPUT (policy ACCEPT 34 packets, 4307 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
5799 MASQUERADE  all  --  *      *       0.0.0.0/0            0.0.0.0/0

root@vserver-ionos-vpn:~# iptables -vnL
Chain INPUT (policy ACCEPT 22726 packets, 2424K bytes)
 pkts bytes target     prot opt in     out     source               destination
   0 DROP       all  --  *      *       180.101.88.205       0.0.0.0/0
   0 DROP       all  --  *      *       193.32.162.11        0.0.0.0/0
   0 DROP       all  --  *      *       180.101.88.196       0.0.0.0/0
   0 DROP       all  --  *      *       195.72.145.14        0.0.0.0/0
   0 DROP       all  --  *      *       218.92.0.22          0.0.0.0/0
   0 DROP       all  --  *      *       198.211.124.50       0.0.0.0/0
   0 DROP       all  --  *      *       51.38.112.61         0.0.0.0/0
   0 DROP       all  --  *      *       194.169.175.36       0.0.0.0/0
   0 DROP       all  --  *      *       43.156.13.252        0.0.0.0/0
   0 DROP       all  --  *      *       164.90.236.141       0.0.0.0/0
   0 DROP       all  --  *      *       43.154.189.227       0.0.0.0/0
   0 DROP       all  --  *      *       43.134.7.162         0.0.0.0/0
   0 DROP       all  --  *      *       183.105.214.111      0.0.0.0/0
   0 DROP       all  --  *      *       85.240.58.125        0.0.0.0/0
   0 DROP       all  --  *      *       124.156.199.133      0.0.0.0/0
   0 DROP       all  --  *      *       94.179.133.22        0.0.0.0/0
   0 DROP       all  --  *      *       218.92.0.24          0.0.0.0/0
   0 DROP       all  --  *      *       165.232.166.202      0.0.0.0/0
   0 DROP       all  --  *      *       114.34.142.75        0.0.0.0/0
   0 DROP       all  --  *      *       218.92.0.29          0.0.0.0/0
  40 DROP       all  --  *      *       179.43.180.106       0.0.0.0/0
   0 DROP       all  --  *      *       203.228.7.104        0.0.0.0/0
   0 DROP       all  --  *      *       213.109.202.127      0.0.0.0/0
   0 DROP       all  --  *      *       95.156.96.46         0.0.0.0/0
   0 DROP       all  --  *      *       185.161.248.218      0.0.0.0/0
   0 DROP       all  --  *      *       218.92.0.22          0.0.0.0/0
   0 DROP       all  --  *      *       43.155.166.220       0.0.0.0/0
   0 DROP       all  --  *      *       167.172.157.140      0.0.0.0/0
   0 DROP       all  --  *      *       117.239.253.153      0.0.0.0/0
   0 DROP       all  --  *      *       188.166.250.251      0.0.0.0/0
   0 DROP       all  --  *      *       43.156.48.140        0.0.0.0/0
   0 DROP       all  --  *      *       189.112.0.11         0.0.0.0/0
   0 DROP       all  --  *      *       43.153.223.232       0.0.0.0/0
   0 DROP       all  --  *      *       159.223.148.156      0.0.0.0/0
   0 DROP       all  --  *      *       119.28.111.112       0.0.0.0/0
   0 DROP       all  --  *      *       43.135.167.165       0.0.0.0/0
   0 DROP       all  --  *      *       61.177.172.136       0.0.0.0/0
   0 DROP       all  --  *      *       61.177.172.160       0.0.0.0/0
1799K DROP       all  --  ens192 *       0.0.0.0/0            0.0.0.0/0            -m geoip ! --source-country DE

Chain FORWARD (policy ACCEPT 7561 packets, 2807K bytes)
 pkts bytes target     prot opt in     out     source               destination
   0 DROP       all  --  *      *       180.101.88.205       0.0.0.0/0
   0 DROP       all  --  *      *       193.32.162.11        0.0.0.0/0
   0 DROP       all  --  *      *       180.101.88.196       0.0.0.0/0
   0 DROP       all  --  *      *       195.72.145.14        0.0.0.0/0
   0 DROP       all  --  *      *       218.92.0.22          0.0.0.0/0
   0 DROP       all  --  *      *       198.211.124.50       0.0.0.0/0
   0 DROP       all  --  *      *       51.38.112.61         0.0.0.0/0
   0 DROP       all  --  *      *       194.169.175.36       0.0.0.0/0
   0 DROP       all  --  *      *       43.156.13.252        0.0.0.0/0
   0 DROP       all  --  *      *       164.90.236.141       0.0.0.0/0
   0 DROP       all  --  *      *       43.154.189.227       0.0.0.0/0
   0 DROP       all  --  *      *       43.134.7.162         0.0.0.0/0
   0 DROP       all  --  *      *       183.105.214.111      0.0.0.0/0
   0 DROP       all  --  *      *       85.240.58.125        0.0.0.0/0
   0 DROP       all  --  *      *       124.156.199.133      0.0.0.0/0
   0 DROP       all  --  *      *       94.179.133.22        0.0.0.0/0
   0 DROP       all  --  *      *       218.92.0.24          0.0.0.0/0
   0 DROP       all  --  *      *       165.232.166.202      0.0.0.0/0
   0 DROP       all  --  *      *       114.34.142.75        0.0.0.0/0
   0 DROP       all  --  *      *       218.92.0.29          0.0.0.0/0
   0 DROP       all  --  *      *       179.43.180.106       0.0.0.0/0
   0 DROP       all  --  *      *       203.228.7.104        0.0.0.0/0
   0 DROP       all  --  *      *       213.109.202.127      0.0.0.0/0
   0 DROP       all  --  *      *       95.156.96.46         0.0.0.0/0
   0 DROP       all  --  *      *       185.161.248.218      0.0.0.0/0
   0 DROP       all  --  *      *       218.92.0.22          0.0.0.0/0
   0 DROP       all  --  *      *       43.155.166.220       0.0.0.0/0
   0 DROP       all  --  *      *       167.172.157.140      0.0.0.0/0
   0 DROP       all  --  *      *       117.239.253.153      0.0.0.0/0
   0 DROP       all  --  *      *       188.166.250.251      0.0.0.0/0
   0 DROP       all  --  *      *       43.156.48.140        0.0.0.0/0
   0 DROP       all  --  *      *       189.112.0.11         0.0.0.0/0
   0 DROP       all  --  *      *       43.153.223.232       0.0.0.0/0
   0 DROP       all  --  *      *       159.223.148.156      0.0.0.0/0
   0 DROP       all  --  *      *       119.28.111.112       0.0.0.0/0
   0 DROP       all  --  *      *       43.135.167.165       0.0.0.0/0
   0 DROP       all  --  *      *       61.177.172.136       0.0.0.0/0
   0 DROP       all  --  *      *       61.177.172.160       0.0.0.0/0
4424 LOG        all  --  ens192 *       0.0.0.0/0            0.0.0.0/0            -m geoip ! --source-country DE,NL,IE  LOG flags 0 level 4 prefix "GeopIP_Block_FC "  
4424 DROP       all  --  ens192 *       0.0.0.0/0            0.0.0.0/0            -m geoip ! --source-country DE,NL,IE

Chain OUTPUT (policy ACCEPT 25757 packets, 20M bytes)
 pkts bytes target     prot opt in     out     source               destination
root@vserver-ionos-vpn:~#

Die ganzen geblockten IP's werden von Wazuh geblockt, wegen SSH Bruteforce.

Wie das ganze Routing auf der Firewall eingerichtet wird, wird mir hoffentlich der Support des Herstellers in Unterstützung sagen können.

Wobei ich nun Unterstützung bräuchte, ist bei der Konfiguration von den iptables, so das die puplic ip des Absenders am Vaultwarden-Server in den Log's zu sehen ist.

Ich sag schon mal danke.

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

Content-ID: 62258403373

Url: https://administrator.de/contentid/62258403373

Ausgedruckt am: 21.11.2024 um 18:11 Uhr

25 Kommentare

Neuester Kommentar

Moin.

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

Deine Masquerade regel inkludiert zu viele Interfaces, somit werden auch Pakete nach intern über den Tunnel maskiert (also die Quelladresse auf die des vServers umgeschrieben) was dein Problem verursacht. Schränke sie stattdessen nur auf Traffic ein welches das WAN Interface ens192 am vServer von innen nach außen verlässt, also bspw. die obige Regel ersetzen durch:

iptables -t nat -A POSTROUTING -o ens192 -j MASQUERADE

Aber Achtung !! Bei dieser Variante musst du beachten das du den Antwort-Traffic auf dem Server daheim wieder über den Tunnel schickst, also bspw. auf deiner Firewall Routing-Tags zu dieser Verbindung hinzufügst oder per Policy Routing das Default GW für den Server auf den Tunnel legst, weil die Pakete sonst über den Internet-Anschluss deines Servers wieder raus gehen und es zu asynchronem Routing und dementsprechend keiner Verbindung kommt!

Routing zwischen zwei PfSense - Nutzung von public IP

Gruß pp

Danke.

Das habe ich verstanden.

HIER ist diese Thematik des asynchonen Routings auch noch einmal recht gut beschrieben.

So, habe mit Hilfe des Support das Routing auf der Firewall konfigurieren können. Eigentlich ganz einfach, wen man weiß wie...

Der Linux-Server hinter der UTM geht jetzt über das VPN raus. Bekomme aber kein Ping Replay.

So schauen immer noch die iptables auf dem vServer aus:

root@vserver-ionos-vpn:~# iptables -t nat -vnL
Chain PREROUTING (policy ACCEPT 6 packets, 348 bytes)
 pkts bytes target     prot opt in     out     source               destination
       0     0 DNAT       tcp  --  ens192 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443 to:172.16.20.5:443

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
    6   348 MASQUERADE  all  --  *      *       0.0.0.0/0            0.0.0.0/0
root@vserver-ionos-vpn:~#

Ein tcpdump auf dem vServer verrät mir, das der Request und der Replay am vServer ankommt.
Ping wurde vom Linux-Server hinter der UTM abgeschickt.

root@vserver-ionos-vpn:~# tcpdump icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens192, link-type EN10MB (Ethernet), snapshot length 262144 bytes
33:54.106500 IP meine-domain.de > one.one.one.one: ICMP echo request, id 16, seq 1, length 64
33:54.113139 IP one.one.one.one > meine-domain.de: ICMP echo reply, id 16, seq 1, length 64
33:55.129512 IP meine-domain.de > one.one.one.one: ICMP echo request, id 16, seq 2, length 64
33:55.136157 IP one.one.one.one > meine-domain.de: ICMP echo reply, id 16, seq 2, length 64
33:56.170331 IP meine-domain.de > one.one.one.one: ICMP echo request, id 16, seq 3, length 64
33:56.176807 IP one.one.one.one > meine-domain.de: ICMP echo reply, id 16, seq 3, length 64
33:57.177657 IP meine-domain.de > one.one.one.one: ICMP echo request, id 16, seq 4, length 64
33:57.184190 IP one.one.one.one > meine-domain.de: ICMP echo reply, id 16, seq 4, length 64

Aber der Request dringt nicht bis zum Absender, dem Linux-Server vor:

sysadmin@docker-vm01:~$ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
^C
--- 1.1.1.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2039ms

@puderpader

iptables -t nat -A POSTROUTING -o ens192 -j MASQUERADE

Brachte leider nicht das erhoffte Ergebnis.

Im Vaultwarden Log steht immer noch die TunnelIP.

[2024-03-22 17:25:07.112][request][INFO] GET /api/config
[2024-03-22 17:25:07.113][response][INFO] (config) GET /api/config => 200 OK
[2024-03-22 17:25:24.053][request][INFO] GET /api/devices/knowndevice
[2024-03-22 17:25:24.054][response][INFO] (get_known_device) GET /api/devices/knowndevice => 200 OK
[2024-03-22 17:25:28.338][request][INFO] POST /identity/accounts/prelogin
[2024-03-22 17:25:28.338][response][INFO] (prelogin) POST /identity/accounts/prelogin => 200 OK
[2024-03-22 17:25:28.593][request][INFO] POST /identity/connect/token
[2024-03-22 17:25:28.984][vaultwarden::api::identity][ERROR] Username or password is incorrect. Try again. IP: 10.8.0.1. Username: meineemail@hotmail.de.
[2024-03-22 17:25:28.985][response][INFO] (login) POST /identity/connect/token => 400 Bad Request
root@48d37998615c:/var/log# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
^C
--- 1.1.1.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2047ms

root@48d37998615c:/var/log# ^C
root@48d37998615c:/var/log# 

Ich lese wirklich viel und versuche alles zu verstehen. Leider verstehe ich das ganze iptables und masquerade Zeugs noch nicht vollständig.

Ich bin leider weiter auf die Hilfe des Forums angewiesen und hoffe das ich mein Problem mit eurer Hilfe gelöst bekomme.

Ping am Zielserver ist wenig zielführend.

Ein Traceroute (mit -n (deaktivieres DNS Lookup, bzw. -d Winblows tracert) wäre da hilfreicher um die verwendeten Router Hops sehen zu können. Idealerweise lässt man dann am Ziel einen tcpdump laufen um zu sehen das die ICMP Echo Requests dort ankommen.
Sendet der Zielserver den Antworttraffic NICHT auf dem gleichen Wege via vServer zurück sondern direkt am lokalen Router hast du genau die Thematik mit dem asynchronen Routing. Das kannst du nur sehen wenn du die Ziel IPs sehen kannst.

Danke aqui, jetzt bin ich völlig verwirrt.

Hier mal das traceroute vom Linux-Server(Steht bei mir Daheim) hinter der UTM:

sysadmin@docker-vm01:~$ traceroute -n 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
172.16.20.254  0.450 ms  1.394 ms  1.502 ms
10.8.0.1  15.373 ms  15.363 ms  15.333 ms
* * *
93.90.196.13  33.945 ms 93.90.196.12  33.930 ms 93.90.196.13  33.889 ms
212.227.121.90  33.910 ms  33.878 ms  33.864 ms
212.227.117.7  38.404 ms  38.183 ms 212.227.120.226  33.107 ms
193.239.117.14  39.104 ms 212.227.117.7  23.719 ms 193.239.117.14  25.004 ms
172.70.248.5  24.478 ms 193.239.117.14  40.467 ms 172.70.248.5  38.375 ms
162.158.84.55  38.313 ms  38.281 ms *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
sysadmin@docker-vm01:~$

Die IP vom vServer ist nicht im traceroute zu sehen.

Wie zu erkenn ist, geht der Traffic wie gewollt über den Tunnel zum vServer ins Internet.

Idealerweise lässt man dann am Ziel einen tcpdump laufen um zu sehen das die ICMP Echo Requests dort ankommen.

Verstehe ich nicht ganz. Ich hab am Ziel Server ja gesehen das der Echo Request nicht am Ziel Server ankommt, aber dafür am vServer. Vom vServer aus scheint es so, als ob der Traffic(Echo Request) nicht weitergeiltet wird zum Ziel Server.

Hab jetzt also das Traceroute ausgeführt und weiß, das der Trraffic über den vServer raus geht aber der Echo Request nicht am Ziel Server ankommt.

Wie zu erkenn ist, geht der Traffic wie gewollt über den Tunnel zum vServer ins Internet.

Richtig! Und vermutlich dort auch richtig geNATet raus ins Internet sonst würdest du die folgenden IPs nicht sehen können da ohne NAT deine Absende RFC1918 IP verworfen wäre.
Das müsstest du jetzt nochmal in die andere Richtung machen um das zu sehen. ICMP geht aber nicht da du das Tunneling ins VPN ja nur mit TCP 443 machst. Sprich nur TCP 443 Traffic wird so transportiert aber kein ICMP.
Alternativ könntest du ein TCP basiertes Ping Tool verwenden auf 443.
Dazu müsstest du einen remoten Client nehmen dort mit dem Browser oder "telnet <ziel_ip> 443" mal einen Connectversuch triggern und dir mit tcpdump ansehen ob a: die Pakete mit richtiger IP Adressierung in den Tunnel sehen und b: mit tcpdump ob sie auch am Zielserver hinter der UTM ankommen.
Dient ja nur dazu zu checken ob das Masquerading überall korrekt ist.

Danke aqui.

Das teste ich aber erst morgen. Essen ist feritg

Danke vielmals....

Du musst deine Masquerade Regel mit meiner ersetzen nicht einfach nur hinzufügen, denn sonst greift ja deine alte Regel noch die ja viel zu viel unnötig maskiert!!
First match wins gilt auch im POSTROUTING!

@aqui Du hast absolut Recht. Ich müste natürlich den ICMP Traffic auch forwarden, deshalb kommt der Echo Request zwar am vServer an ab er nicht am Ziel-Server.
Soweit ist dann ja alles korrekt konfiguriert.
Darum kümmere ich mich später.

Wichtig ist mir, das die korrekte IP im Linux-Server Log auftauscht und nicht die des Tunnels.

@puderpader
Hatte ich getan.

Habe:

iptables -t nat -D POSTROUTING 1
iptables -t nat -A POSTROUTING -o ens192 -j MASQUERADE

Würde aber bedeuten, das Traffic der das Intergace ens192 verlässt, mit der IP des vServers maskiert wird.

Das würde bedeuten, in meinem Vaultwarden Log würde bei einem Loginversuch, wen das Password falsch eingegeben wurde, immer die IP vom vServer stehen. Wenn dann noch Fail2Ban greift, sperre ich den vServer und es kommen überhaupt keine ANfragen mehr am Linux-Server an.

So schauts aus:

root@vserver-ionos-vpn:~# iptables -t nat -vnL
Chain PREROUTING (policy ACCEPT 8 packets, 501 bytes)
 pkts bytes target     prot opt in     out     source               destination
       0     0 DNAT       tcp  --  ens192 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443 to:172.16.20.5:443

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
    8   501 MASQUERADE  all  --  *      ens192  0.0.0.0/0            0.0.0.0/0
root@vserver-ionos-vpn:~#

Jetzt kann ich meine Dienste nicht mehr aufrufen.

Die Anfrage kommt am vServer an, wird aber nicht weitergeleitet.

wird aber nicht weitergeleitet.

Da wäre dann mit ip r nochmal die Routing Tabelle hilfreich.

Die Routingtabelle auf dem vServer schaut so aus:

root@vserver-ionos-vpn:~# ip r
default via 10.255.255.1 dev ens192
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
10.255.255.1 dev ens192 scope link
172.16.20.0/24 via 10.8.0.2 dev tun0
172.16.70.0/24 via 10.8.0.2 dev tun0
root@vserver-ionos-vpn:~#

Für mich ergibt das mit dem MASQUERADE keinen Sinn.

Ich verstehe das so:

Das Interface ens192 vom vServer hat eine Puplic IP, sagen wir mal die 83.40.1.5

iptables -t nat -A POSTROUTING -o ens192 -j MASQUERADE

Tut nichts anderes als in den Ip Paketen die Absender Adresse mit der des ens192 Interfaces zu ersetzen.
Heißt also, das am Ziel Server, dem Linux-Server auf dem mein Vaultwarden läuft, statt der Tunnel IP,
die IP vom ens192 Interface des vServes angezeigt wird. Das ist ja so aber nicht gewollt.

Ich möchte die Puplic IP vom Client, der eine Verbindung mit dem Vaultwarden Server aufbaut im LOG stehen haben,
um diese mit Fail2Ban auch blockieren zu können, nach 3 falschen Anmeldeversuchen.

Ich habe den Eindruck, das meine Erklärung oben eventuell falsch verstanden wurde.

Also noch mal:

Sagen wir ein Bekantner ruft meine Seite von seinem Internet Anschluss aus auf.
IP vom Bekannten: 80.80.80.80

tresor.meinedomain.de(A Record zeigt auf meinen vServer bei ionos)
vServer IP: 100.100.100.100

Der vServer schickt die Anfrage weiter über den SSL Tunnel an meine UTM.
An der UTM werden alle https Anfragen die von S2S Tunnel kommen,
an den Nginx Reverse Proxy weitergeleitet. Der Nginx RP leitet weiter zum eigentlichen Server.

Der Vaultwarde Server Logt alle Verbindungen mit.
Ich möchte also das die Puplic Ip meines bekannten in dem Log steht, und nicht die des Tunnel-Interfaces oder die des vServer ens192 Interfaces.

vom vServer hat eine Puplic IP

Pupsen tut der arme Kerl hoffentlich nicht.

Tut nichts anderes als in den Ip Paketen die Absender Adresse mit der des ens192 Interfaces zu ersetzen.

Man achte auf die Chain "Postrouting"! Er macht das nur wenn vorab geroutete Frames den Server wieder ausgehend verlassen (-o).

Das ist ja so aber nicht gewollt.

Das ist per se richtig aber dein Linux Server und deine lokalen 172.16er Netze erreicht er ja ausgehend zum Ziel mitnichten über das ens192 Interface sondern über das tun0 VPN Interface. Folglich findet dann auch kein Masquerading mit der ens192 IP statt.
Das Masquerading muss hier also über das 10er tun0 Interface passieren, damit die Zielrechner im 10.8er und den 172er Netzen die 10.8er IP als Absender "sehen" um den Rücktraffic auch wieder über den Tunnel zu schicken und nicht lokal zu routen wie es in den o.a. Threads beschrieben ist. Andernfalls rennst du ins Problem asymetrisches Routing.
Bedeutet im Umkehrschluß aber auch das du die am Jumphost eingehenden Client Verbindungen nicht mehr mit ihren Original IPs dort siehst, denn die müssen ja zwangsläufig in die Tunnel IP geNATet werden eben wegen des Rücktraffics vom Ziel der via Tunnel gehen muss. An den Zielhosts wirst du also nix mit fail2ban und Logging. Nicht das du hier einen Denkfehler machst?!

HIER kannst du sehen wie das mit einem IPsec Jumphost mit NGINX Proxy und nftables gelöst ist.

Zitat von @Ueba3ba:

Für mich ergibt das mit dem MASQUERADE keinen Sinn.

Ich verstehe das so:

Das Interface ens192 vom vServer hat eine Puplic IP, sagen wir mal die 83.40.1.5

iptables -t nat -A POSTROUTING -o ens192 -j MASQUERADE

Tut nichts anderes als in den Ip Paketen die Absender Adresse mit der des ens192 Interfaces zu ersetzen.

Falsch. Nur ausgehende Pakete die das WAN Interface ausgehend verlassen deren Quelladresse wird auf die des WAN Ports umgeschrieben! Deswegen ja die Option -o (für out-interface).
Geforwardete Pakete vom WAN in den Tunnel werden dadurch nicht mehr umgeschrieben, die Quelladresse des Clients bleibt also gleich.
Und weil die Pakete mit einer öffentlichen Adresse auf deinem Server ankommen müssen diese auch wieder über den Tunnel zurückgeschickt werden entweder via Policy-Route oder Routing-Tags die der eingehenden Verbindung hinzugefügt werden und dann die Rück-Pakete durch die Tags automatisch über den Tunnel geschickt werden.

Heißt also, das am Ziel Server, dem Linux-Server auf dem mein Vaultwarden läuft, statt der Tunnel IP,
die IP vom ens192 Interface des vServes angezeigt wird.

Nein, wie geschrieben wird nur SRCNAT gemacht wenn Pakete den WAN Port nach außen verlassen nicht nach innen!

Ich möchte die Puplic IP vom Client, der eine Verbindung mit dem Vaultwarden Server aufbaut im LOG stehen haben,
um diese mit Fail2Ban auch blockieren zu können, nach 3 falschen Anmeldeversuchen.

Schon verstanden

Ich habe den Eindruck, das meine Erklärung oben eventuell falsch verstanden wurde.

Nöp, war alles klar.

Schau dir dazu auch diesen Thread an
Routing zwischen zwei PfSense - Nutzung von public IP
Da wird es auch sehr detailliert erklärt.

Servus, so, es kann weiter gehen.

Schau dir dazu auch diesen Thread an
Routing zwischen zwei PfSense - Nutzung von public IP
Da wird es auch sehr detailliert erklärt.

Das habe ich soweit verstande.
Nur habe ich keine PfSense im Einsatz, sondern eine Securepoint UTM(Hab eine NFR Lizenz)

Die Route ist eingerichtet.
Das Regelwerk auch.

Bei der Securepoint UTM habe ich keine Möglichkeit wie bei der PfSense eine Policy-Route oder Routing-Tags zu konfigurieren.

Konfiguriert ist es wie auf den Bildern zu sehen.

Ich habe aus:

iptables -t nat -A POSTROUTING -o ens192 -j MASQUERADE

wieder:

iptables -t nat -A POSTROUTING -j MASQUERADE

gemacht, da sonst nicht mehr funktioniert.

Anfragen kommen dann zwar am vServer an mit,

iptables -t nat -A POSTROUTING -o ens192 -j MASQUERADE

, dann ist aber auch wieder Schluss.

Du musst auch darauf achten das der NginxRP im vServer via VPN Tunnel die Tunnel IP als Absender verwendet (proxy_bind <tun0_ip>):

server {
        listen 8080;
        listen [::]:8080;

        location / {
                proxy_bind <tun0_ip>;
                proxy_pass http://172.16.20.5:80;
                include proxy_params;
                }
} 

Denn so bekommen diese Frames die Richtung Server gehen eine Tunnel Absender IP damit die Rückroute am Zielserver 172.16.20.5 auch wieder in den Tunnel geht ansonsten droht dir wieder asymetrisches Routing und Session Abbruch.
Zumindestens für den Proxy Traffic erspart dir das auch das NAT.

Zitat von @Ueba3ba:

>
wieder:

iptables -t nat -A POSTROUTING -j MASQUERADE

gemacht, da sonst nicht mehr funktioniert.

Das ist aber eben gerade Bullshit weil dann die Quelladresse über den Tunnel auf die des Tunnels umgeschrieben wird !!!

Anfragen kommen dann zwar am vServer an mit,

iptables -t nat -A POSTROUTING -o ens192 -j MASQUERADE

, dann ist aber auch wieder Schluss.

Dann hast du in der Firewall der UTM den Traffic aus dem Internet über den Tunnel eingehend nicht erlaubt !

Hier muss es eine eingehende Regel geben, die so aussieht

Quelle = 0.0.0.0/0 bzw. any
Quellport = any
Quellinterface = tun1
Ziel = 172.16.20.5/32
Zielport = 443/TCP
ZielInterface = <Interface des Servers>

Zitat von @aqui:

Du musst auch darauf achten das der NginxRP im vServer via VPN Tunnel die Tunnel IP als Absender verwendet (proxy_bind <tun0_ip>):

server {
        listen 8080;
        listen [::]:8080;

        location / {
                proxy_bind <tun0_ip>;
                proxy_pass http://172.16.20.5:80;
                include proxy_params;
                }
} 

Das will er ja doch aber gerade nicht! Er will die externe IP des Clients direkt am Server anliegen haben.
Das Default GW hat er für den Server schon per Policy Route auf den Tunnel gelegt, also ist asynchrones Routing dann ausgeschlossen.
Ich denke deshalb das die Firewall der UTM den Internet Traffic mit den öffentlichen IPs eingehend über tun1 blockiert.
Das sollte er ja an seinen Logs sehen, aber das ist ja Montag mal wieder zuuuu leicht da einfach mal rein zu schauen.

Das sollte er ja an seinen Logs sehen, aber das ist ja Montag mal wieder zuuuu leicht da einfach mal rein zu schauen.

Upps, ja das Log der UTM.

Da sollte ich wirklich mal reinschauen.

Das will er ja doch aber gerade nicht! Er will die externe IP des Clients direkt am Server anliegen haben.

Mist, sorry. 🤦‍♂️ Hab ich im Eifer des Gefechts mal wieder übersehen... Vergiss was da steht. Wollte hier keine Verwirrung stiften.

Danke aqui und puderpader.

Folgendes:

Am vServer ist iptables MASQUERADE richtig gesetzt:

^Croot@vserver-ionos-vpn:~# iptables -t nat -vnL
Chain PREROUTING (policy ACCEPT 736 packets, 45264 bytes)
 pkts bytes target     prot opt in     out     source               destination
  199 11856 DNAT       tcp  --  ens192 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443 to:172.16.20.5:443

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

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

Chain POSTROUTING (policy ACCEPT 40 packets, 5069 bytes)
 pkts bytes target     prot opt in     out     source               destination
  622 39338 MASQUERADE  all  --  *      ens192  0.0.0.0/0            0.0.0.0/0
root@vserver-ionos-vpn:~#

Traffic vom Linux Server(hinter der UTM) geht über den vServer raus.

sysadmin@docker-vm01:~$ traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
172.16.20.254 (172.16.20.254)  0.382 ms  1.205 ms  1.423 ms
10.8.0.1 (10.8.0.1)  14.216 ms  14.201 ms  14.514 ms
* * *
93.90.196.13 (93.90.196.13)  44.252 ms 93.90.196.12 (93.90.196.12)  44.111 ms  44.157 ms
212.227.121.226 (212.227.121.226)  44.660 ms  44.562 ms 212.227.121.90 (212.227.121.90)  44.906 ms
212.227.117.7 (212.227.117.7)  49.848 ms  20.774 ms  23.162 ms
193.239.117.14 (193.239.117.14)  70.496 ms  70.505 ms 212.227.117.7 (212.227.117.7)  25.444 ms

Regel an der UTM Firewall angelegt. Siehe Bild.

Aufruf des Vaultwarden über mein Handy:

root@vserver-ionos-vpn:~# tcpdump port 443
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens192, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:21:02.871246 IP 104.28.62.57.60388 > meine.domain.de.https: Flags [S], seq 1442198677, win 64240, options [mss 1380,sackOK,TS val 3712101540 ecr 0,nop,wscale 13], length 0
18:21:03.895580 IP 104.28.62.57.60388 > meine.domain.de.https: Flags [S], seq 1442198677, win 64240, options [mss 1380,sackOK,TS val 3712102565 ecr 0,nop,wscale 13], length 0
18:21:05.943685 IP 104.28.62.57.60388 > meine.domain.de.https: Flags [S], seq 1442198677, win 64240, options [mss 1380,sackOK,TS val 3712104613 ecr 0,nop,wscale 13], length 0
18:21:09.976804 IP 104.28.62.57.60388 > meine.domain.de.https: Flags [S], seq 1442198677, win 64240, options [mss 1380,sackOK,TS val 3712108646 ecr 0,nop,wscale 13], length 0
18:21:18.041705 IP 104.28.147.196.35194 > meine.domain.de.https: Flags [S], seq 1230170274, win 64240, options [mss 1380,sackOK,TS val 98912388 ecr 0,nop,wscale 13], length 0
18:21:19.085308 IP 104.28.147.196.35194 > meine.domain.de.https: Flags [S], seq 1230170274, win 64240, options [mss 1380,sackOK,TS val 98913432 ecr 0,nop,wscale 13], length 0

Seite ist nicht aufrufbar.

Firewall LOG zeigt nichts relevantes an.

VPN-Internet hat die Zone des Tunnels

Ich werd verrückt. Eben hat sich die Seite auf dem Handy laden lassen.

Und siehe da, im Log steht tatsächlich die Puplic IP vom Client.

[2024-03-25 20:42:22.082][response][INFO] (get_known_device) GET /api/devices/knowndevice => 200 OK
[2024-03-25 20:42:25.531][request][INFO] POST /identity/accounts/prelogin
[2024-03-25 20:42:25.531][response][INFO] (prelogin) POST /identity/accounts/prelogin => 200 OK
[2024-03-25 20:42:25.890][request][INFO] POST /identity/connect/token
[2024-03-25 20:42:25.890][vaultwarden::api::identity][ERROR] Username or password is incorrect. Try again. IP: 172.225.195.2. Username: huj@uhh.de.
[2024-03-25 20:42:25.890][response][INFO] (login) POST /identity/connect/token => 400 Bad Request
root@48d37998615c:/var/log# ^C
root@48d37998615c:/var/log# 

Freunde, ich danke euch für eure Unterstützung.