Remote Access ssl und RemoteDesktop

Hi jklein,

hast du Paketfilter-Regeln für die einzelnen Services erstellt?

Falls nicht musst du das natürlich noch tun und z.b. dem VPN-Pool den zugriff via RDP auf das interne Netz oder die jeweiligen Hosts erlauben.

Ebenso für andere Protokolle.

Gruß Chris

Ich habe unter netrwork security Packet Filter
folgende Rule erstellt

Source: VPN Pool ssl
Service: Microsoft Remote
Destination: Internal Network

der Fehler müsste woanders liegen

Grüße
Joachim

Es gibt sehr viele Fehlerquellen ...
Was steht denn im packetfilter.log zB?

Ist das setzen der "Automatic packet filter rules" unter Remoteaccess:SSL:Advanced keine Option für Dich?

Die Automatic packet filer rules habe ich gesetzt es ändert sich nichts
Wie ist das mit der compression kann die Probleme machen
Wie gesagt das Gerät ist neu für mich im Log steht Tonnen an Packet dropped wie

2008:11:25-19:52:34 (none) ulogd[2641]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" dstmac="00:xx:xx:xx:x8c:21" srcmac="xx:xx:xx:xx:xx:00" srcip="xx.xx.***.***" dstip="***.***.***.x" proto="17" length="63" tos="0x00" prec="0x00" ttl="117" srcport="4672" dstport="62990" 

Leider steht in der kb die FWRULE 60001 nicht drin, 
erst hab ich gedacht das wg Dyn IP Probleme entstehen allerdings wenn die einwahl klappt müsste dieser Bereich Richtig sein.

Trotzdem Danke

Die 60001 ist die letzte Regeln und Standardmäßig DROP. Also hat vorher keine gepasst.

Suche dochmal nach den Einträgen für eine der VPN-Adressen.
Nach dem Muster
[FONT="Courier New"]srcip=vpn.ip.des.clients dstip=ip.des.ser.ver[/FONT]
oder umgekehrt.

die pfr braucht's nicht wenn "Automatic Packet Filter Rule" aktiv ist - was einfacher ist;
was nach der o.g. darstellung fehlt ist das masquerading VPN-Pool (SSL) nach Internal

gruss andre

Genau das war es auch, mir ist zwar nicht ganz klar was ich da geoffnet habe (masquerading VPN-Pool ), hab ja im Februrar die Schulung
Danke danke
Grüße Joachim

schoen wenn's jetzt klappt..
es wurde weniger was "geoeffnet", als was "versteckt" - analog zum NAT richtung public muss auch der vpn pool gegen alle netze, die er erreichen will, ge-NAT-tet werden;
nur: frag mich nicht, warum - das sollte eigentlich so mittels harmlosen routing funktionieren, wie bei allen anderen ans system angeschlossenen netzen.
und rechne damit, das der trainer im februar auch bestreitet, das man das braucht - meine haben es bisher alle getan! und auch hier im forum meinen viele, das kann nicht sein - ich wuerde mich denen gern anschliessen, wenn nicht die realitaet etwas anderes zeigen wuerde...
gruss

schoen wenn's jetzt klappt..
es wurde weniger was "geoeffnet", als was "versteckt" - analog zum NAT richtung public muss auch der vpn pool gegen alle netze, die er erreichen will, ge-NAT-tet werden;
nur: frag mich nicht, warum - das sollte eigentlich so mittels harmlosen routing funktionieren, wie bei allen anderen ans system angeschlossenen netzen.
und rechne damit, das der trainer im februar auch bestreitet, das man das braucht - meine haben es bisher alle getan! und auch hier im forum meinen viele, das kann nicht sein - ich wuerde mich denen gern anschliessen, wenn nicht die realitaet etwas anderes zeigen wuerde...
gruss

Vielen Dank für die Info
ich kann ja bei der Schulung den Trainer auf unser Test ASG lassen und aufzeigen das es ohne nicht geht...[:)]
gruss
Joachim

schoen wenn's jetzt klappt..
es wurde weniger was "geoeffnet", als was "versteckt" - analog zum NAT richtung public muss auch der vpn pool gegen alle netze, die er erreichen will, ge-NAT-tet werden;
nur: frag mich nicht, warum - das sollte eigentlich so mittels harmlosen routing funktionieren, wie bei allen anderen ans system angeschlossenen netzen.
und rechne damit, das der trainer im februar auch bestreitet, das man das braucht - meine haben es bisher alle getan! und auch hier im forum meinen viele, das kann nicht sein - ich wuerde mich denen gern anschliessen, wenn nicht die realitaet etwas anderes zeigen wuerde...
gruss

NAT? Warum sollte NAT stattfinden? Die Regeln "Automatic Packet Filter Rule" setzen auch kein NAT (siehe iptables -n -v -L) und sind notwendig, damit die Astaro die angeschlossenen Netze zulässt, sofern man keine Regeln dafür manuell erstellen muss / will.
Hier vermute ich weniger ein Astaro-NAT-Problem, sondern ein Netzwerkkonfigurationsproblem. Fehlerhafte Subnetzklassifizierung, falsche Routingeinträge und fehlender Standardgateway auf den Zielsystemen sind sehr beliebte Spasskiller.

dann haben hier viele leute Netzwerkkonfigurationsprobleme... was ein wort! :-)
nein, im ernst: wie beschrieben - es macht keinen sinn, aber es funktioniert.

und wie gerade in einem der en-forem beschrieben hat es sich offenbar seit 7.305 geaendert, da laeufts dann auch ohne NAT, wie es sein sollte!! hab ich aber selber noch nicht probiert..

gruss

Ich habe bisher bei keiner einzigen ASG beim SSLVPN NAT nutzen müssen. Nur bei einer einzigen musste ich die Autorules weglassen, da nicht alle Clients komplett ins Netz sollten. Von daher wäre mein erster Klick "open support case" [;)]

vergibst du moeglicherweise adressen aus dem zielbereich? dann braucht man das nicht; sonst habe ich keine anderen erfahrungen gemacht
und warum einen case, wenn ich das mit wenigen mausklicks loesen kann - das MASQ hat nirgendwo site effects und ist damit m.e. die sinnvollere variante
a.

Die Adresse kommen aus dem SSLVPN Pool der Astaro. Und für mich wäre das ein Case, da es jeglichem Verständnis entbehrt, warum an dieser Stelle NAT zum Einsatz kommen muss.

Bei Handhelds mit Active Sync kann ich es noch nachvollziehen, da die Mistviecher mit der internen IP-Adresse auf die externe des Exchange zugreifen und der Exchange an die interne antwortet ... aber sonst?