Proxmox VE GUI nicht über VPN-Tunnel erreichbar

magicpeter · Dec 9, 2024

Moin,
ich betreibe ein Netzwerk mit
2xPVE 8.31 Nodes im Cluster, Lancom Firewall, QNAP NAS
Ich arbeite oft von Zuhause und verbindle mich dann per VPN-Tunnel mit der Firewall und dem Netzwerk.
Ich kann alle Geräte an pingen und auch mich per RDP mit der Windows 2025 VM verbinden, aber auf die PVE GUI komme ich nicht..
Für den VPN-Tunnel SSL sind Ping, http, https, RDP und 8006, 8007 Ports freigeben.
Ich habe auch schon mal alle Ports freigeben, es klappt aber trotzdem nicht.

Firmennetzwerk: 192.168.2.0/24
Heimnetzwerk: 192.168.111.0/24
VPN-Netzwerk: 192.168.254.0/24

Warum klappen alle anderen Geräte nur beiden PVE Nodes nicht?

Mein Browser sagt nur die Seite kann nicht geöffnet werden.

Hat eine eine Idee?

Wäre schon wichtig für die Fernwartung der Nodes.

Danke euch....

fba · Dec 9, 2024

Hi,

wenn Ping auf die PVE-Nodes funktioniert, und Du für die GUI die gleiche IP nutzt, dann wirds wohl doch an der Firewall liegen.
Geht kein Ping, dann liegt es häufig an fehlenden Routing-Einträgen, z. B. der Hinweg geht, aber der Rückweg dann nicht, weil das falsche Gateway genutzt wird.

magicpeter · Dec 9, 2024

fba said:
Hi,

wenn Ping auf die PVE-Nodes funktioniert, und Du für die GUI die gleiche IP nutzt, dann wirds wohl doch an der Firewall liegen.
Geht kein Ping, dann liegt es häufig an fehlenden Routing-Einträgen, z. B. der Hinweg geht, aber der Rückweg dann nicht, weil das falsche Gateway genutzt wird.

Ich habe einmal ein Ticket beim Hersteller Lancom aufgemacht. Mal schauen was die so sagen.

Nur zur Sicherheit, welche Ports werden für den Aufruf der PVE GUI benötigt?

https://192.168.2.16:8006/

Port 8006, 443??

Oder sind da noch mehr Ports die offen ein müssen?

fba · Dec 10, 2024

magicpeter said:
Oder sind da noch mehr Ports die offen ein müssen?

In der Doku sind alle Ports und deren Verwendung aufgelistet: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_ports_used_by_proxmox_ve

magicpeter · Dec 10, 2024

fba said:
In der Doku sind alle Ports und deren Verwendung aufgelistet: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_ports_used_by_proxmox_ve

Könnte es nicht sein das die PVE Firewall da etwas gegen hat wenn man über einen VPN-Tunnel auf die GUI, SSH, etc. zugreift?
Müssen da irgendwelche Einstellungen gemacht werden?

Falk R. · Dec 10, 2024

Dem PVE ist da so etwas von egal. Kommst du per ssh an den PVE? Manchem Firewalls muss man noch beibringen, dass https Traffic über Port 8006 geht und der erlaubt werden soll.
Zu 99% liegt das Problem an der Firewall.

magicpeter · Dec 10, 2024

Falk R. said:
Dem PVE ist da so etwas von egal. Kommst du per ssh an den PVE? Manchem Firewalls muss man noch beibringen, dass https Traffic über Port 8006 geht und der erlaubt werden soll.
Zu 99% liegt das Problem an der Firewall.

Nein, ich komme gar nicht über den VPN-Tunnel auf den PVE weder per SSH noch per HHPS, 8006. Ich komme in der Netz und kann dort auf die VMs per RDP zugreifen.

beisser · Dec 10, 2024

banale frage, haben die pve-server das korrekte gateway?
wenn du die vms im gleichen netz erreichst, dann haben die offensichtlich das korrekte default gateway.
zeig uns doch mal deine netzwerkkonfig vom host und sag uns die ip vom lancom router im lan.

magicpeter · Dec 10, 2024

Moin,
der LANcom Router / Firewall hat die IP 192.168.2.254
Ich schau mal eben, aber ich meine das wäre auch 192.168.2.254

nano /etc/network/interfaces

auto lo
iface lo inet loopback

iface enp2s0 inet manual

iface enp3s0 inet manual

auto enp1s0f0
iface enp1s0f0 inet static
address 192.168.20.14/24
#cluster

iface enp1s0f1 inet manual

auto vmbr0
iface vmbr0 inet static
address 192.168.2.16/24
gateway 192.168.2.254
bridge-ports enp2s0
bridge-stp off
bridge-fd 0

