net.tcp auf port 8100 funktioniert nicht

F

fip

Member
Proxmox Subscriber
Dec 29, 2022
8
0
6
Um die Kundenapplikation laufen zu lassen brauche ich eine net.tcp-Verbindung auf port 8100 auf einen standalone server.
Das funktioniert weder von einem WIN10 noch von einem WIN11 client wenn diese Clients unter proxmox laufen.

WIN10 , WIN11 und WIN10 unter VMWare-ESXi laufen ohne Probleme. Ich kann aus den virtuellen WIN10 und WIN11 Clients unter proxmox sehen, dass sie via nmap zu 8100 verbinden bzw. unter powershell test-netconnection bekomme ich auch tcptestsucceedded:true.

15 WIN10-Clients unter VMWare ESXi laufen beim Kunden ohne Probleme. Jetzt will der Kunde ein Proof of concept für Proxmox. Alles läuft ohne Probleme, nur die Verbindung zum Mail-Service auf port 8100 verweigert den Dienst und somit ist die Applikation "unter Proxmox" nicht lauffähig. Das kann's ja nicht sein?

Wenn ich mit wireshark mitschaue ergibt sich die im png angehängte kommunikation (192.168.70.8 ist der Server), in der ersichtlich ist, dass die Verbindung ziemlich schnell auf ein RST läuft. Die Windows Friewall und der Virenscanner sind abgeschaltet.
Auf der Proxmox maschine ist die Firewall ebenfalls abgeschaltet:
root@pve:~# pve-firewall status
Status: disabled/stopped

Danke für eure Unterstützung.
lg
fip
 

Attachments

  • proxmoxwireshark.png
    proxmoxwireshark.png
    85.3 KB · Views: 11
Wie ist da der Flow? Der Server mit dem Mail Service auf Port 8100 ist der 192.168.70.8 und der externe Client ist 192.168.70.90 in dem TCP dump?

Wie ist der Mail Server konfiguriert? Denn wenn die VM direkt ein Bein im gleichen IP Subnet hat, z.b. mit der vmbr0 als Bridge (virtueller Switch), sollte da von Proxmox VE Seite nichts hineingrätschen.

Falls das Setup doch komplexer ist, zeig bitte mal die Config von der VM qm config {vmid} innerhalb von [code][/code] Blöcken (oder die Buttons im Editor). Und erklär wie das Netzwerk aufgebaut ist, bzw. zeige die Config am Host (/etc/network/interfaces) bzw. die SDN config, je nachdem.
 
aaron said:
Wie ist da der Flow? Der Server mit dem Mail Service auf Port 8100 ist der 192.168.70.8 und der externe Client ist 192.168.70.90 in dem TCP dump?

Wie ist der Mail Server konfiguriert? Denn wenn die VM direkt ein Bein im gleichen IP Subnet hat, z.b. mit der vmbr0 als Bridge (virtueller Switch), sollte da von Proxmox VE Seite nichts hineingrätschen.

Falls das Setup doch komplexer ist, zeig bitte mal die Config von der VM qm config {vmid} innerhalb von [code][/code] Blöcken (oder die Buttons im Editor). Und erklär wie das Netzwerk aufgebaut ist, bzw. zeige die Config am Host (/etc/network/interfaces) bzw. die SDN config, je nachdem.
Click to expand...
192.168.70.8 mit port 8100 ist der ansprechpunkt am Apllikationsserver über den dieser Server dann die Verbindung zu MS365 herstellt um Emails zu schicken bzw. zu empfangen. In dem Fall auf 192.168.70.90 läuft ein fetter Windows-Client der zur Darstellung und Abwicklung der Email-Services die Verbindung zum server braucht.
Das ist in dem Fall kein klassischser SMTP-Server. Der Softwarehersteller hat da mit dem Microsoft Framework einen Service gebaut, der die Funktionalität für die Clients zur Verfügung stellt.
Code: 
root@pve:~# qm config 104
agent: 1
balloon: 4096
boot: order=scsi0;ide0;ide2;net0
cores: 2
cpu: x86-64-v2-AES
ide0: local:iso/virtio-win-0.1.271.iso,media=cdrom,size=709474K
ide2: local:iso/Windows10GERx64.iso,media=cdrom,size=4809216K
machine: pc-i440fx-9.0
memory: 8192
meta: creation-qemu=9.0.2,ctime=1752492216
name: WIN10TEST
net0: virtio=BC:24:11:00:C8:04,bridge=vmbr0,firewall=1
numa: 0
ostype: win10
scsi0: local-lvm:vm-104-disk-0,size=100G,ssd=1
scsihw: virtio-scsi-pci
smbios1: uuid=a8fbac05-0004-4d9f-83b1-2797afa1a338
sockets: 2
vmgenid: ed156005-b211-4e55-8c98-f5f534463347
root@pve:~#

