Firewall-Konfiguration für UltraVNC SC?
Thomas Kowtsch
irgendwie stehe ich grade völlig auf dem Schlauch...
Um der lieben Familie möglichst einfachen Online-Support bieten zu
können wollte ich eigentlich UltarVNC SC nehmen - der Ratsuchende
startet das Tool (ohne Installation o.ä.), das Teil kontaktiert einen
Zielrechner und dort läuft dann ein VNCViewer.
Soweit, so gut - DynDNS tut was es soll, der UVNC-Paktet versucht
todesmutig die Verbindung aufzunehmen - nur der fli4l (v3.2.2)
widersteht ganz hartnäckig allen meinen Portforwarding-Versuchen...
Entweder klemmt hier was ganz gewaltig oder ich sehe wieder mal den
Wald vor lauter Bäumen nicht...
Da hätten wir zum einen eine ganz normale 08/15-Konfiguration mit
PF_NEW_CONFIG='yes':
Und erstmal geöffnetem Port 5900
<<schnipp>>
PF_INPUT_N='3'
PF_INPUT_1='IP_NET_1 ACCEPT' # allow all hosts in the local
# network access to the router
PF_INPUT_2='tmpl:vnc ACCEPT' # accept VNC access (Port 5900)
PF_INPUT_3='tmpl:samba DROP NOLOG' # drop (or reject)samba access
<<schnapp>>
Und dann noch das Forwarding:
PORTFW_N='1'
PORTFW_1_TARGET='5900'
PORTFW_1_NEW_TARGET='192.168.6.2:5900'
PORTFW_1_PROTOCOL='tcp'
Irgendwas habe ich mit Sicherheit übersehen bzw. vergessen - aber was?
Danke schonmal für alle Denkanstöße,
Thomas
--
Die Wunsch-Website einer Werbeagentur ist DAU-kompatibel, sonst nichts.
Webdesigner haben bekanntlich zur Sicherheit im Netz und zu korrektem HTML ein
Verhältnis wie Klaus Störtebeker zum Handelsrecht.
(http://www.heise.de/tp/deutsch/inhalt/te/13095/1.html)
Johannes Wolter
> Soweit, so gut - DynDNS tut was es soll, der UVNC-Paktet versucht
> todesmutig die Verbindung aufzunehmen - nur der fli4l (v3.2.2)
> widersteht ganz hartnäckig allen meinen Portforwarding-Versuchen...
>
> PF_NEW_CONFIG='yes':
>
> Und erstmal geöffnetem Port 5900
> <<schnipp>>
Der ist schonmal unnötig, fli4l öffnet alle nötigen Ports selbst und
dann auch an der richtigen Stelle (INPUT hat mit port forwarding nichts
zu tun).
> Und dann noch das Forwarding:
> PORTFW_N='1'
> PORTFW_1_TARGET='5900'
> PORTFW_1_NEW_TARGET='192.168.6.2:5900'
> PORTFW_1_PROTOCOL='tcp'
>
> Irgendwas habe ich mit Sicherheit übersehen bzw. vergessen - aber was?
Du verwendest welche Art Internetzugang? Irgendwas mit dynamischer IP
(dsl, isdn, dhcp_client)?
Du könntest das paketfilterlog anmachen und kucken, ob da wirklich was
ankommt und abgelehnt wird. Oder einfach mal im webinterface kucken, ob
die Forwardregel da ist und deren Counter auch hochgeht.
MfG,
J.
Mathias Wrede
* Thomas Kowtsch wrote:
> Und dann noch das Forwarding:
> PORTFW_N='1'
> PORTFW_1_TARGET='5900'
> PORTFW_1_NEW_TARGET='192.168.6.2:5900'
> PORTFW_1_PROTOCOL='tcp'
>
> Irgendwas habe ich mit Sicherheit übersehen bzw. vergessen - aber was?
du hast UltraVNC SC entsprechen der Dokumentation
<http://www.uvnc.com/addons/singleclick.html> konfiguriert?
Dann solltest du den Port 5500 Forwarden. Im Listen-Mode ist das der
Standard-Port.
HTH
Mathias
Jim Meba
Thomas Kowtsch schrieb:
> irgendwie stehe ich grade völlig auf dem Schlauch...
>
> Um der lieben Familie möglichst einfachen Online-Support bieten zu
> können wollte ich eigentlich UltarVNC SC nehmen - der Ratsuchende
> startet das Tool (ohne Installation o.ä.), das Teil kontaktiert einen
> Zielrechner und dort läuft dann ein VNCViewer.
Hab ich hier am Start.
> Soweit, so gut - DynDNS tut was es soll, der UVNC-Paktet versucht
> todesmutig die Verbindung aufzunehmen - nur der fli4l (v3.2.2)
> widersteht ganz hartnäckig allen meinen Portforwarding-Versuchen...
>
> Entweder klemmt hier was ganz gewaltig oder ich sehe wieder mal den
> Wald vor lauter Bäumen nicht...
>
> Da hätten wir zum einen eine ganz normale 08/15-Konfiguration mit
> PF_NEW_CONFIG='yes':
>
> Und erstmal geöffnetem Port 5900
> <<schnipp>>
> PF_INPUT_N='3'
> PF_INPUT_1='IP_NET_1 ACCEPT' # allow all hosts in the local
> # network access to the router
> PF_INPUT_2='tmpl:vnc ACCEPT' # accept VNC access (Port 5900)
Nicht nötig bei Verwendung von PORTFW_X, das wird damit automagisch
erzeugt.
> Und dann noch das Forwarding:
> PORTFW_N='1'
> PORTFW_1_TARGET='5900'
> PORTFW_1_NEW_TARGET='192.168.6.2:5900'
> PORTFW_1_PROTOCOL='tcp'
>
> Irgendwas habe ich mit Sicherheit übersehen bzw. vergessen - aber was?
Ist das ein "normaler" Fli4l mit DSL?
Bei fester IP muss diese ins _TAERGET mit rein.
Der Zierechner hat die IP 192.168.6.2 und der Vnc-Client "horcht" auf Port
5900? Weil das ist der default Port vom VNC-Server, wenn der installiert
ist.
-- Jim
Herbert Demmel
news:1t73p45ma7r7g3lhd...@4ax.com:
> Entweder klemmt hier was ganz gewaltig oder ich sehe wieder mal den
> Wald vor lauter Bäumen nicht...
> Vielleicht suchst Du das:
Für die gleiche Aufgabenstellung trage ich einfach das gewünschte
Portforwarding via Weboberfläche auch dem Fli4l ein (unter
Firewall/Portforwarding) - ohne Änderung in den Config-Dateien und nur
bei Bedarf
Herbert
Frank Hartwig
> Hallo Thomas,
>
> * Thomas Kowtsch wrote:
>> Und dann noch das Forwarding:
>> PORTFW_N='1'
>> PORTFW_1_TARGET='5900'
>> PORTFW_1_NEW_TARGET='192.168.6.2:5900'
Auch bei mir lauscht der VNC-Viewer auf Port 5500
>> PORTFW_1_PROTOCOL='tcp'
>>
>> Irgendwas habe ich mit Sicherheit übersehen bzw. vergessen - aber was?
> Dann solltest du den Port 5500 Forwarden. Im Listen-Mode ist das der
> Standard-Port.
Nur noch mal zur Verdeutlichung.
Gruß Frank
Thomas Kowtsch
>du hast UltraVNC SC entsprechen der Dokumentation
><http://www.uvnc.com/addons/singleclick.html> konfiguriert?
Ja. Auch wenn ich nicht mehr ganz sicher bin, welche von den mind.
leicht verschiedenen Dokus ich genommen habe. Einzige Abwandlung: Ich
habe in zu Anfang das ganze tatsächlich auf Port 5900 umgelegt.
>Dann solltest du den Port 5500 Forwarden. Im Listen-Mode ist das der
>Standard-Port.
Interessanter Tipp ;-)
Ich habe bislang nicht rausgefunden, was genau bei mir schief läuft,
aber ich habe mir ein Paket für den normalen Port 5500 gebaut. Wenn
ich jetzt nur den einen Port forwarde dauert die Verbindung ewig, aber
irgendwann scheint es zu klappen (falls die hilfesuchende Seite lange
genug dabei bleibt und nicht u.U. die zu testzwecken mißbrauchte
Handyverbindung wegbricht). Nehme ich zusätzlich Port 5900 dazu kommt
die Verbindung sofort zu Stande...?!?
Damit funktioniert zumindest der Teil erstmal; warum ich aber auf der
Helferseite kein Fenster bekomme (noch nichtmal eine Frage, ob ich die
Verbindung annehmen will) werde ich wohl in den nächsten Wochen
ergründen müssen.
Auf alle Fälle komme ich jetzt wenigstens so weit, das tun zu können
;-)
Danke nochmal!
Michael Schaffner
> Interessanter Tipp ;-)
> Ich habe bislang nicht rausgefunden, was genau bei mir schief läuft,
> aber ich habe mir ein Paket für den normalen Port 5500 gebaut. Wenn
> ich jetzt nur den einen Port forwarde dauert die Verbindung ewig, aber
> irgendwann scheint es zu klappen (falls die hilfesuchende Seite lange
> genug dabei bleibt und nicht u.U. die zu testzwecken mißbrauchte
> Handyverbindung wegbricht). Nehme ich zusätzlich Port 5900 dazu kommt
> die Verbindung sofort zu Stande...?!?
>
> Damit funktioniert zumindest der Teil erstmal; warum ich aber auf der
> Helferseite kein Fenster bekomme (noch nichtmal eine Frage, ob ich die
> Verbindung annehmen will) werde ich wohl in den nächsten Wochen
> ergründen müssen.
Da ich gerade heute auch darüber gefallen bin, stach mir dein Posting
ins Auge..
Falls du ein aktuelles Debian oder Ubuntu auf der "Helferseite" hast :
https://bugs.launchpad.net/ubuntu/+source/vnc4/+bug/123631
Ich habe zwar keinen entsprechenden Debian-Bug gefunden, das Verhalten
ist aber identisch.
Wenn du ne Lösung hast, sagt Bescheid !
Tschuess..
Michael
Thomas Kowtsch
>Falls du ein aktuelles Debian oder Ubuntu auf der "Helferseite" hast :
>https://bugs.launchpad.net/ubuntu/+source/vnc4/+bug/123631
Leider nein.
>Ich habe zwar keinen entsprechenden Debian-Bug gefunden, das Verhalten
>ist aber identisch.
Gut - da haben wir also mindestens 3 Betrübssysteme, die Ärger machen
und keinen der helfen kann...
>Wenn du ne Lösung hast, sagt Bescheid !
Einen Tipp habe ich gefunden, aber noch nicht probiert: Für
verschlüsselte Verbindungen muss das DSM-Plugin in der gleichen
Version auf Helfer- und Hilflos-Seite verwendet werden. Daher sollte
man die beim Helfer verwendete Version des Plugins unter dem Namen
MSRC4Plugin.dsm mit in das ZIP-File packen.
Ob's hilft - keine Ahnung, auch unverschlüsselte Verbindungen von
localhost oder anderen Rechnern im Netz funktionieren bei mir nicht.
Von Außen schon gleich gar nicht. Auch nicht mit einem alternativen
Client a la tightVNC oder so...
Es grüßt,
K. Martinen
> Gut - da haben wir also mindestens 3 Betrübssysteme, die Ärger machen
Sprich: Bei dir geht es darum Windozen zu fernwarten? :-)
Was wohl meistens der fall ist...
>> Wenn du ne Lösung hast, sagt Bescheid !
Vielleicht keine Lösung, aber ein Ansatz...
Mir scheint das procedere ist hier auch erwähnenswert. Ich mache das eigentlich
immer so.
1. Der Hilfesuchende ruft mich an. Ich sende ihm das Programm und/oder sage ihm
er soll warten bis ich soweit bin.
2. Ich richte entweder über imonc oder das webinterface (cgiconfig) die
Weiterleitung ein und kontrolliere ob der dyndns name angemeldet ist.
3. ich starte den Viewer im listenmode (der bohrt sich ein loch in der
Windowsfirewall)
(bei 2. und 3. ist die Reihenfolge egal)
4. Erst JETZT sage ich dem Anrufer das er das Programm starten soll.
Und dann klappt es normalerweise ohne Probleme. Wenn doch nicht - dann liegt es
m.e. meist daran das auf der Anruferseite etwas die Verbindung stört. Z.b. eine
Paranoide Firewall mit Selbstschutzwahn (z.b. Kaspersky ISS mit pro-aktivem
Schutz) oder andere Probleme die mit der LAN oder Inet-verbindung
zusammenhängen. Und dann ist Fernwartung meist eh ausgeschlossen. Es sei denn
man kann den DAU auf der anderen seite telefonisch durchsprechen seine
konfiguration zu checken und sachen zu deaktivieren die evtl. stören. Nach
meinen Erfahrungen kann das sehr stressig werden. Für beide seiten.
Extrem blöd ist - wenn man den Faden verliert weil man ungenaue angaben bekommt
oder der (Remote-)User schneller klickt als man sprechen kann darüber aber kein
wort verliert. Ergo: Nix für Schnelle Click-finger. ;-)
> Ob's hilft - keine Ahnung, auch unverschlüsselte Verbindungen von
> localhost oder anderen Rechnern im Netz funktionieren bei mir nicht.
> Von Außen schon gleich gar nicht. Auch nicht mit einem alternativen
> Client a la tightVNC oder so...
Hast du selbst auch Windoze und vielleicht vergessen dort in der/einer
(Personal)firewall ein loch zu bohren für den Listen-port des VNCViewers?
Der UltraVNC den ich kenne macht das bei der Fw von Windows selbst. Wenn dort
aber keine Ausnahmen zugelassen sind geht gar nichts. Und ob andere Pers.Fw. das
besser machen sei dahingestellt.
Das dazu von mir. Vielleicht hilfts.
Gruß
Kay