iface vmbr1 inet manual

source /etc/network/interfaces.d/*

Das sollte doch so passen oder?

Der DNS auf den Nodes ist auch die 192.168.2.254

ip a

root@node1:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
link/ether a8:b8:e0:06:7c:93 brd ff:ff:ff:ff:ff:ff
3: enp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether a8:b8:e0:06:7c:94 brd ff:ff:ff:ff:ff:ff
4: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether a8:b8:e0:06:7c:91 brd ff:ff:ff:ff:ff:ff
inet 192.168.20.14/24 scope global enp1s0f0
valid_lft forever preferred_lft forever
inet6 fe80::aab8:e0ff:fe06:7c91/64 scope link
valid_lft forever preferred_lft forever
5: enp1s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether a8:b8:e0:06:7c:92 brd ff:ff:ff:ff:ff:ff
6: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether a8:b8:e0:06:7c:93 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.16/24 scope global vmbr0
valid_lft forever preferred_lft forever
inet6 fe80::aab8:e0ff:fe06:7c93/64 scope link
valid_lft forever preferred_lft forever
7: tap101i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr101i0 state UNKNOWN group default qlen 1000
link/ether 02:e6:96:0d:02:6a brd ff:ff:ff:ff:ff:ff
8: fwbr101i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether be:7d:77:c3:ef:6a brd ff:ff:ff:ff:ff:ff
9: fwpr101p0@fwln101i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
link/ether 8a:11:73:68:b4:98 brd ff:ff:ff:ff:ff:ff
10: fwln101i0@fwpr101p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr101i0 state UP group default qlen 1000
link/ether be:7d:77:c3:ef:6a brd ff:ff:ff:ff:ff:ff
11: tap102i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr102i0 state UNKNOWN group default qlen 1000
link/ether 52:6a:89:78:48:97 brd ff:ff:ff:ff:ff:ff
12: fwbr102i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether b6:46:05:67:72:e8 brd ff:ff:ff:ff:ff:ff
13: fwpr102p0@fwln102i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
link/ether a6:29:0c:3d:5b:f9 brd ff:ff:ff:ff:ff:ff
14: fwln102i0@fwpr102p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr102i0 state UP group default qlen 1000
link/ether b6:46:05:67:72:e8 brd ff:ff:ff:ff:ff:ff
19: tap103i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr103i0 state UNKNOWN group default qlen 1000
link/ether 8e:c5:63:35:92:43 brd ff:ff:ff:ff:ff:ff
20: fwbr103i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 76:4c:8a:50:19:33 brd ff:ff:ff:ff:ff:ff
21: fwpr103p0@fwln103i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
link/ether 36:06:67:da:5f:e9 brd ff:ff:ff:ff:ff:ff
22: fwln103i0@fwpr103p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr103i0 state UP group default qlen 1000
link/ether 76:4c:8a:50:19:33 brd ff:ff:ff:ff:ff:ff
root@node1:~#

nano /etc/hosts

127.0.0.1 localhost.localdomain localhost
192.168.2.16 node1.local node1
192.168.2.17 node2.local node2

# The following lines are desirable for IPv6 capable hosts

::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

beisser · Dec 10, 2024

sieht auf den ersten blick gut aus.
es wurde weiter oben gefragt ob der server pingbar ist via vpn. geht das?
kannst du von den hosts aus den vpn-client pingen?

du könntest dir auch mal die frewall-regeln fürs vpn anschaun bzw auch mal grundsätzlich die firewall-regeln.
ebenso die logs der firewall. evtl trifft hier der traffic aus dem vpn auf eine regel, die den traffic zum pve host limitiert.
ist schwer zu troubleshooten mit der kristallkugel.

ich glaube falk liegt hier richtig und da klemmt irgendwas mit der firewall.
falls das regelwerk nicht super komplex ist, kannst ja mal ein paar screenshots zu den regeln posten. evtl werden wir daraus schlau.
auch interessant ist die vpn-konfig. speziell die netze.
du hast ja oben schon netze hingeschrieben, aber screenshots wäre trotzdem nicht schlecht

magicpeter · Dec 10, 2024

Ja, die Nodes sind beide anpingbar...

PING 192.168.2.16 (192.168.2.16): 56 data bytes
64 bytes from 192.168.2.16: icmp_seq=0 ttl=63 time=66.656 ms
64 bytes from 192.168.2.16: icmp_seq=1 ttl=63 time=20.463 ms
64 bytes from 192.168.2.16: icmp_seq=2 ttl=63 time=19.817 ms
64 bytes from 192.168.2.16: icmp_seq=3 ttl=63 time=19.437 ms
64 bytes from 192.168.2.16: icmp_seq=4 ttl=63 time=19.833 ms

--- 192.168.2.16 ping statistics ---
12 packets transmitted, 12 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 19.437/24.120/66.656/12.833 ms

Hier sind die Screenshots der Firewall

Hier sind ein paar Logs:

1 10.12.2024 17:08:45 ERROR Internet Unable to complete PPPoE Discovery
2 10.12.2024 17:08:45 OK Internet Timeout waiting for PADO packets
3 10.12.2024 17:08:24 OK Alarme IDPS: ET 3CORESec Poor Reputation IP group 6 [Classification: Misc Attack] [Severity: 2] [Signature Id: 2525005] [Action: blocked] [Source: 198.235.24.80:54993] [Destination: 192.168.178.100:22]

4 10.12.2024 17:08:24 OK Alarme IDPS: ET DROP Dshield Block Listed Source group 1 [Classification: Misc Attack] [Severity: 2] [Signature Id: 2402000] [Action: blocked] [Source: 198.235.24.80:54993] [Destination: 192.168.178.100:22]

5 10.12.2024 17:08:24 ERROR Server exception Traceback (most recent call last): File "/opt/gateprotect/lib/python/gppylib-0.0.0-py3.7.egg/gplib/messaging/client.py", line 653, in _handle_msgs self.handle_xml_message(XMLMessage(msg)) File "/opt/gateprotect/lib/python/gpSnmpd-0.0.0-py3.7.egg/gpSnmpd/messaging.py", line 16, in handle_xml_message super().handle_json_message(json_msg) File "/opt/gateprotect/lib/python/gppylib-0.0.0-py3.7.egg/gplib/messaging/client.py", line 223, in handle_json_message msg_addr, msg_method = msg.get_header("To").split("::", 2)[1:3] ValueError: not enough values to unpack (expected 2, got 1)

6 10.12.2024 17:08:24 ERROR Server exception Traceback (most recent call last): File "/opt/gateprotect/lib/python/gppylib-0.0.0-py3.7.egg/gplib/messaging/client.py", line 653, in _handle_msgs self.handle_xml_message(XMLMessage(msg)) File "/opt/gateprotect/lib/python/gpSnmpd-0.0.0-py3.7.egg/gpSnmpd/messaging.py", line 16, in handle_xml_message super().handle_json_message(json_msg) File "/opt/gateprotect/lib/python/gppylib-0.0.0-py3.7.egg/gplib/messaging/client.py", line 223, in handle_json_message msg_addr, msg_method = msg.get_header("To").split("::", 2)[1:3] ValueError: not enough values to unpack (expected 2, got 1)

7 10.12.2024 17:08:24 OK VPN MULTI_sva: pool returned IPv4=192.168.254.2, IPv6=(Not enabled)
8 10.12.2024 17:08:24 OK VPN 83.135.189.254:19257 [] Peer Connection Initiated with [AF_INET]83.135.189.254:19257 (via [AF_INET]192.168.178.100%eth0)

9 10.12.2024 17:08:24 OK VPN 83.135.189.254:19257 WARNING: 'cipher' is present in local config but missing in remote config, local='cipher AES-128-CBC'

10 10.12.2024 17:08:24 OK VPN 83.135.189.254:19257 peer info: IV_SSO=webauth,openurl,crtext
11 10.12.2024 17:08:24 OK VPN 83.135.189.254:19257 peer info: IV_GUI_VER=Viscosity_1.11.4_1702
12 10.12.2024 17:08:24 OK VPN 83.135.189.254:19257 peer info: IV_COMP_STUBv2=1
13 10.12.2024 17:08:24 OK VPN 83.135.189.254:19257 peer info: IV_COMP_STUB=1
14 10.12.2024 17:08:24 OK VPN 83.135.189.254:19257 peer info: IV_LZO=1
15 10.12.2024 17:08:24 OK VPN 83.135.189.254:19257 peer info: IV_LZ4v2=1
16 10.12.2024 17:08:24 OK VPN 83.135.189.254:19257 peer info: IV_LZ4=1
17 10.12.2024 17:08:24 OK VPN 83.135.189.254:19257 peer info: IV_PROTO=990
18 10.12.2024 17:08:24 OK VPN 83.135.189.254:19257 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305
19 10.12.2024 17:08:24 OK VPN 83.135.189.254:19257 peer info: IV_NCP=2
20 10.12.2024 17:08:24 OK VPN 83.135.189.254:19257 peer info: IV_MTU=1600
21 10.12.2024 17:08:24 OK VPN 83.135.189.254:19257 peer info: IV_TCPNL=1
22 10.12.2024 17:08:24 OK VPN 83.135.189.254:19257 peer info: IV_PLAT=mac
23 10.12.2024 17:08:24 OK VPN 83.135.189.254:19257 peer info: IV_VER=2.6.12
24 10.12.2024 17:08:05 ERROR Internet Unable to complete PPPoE Discovery
25 10.12.2024 17:08:05 OK Internet Timeout waiting for PADO packets
26 10.12.2024 17:07:54 OK Alarme IDPS: ET SCAN Suspicious inbound to PostgreSQL port 5432 [Classification: Potentially Bad Traffic] [Severity: 2] [Signature Id: 2010939] [Action: blocked] [Source: 194.48.251.232:46562] [Destination: 192.168.178.100:5432]
27 10.12.2024 17:07:33 OK Server FATAL: terminating connection due to administrator command
28 10.12.2024 17:07:25 ERROR Internet Unable to complete PPPoE Discovery
29 10.12.2024 17:07:25 OK Internet Timeout waiting for PADO packets
30 10.12.2024 17:06:50 OK Internet pppd 2.4.7 started by root, uid 0
31 10.12.2024 17:06:50 OK Internet Plugin rp-pppoe.so loaded.
32 10.12.2024 17:06:46 OK Internet Exit.
33 10.12.2024 17:06:46 ERROR Internet Unable to complete PPPoE Discovery

beisser · Dec 10, 2024

wenn die übers vpn anpingbar sind, aber andere ports nicht wollen, dann würde ich behaupten, das es tatsächlich was im regelwerk der firewall gibt, dass hier reinpfuscht.
ne andere erklärung gibt es eigentlich nicht mehr imho.

magicpeter · Dec 10, 2024

ich hatte auch schon mal alle Ports freigeben. Hat aber nichts geändert.

fba · Dec 10, 2024

Die PVE Nodes sind beide anpingbar, wenn Du Dich im Heimnetzwerk 192.168.111.0/24 befindest? Das würde gegen ein allgemeines Problem beim Routing sprechen.
Wenn nur SSH oder https auf Port 8006 nicht funktionieren, muss das ja irgendwo verhindert werden. Gibts daheim/in der Firma vielleicht noch eine Firewall?
Ein IP-Adresskonflikt wäre ansonsten noch auszuschließen, nicht das ein anderes Gerät auf die Pings antwortet.

Falk R. · Dec 10, 2024

Und unbedingt während eines Versuchs in das Firewall Live Log schauen. Manchmal greift auch eine Default Regel der FW Hersteller, weil Pakete anders sind als erwartet. Um dem auf die Schliche zu kommen hilft nur das Firewall Log.

magicpeter · Dec 12, 2024

Moin,
es wird immer komischer.
Heute habe ich mit einem Techniker von Lancom die Firewall überprüft und mit Wireshark die Verbindung überprüft.

Die Verbindung zur Proxmox GUI https://192.168.2.16:8006/ kommt zustande. Die Firewall blockiert nichts.

Screenshot Wireshark:

Netzwerke:

192.168.2.0/24 Büro-Netzwerk mit dem Proxmox Server
192.168.111.0/24 Mein Netzwerk im Homeoffice
192.168.254.0/24 VPN-Netzwerk

fba · Dec 12, 2024

Das ist doch schön, liegt wohl nicht an der Fw oder am Routing

Hast Du es schon mal mit einem anderen Browser probiert?

magicpeter · Dec 12, 2024

fba said:
Das ist doch schön, liegt wohl nicht an der Fw oder am Routing
Hast Du es schon mal mit einem anderen Browser probiert?

Ja, habe ich auch schon, Safari, Chrome, Firefox überall das gleiche Ergebnis.
Es wird nichts angezeigt.
Ich werde jetzt eine VerwaltungsVM installieren damit mich drauf verbinden kann und dann die andern VMS und Proxmox verwalten kann.
Mir fällt sonst nix mehr ein. Darauf kommt dann anydesk und gut ist.

6. vServer
Servername SERVERORG1
Serveralter 2024
Dienste anydesk
Domain
Server-OS Debian 12 mit Cinnamon
IP-Adresse 192.168.2.28
vResourcen 2 GB RAM, 1 vCPU, Disk 20 GB

Hat jemand noch eine andere Idee?

Proxmox VE GUI nicht über VPN-Tunnel erreichbar

Member

Member

Member

Member

Member

Distinguished Member

Member

Active Member

Member

Attachments

Active Member

Member

Attachments

Active Member

Member

Member

Distinguished Member

Member

Attachments

Member

Member