network config im png. einfachere network-config geht glaub ich nicht.

Danke für einen prompten und kompetenten Support.
lg
fip
 

Attachments

  • proxmoxnetwork.png
    proxmoxnetwork.png
    20.2 KB · Views: 5
Hmm, also das Setup sieht soweit so einfach wie möglich aus:
Code: 
Client → (Proxmox VE vmbr0) → Server

Da sollte von Proxmox VE Seite eigentlich nichts hineingrätschen, sondern die Pakete vom Client direkt an den Server gehen.

MTU usw. passen auch? Ansonsten ist die Frage, wieso da ein RST stattfindet. Gibts am Client oder Server detailierte Logs?

Evtl. haben andere auch noch eine Idee. Wenn es um obskure TCP resets geht, bin ich nicht ganz so erfahren.
 
aaron said:
Hmm, also das Setup sieht soweit so einfach wie möglich aus:
Code: 
Client → (Proxmox VE vmbr0) → Server

Da sollte von Proxmox VE Seite eigentlich nichts hineingrätschen, sondern die Pakete vom Client direkt an den Server gehen.

MTU usw. passen auch? Ansonsten ist die Frage, wieso da ein RST stattfindet. Gibts am Client oder Server detailierte Logs?

Evtl. haben andere auch noch eine Idee. Wenn es um obskure TCP resets geht, bin ich nicht ganz so erfahren.
Click to expand...
Ja, ich hab das testsetup bewusst so einfach wie möglich gestaltet. Leider gibt es von der Herstellerseite keine detailierten Logs dazu. Hab ich schon mehrfach hinterfragt. Deren Aussage, Standalone funktioniert alles, mit Vmware funktioniert alles und ihre Empfehlung ist ein nativer Windows Terminalserver ohne allem. Zu allem anderen haben sie eine Meinung, wie halt der klassische fat-client / server Denker und so sieht ihr support auch aus. Ich hab viele Stunden in dem Thema stecken und will das unbedingt mit Proxmox zum laufen bekommen. Nachdem ich jetzt alle Varianten durchprobiert habe und es wirklich so ist, dass das Thema nur auftritt wenn ich die Clients unter proxmox am laufen habe, bin ich allerdings komplett am Ende mit meinen Ideen wo ich da noch schrauben müßte/könnte/wollte.
 
Du könntest auch noch eine NIC direkt an die VM via PCI Passthrough durchreichen. Dann ist da von Proxmox VE Seite wirklich nichts mehr dazwischen und du hast, aus Netzwerksicht, eine bare-metal Kiste.

Evlt. wirst du im BIOS IOMMU aktivieren müssen. Dann sind hoffentlich mehrere Ports auf der gleichen Karte in eigenen IOMMU Groups. Alternativ kann man testweise eine weitere NIC stecken um sie an die VM durchzureichen.
 
aaron said:
Du könntest auch noch eine NIC direkt an die VM via PCI Passthrough durchreichen. Dann ist da von Proxmox VE Seite wirklich nichts mehr dazwischen und du hast, aus Netzwerksicht, eine bare-metal Kiste.

Evlt. wirst du im BIOS IOMMU aktivieren müssen. Dann sind hoffentlich mehrere Ports auf der gleichen Karte in eigenen IOMMU Groups. Alternativ kann man testweise eine weitere NIC stecken um sie an die VM durchzureichen.
Click to expand...
Könnte ich das nicht auch mit einer USB-NIC erreichen die ich der VM zuordne? Bzw. meinst, macht es Sinn das Thema auch auf den englischen Supportseiten zu psoten?
 
