ChunkVNC / UltraVNC duch pfsense



  • Moin zusammen,

    ich versuche gerade folgendes:

    Wir haben externen Support für spezielle Software auf einigen Servern.
    Die Dienstleister müssen da gelegentlich mal schauen - nun möchten wir weder RDP nach außen frei geben, noch permanente Tunnel in unsere Netze.

    Die Lösung bisher ChunkVNC.

    Nach einem Umbau ist jetzt auch der Repeater (also der Meeting-Point für Clients und Server) in ein Netz hinter der PF gewandert und wird mittel Portforeward auf eine öffentl. IP gemappt.

    WAN / Internet
                :+ –---------- Externer mit Laptop (Viewer)
                : Provider
                :
          .-----+-----.
          |  Gateway  |  Router
          '-----+-----'
                |
            WAN | + NAT(Repeater)
                |
          .-----+-----.  Servernetz  .------------.
          |  pfSense  +---------------Repeater
          '-----+-----' 10.10.10.x    '------------'
                |
            VMs | 10.0.0.1/24 Server (Support?)

    Bisher (mit externem Repeater) funktioniert das ganze wie folgt:

    Man öffnet auf der betroffenen VM das Support-Tool - dieses meldet sich beim Repeater.
    Der Externe öffnet seinen Viewer und kann sich über einen Sessioncode mit dem Repeater verbinden.
    Der Repeater leitet den Traffic zum jeweils anderen weiter.

    Mein Problem: Das Support-Tool erreicht scheinbar den Repeater auf der Öffentlichen IP nicht, obwohl die PF Packete dahin durch lässt :  10.0.0.10:54692 x.x.x.40:5500 TCP:SEC mit grünem Harken.

    Auch Telnet auf dem Port ging vom entsprechenden Server zum Nat-Repeater nicht durch.
    Direkt die interne Repeater-IP angesprochen funktioniert jedoch per Telnet - so hat der Repeater allerdings keine Funktion ;(

    Gegenprobe : mein Laptop von außen kann beide Tools (Viewer und Support) öffnen und es funktioniert.
    Auch mit 2en getestet - ist nur unpraktisch.
    Habe jetzt aus purer Verzweiflung die Server-Regel um Options und Flags erweiter - leider ohne Erfolg;(

    Arbeitet hier auch jemand mit UltraVNC und kennt ähnliche Probleme?

    Gruß
    TX



  • Hallo,

    UltraVNC verwende ich auch hier. Das benötigt nicht mehr als ein simples Port-Forwarding. Aber das dürfte ja nicht dein Problem sein.
    Das Problem scheint eher die Verbindung zwischen VM und Repeater zu sein.

    Du hast in dem Schema 2x Repeater angeführt. Wieviele gibt es denn da tatsächlich?
    Macht der Router vor der pfSense auch NAT?

    @trixters:

    Mein Problem: Das Support-Tool erreicht scheinbar den Repeater auf der Öffentlichen IP nicht, obwohl die PF Packete dahin durch lässt :  10.0.0.10:54692 x.x.x.40:5500 TCP:SEC mit grünem Harken.
    Auch Telnet auf dem Port ging vom entsprechenden Server zum Repeater einwandfrei durch.

    Von eine TCP "SEC"-Flag habe ich noch nie gehört.  ???

    Muss das Support-Tool den Repeater über die öffentliche IP erreichen? Das kann bei Double-NAT kompliziert werden.


  • Moderator

    @virago: das müsste eigentlich S,E,C sein, wenn ichs richtig weiß. Das sind die TCP Flags, gesetzt müssten also SYN, ECE und CWR sein. Wenn dem so ist, hat wohl der sendende Host die Verbindungsrate gedrosselt weil er das so kommuniziert bekommen hatte.


    CWR (1 bit): Congestion Window Reduced (CWR) flag is set by the sending host to indicate that it received a TCP segment with the ECE flag set and had responded in congestion control mechanism (added to header by RFC 3168).
    ECE (1 bit): ECN-Echo has a dual role, depending on the value of the SYN flag. It indicates:

    • If the SYN flag is set (1), that the TCP peer is ECN capable.
    • If the SYN flag is clear (0), that a packet with Congestion Experienced flag set (ECN=11) in IP header was received during normal transmission (added to header by RFC 3168). This serves as an indication of network congestion (or impending congestion) to the TCP sender.
      --

    sollte aber erstmal kein imminentes Problem sein.



  • @JeGr
    Klingt plausibel. Danke.
    Zufall, dass dies gerade bei dieser Verbindung aufgetreten ist oder gibt es da generell eine hohe Netzlast?

    @trixters
    Über den Port 5500 wird der Repeater standardmäßig vom Support-Tool angesprochen? Und die IP davor ist die externe?



  • Also der Aufbau ist wie oben beschrieben:

    Der Repeater sitzt intern und wird per NAT von außen über eine öffentliche CARP-Adresse der PF erreichbar.

    Ich habe das Problem jetzt umgangen : Das Support-Tool nutzt die interne IP, der externe Viewer die öffentliche.

    Denn irgendwie scheint es nicht zu klappen, wenn beide die öffentliche Adresse ansteuern - dann kommt das interne Support-Tool nicht zum Repeater durch ;(

    Damit das ganze Idiotensicher wird, habe ich das ganze in eine ChunkVNC-Lösung gepackt - damit keiner nach irgendwelchen Parametern fragen muss.
    Die Ports des Repeaters sind die Standard-Ports, also 5500 / 5901.

    Wenn man in die Logs der betroffenen Interfaces schaut werden die Packete auch durch gelassen - aber das war es dann auch schon - ich denke das die PF das NAT zum Repeater von intern nicht korrekt hin bekommt.

    Momentan ist das leider nur eine Nebenbaustelle - einfach viel zu tun, daher bin ich nur sporradisch hier.

    Regards



  • Hast es schon mit NAT Reflection versucht? Das ist eben dafür da, um von intern mit der externen IP auf interne Hosts zuzugreifen, für die es eine NAT-Regel extern > intern gibt.
    Wenn du Double-NAT hast, kannst du das aber auch vergessen. Dazu gab es leider bislang keine Antwort.