Ich hab jetzt noch recherchiert was Microsoft da wieder einmal für eigenes Süppchen kocht.
Microsoft Net.TCP ist ein Netzwerkprotokoll, das speziell für die Windows Communication Foundation (WCF) entwickelt wurde. Es ermöglicht eine leistungsstarke und effiziente Kommunikation zwischen Anwendungen, die auf dem .NET-Framework basieren. Hier sind einige wichtige Punkte:

  1. URI-Schema:
    • Net.TCP verwendet das URI-Schema net.tcp://, um Endpunkte zu identifizieren, die über TCP (Transmission Control Protocol) erreichbar sind

      .
  2. Port Sharing:
    • Das Net.TCP Port Sharing ermöglicht es mehreren Prozessen, denselben TCP-Port zu nutzen. Dies wird durch den Net.TCP Port Sharing Service realisiert, der eingehende Verbindungen akzeptiert und an die entsprechenden Prozesse weiterleitet

      .
  3. Leistung:
    • Net.TCP ist für hohe Leistung und geringe Latenz optimiert, was es ideal für Anwendungen macht, die schnelle und zuverlässige Kommunikation erfordern

      .
  4. Integration:
    • Es ist nahtlos in das .NET-Ökosystem integriert und wird durch eine Vielzahl von Tools und Bibliotheken unterstützt, was die Implementierung und Nutzung erleichtert

      .
Zusammengefasst bietet Net.TCP eine robuste Lösung für die Kommunikation zwischen .NET-Anwendungen, insbesondere in Szenarien, in denen Leistung und Zuverlässigkeit entscheidend sind.

Habt ihr mit diesem Framework Erfahrungen?
 
Ich sehe auch nichts was von Proxmox Seite reinspielen kann. Teste doch bitte mal mit einer USB Nic, die hat man ja oft für Notebooks rumliegen. Wenn es dann nicht geht, liegt es nicht am Netzwerk.

Falls das Problem dann immer noch besteht, bei der Win10 VM mal den CPU Typ ändern. Host wäre ganz praktisch, denn wenn das Protokoll so performant und neu ist, braucht es eventuell spezielle CPU Features, welche jetzt maskiert sind.
 
  • Like
Reactions: fip and aaron
Falk R. said:
Ich sehe auch nichts was von Proxmox Seite reinspielen kann. Teste doch bitte mal mit einer USB Nic, die hat man ja oft für Notebooks rumliegen. Wenn es dann nicht geht, liegt es nicht am Netzwerk.

Falls das Problem dann immer noch besteht, bei der Win10 VM mal den CPU Typ ändern. Host wäre ganz praktisch, denn wenn das Protokoll so performant und neu ist, braucht es eventuell spezielle CPU Features, welche jetzt maskiert sind.
Click to expand...
Danke für den Tip, werde ich mit USB-LAN Adapter ausprobieren und dann Feedback geben. Muss aber erst einen Termin mit dem Kunden vereinbaren.
 
fip said:
Danke für den Tip, werde ich mit USB-LAN Adapter ausprobieren und dann Feedback geben. Muss aber erst einen Termin mit dem Kunden vereinbaren.
Click to expand...
Den CPU-TYP mit host hab ich ausprobiert (ging remote) hat leider auch nichts gebracht. Ich hab auch schone alle NICs für die VM durchprobiert E1000, E1000E, virtio, reltek. Problem bleibt bei allen bestehen. USB-NIC , wie gesagt, muss ich erst Termin machen. lg fip
 
Ich hab jetzt einmal noch 3 wiresharkmitschnitte (2 über proxmox WIN10 und WIN11 - bei denen es nicht funktioniert und einen über VMWare - wo es funktioniert). Hat jemand eine Idee warum die selbe Serverkomponente und die selbe Client-Komponente unter vmware funktioniert und unter proxmox nicht? Danke
 

Attachments

  • proxmoxwin10failed.png
    proxmoxwin10failed.png
    449.6 KB · Views: 5
  • vmwareWIN10success.png
    vmwareWIN10success.png
    138.9 KB · Views: 5
  • proxmoxWIN11failed.png
    proxmoxWIN11failed.png
    85.3 KB · Views: 5
Das RST, ACK ist ja eigentlich eine saubere Connection Close Meldung. Irgendwer schließt den Stream.
Ich habe auch einen Kunden mit einer komischen Software, wenn ich die VM auf Proxmox starte, sind angeblich die Daten korrupt. Starte ich die VM danach mit der gleichen VMDK wieder auf einem ESXi, ist angeblich alles heile. Das ganze ist auf identischer Hardware und nicht nachvollziehbar, denn wenn ich ein md sum auf die Datei mache sind die Hashes identisch. Auch da tappen wir seit 2 Jahren im Dunkeln. Ich bin daher mal sehr gespannt ob es bei dir lösbar ist mit einer externen NIC.
 
hmm…

Probier mal bei der NIC der VM die "Firewall" Checkbox auszumachen. Vor allem, wenn die eh nie für die VM verwendet werden soll.
 
You must log in or register to reply here.
Top Bottom