Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 15 replies
  • Subscribers 38 subscribers
  • Views 5181 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Astaro 8.203 + SFirm

Revan
Hallo,

ich habe hier ein Problem mit der Kommunikation der sfirm-Software über den Socks-Proxy, vielleicht weiß ja jemand wie das zu beheben ist.
Die HBCI-Kommunikation läuft einwandfrei, nur Updates der Software lassen sich nicht herunterladen. Die Fehlermeldung lautet " Die Dateianfrage an den HTTP-Server ist fehlgeschlagen"

Beim Versuch eines Updates steht im Log des Socks-Proxy folgendes: 


2012:01:12-14:22:22 asg sockd[6306]: pass(1): tcp/accept [: 192.168.33.70.57545 -> 192.168.33.206.1080

2012:01:12-14:22:22 asg sockd[6307]: block(0): tcp/connect [: 192.168.33.70.57545 -> 81.169.174.93.80

2012:01:12-14:22:23 asg sockd[6306]: pass(1): tcp/accept [: 192.168.33.70.57546 -> 192.168.33.206.1080

2012:01:12-14:22:23 asg sockd[6307]: block(0): tcp/connect [: 192.168.33.70.57546 -> 81.169.174.93.80

2012:01:12-14:22:24 asg sockd[6306]: pass(1): tcp/accept [: 192.168.33.70.57547 -> 192.168.33.206.1080

2012:01:12-14:22:24 asg sockd[6307]: block(0): tcp/connect [: 192.168.33.70.57547 -> 81.169.174.93.80

2012:01:12-14:22:25 asg sockd[6306]: pass(1): tcp/accept [: 192.168.33.70.57548 -> 192.168.33.206.1080

2012:01:12-14:22:25 asg sockd[6307]: block(0): tcp/connect [: 192.168.33.70.57548 -> 81.169.174.93.80

2012:01:12-14:22:27 asg sockd[6306]: pass(1): tcp/accept [: 192.168.33.70.57549 -> 192.168.33.206.1080

2012:01:12-14:22:27 asg sockd[6307]: block(0): tcp/connect [: 192.168.33.70.57549 -> 81.169.174.93.80

2012:01:12-14:22:28 asg sockd[6306]: pass(1): tcp/accept [: 192.168.33.70.57551 -> 192.168.33.206.1080

2012:01:12-14:22:28 asg sockd[6307]: block(0): tcp/connect [: 192.168.33.70.57551 -> 81.169.174.93.80

2012:01:12-14:22:29 asg sockd[6306]: pass(1): tcp/accept [: 192.168.33.70.57553 -> 192.168.33.206.1080

2012:01:12-14:22:29 asg sockd[6307]: block(0): tcp/connect [: 192.168.33.70.57553 -> 81.169.174.93.80

2012:01:12-14:22:30 asg sockd[6306]: pass(1): tcp/accept [: 192.168.33.70.57554 -> 192.168.33.206.1080

2012:01:12-14:22:30 asg sockd[6307]: block(0): tcp/connect [: 192.168.33.70.57554 -> 81.169.174.93.80

2012:01:12-14:22:31 asg sockd[6306]: pass(1): tcp/accept [: 192.168.33.70.57555 -> 192.168.33.206.1080

2012:01:12-14:22:31 asg sockd[6307]: block(0): tcp/connect [: 192.168.33.70.57555 -> 81.169.174.93.80

2012:01:12-14:22:32 asg sockd[6306]: pass(1): tcp/accept [: 192.168.33.70.57556 -> 192.168.33.206.1080

2012:01:12-14:22:32 asg sockd[6307]: block(0): tcp/connect [: 192.168.33.70.57556 -> 81.169.174.93.80

2012:01:12-14:22:33 asg sockd[6306]: pass(1): tcp/accept [: 192.168.33.70.57558 -> 192.168.33.206.1080

2012:01:12-14:22:33 asg sockd[6307]: block(0): tcp/connect [: 192.168.33.70.57558 -> 81.169.174.93.80

2012:01:12-14:22:34 asg sockd[6306]: pass(1): tcp/accept [: 192.168.33.70.57559 -> 192.168.33.206.1080

2012:01:12-14:22:34 asg sockd[6307]: block(0): tcp/connect [: 192.168.33.70.57559 -> 81.169.174.93.80

2012:01:12-14:22:35 asg sockd[6306]: pass(1): tcp/accept [: 192.168.33.70.57560 -> 192.168.33.206.1080

2012:01:12-14:22:35 asg sockd[6307]: block(0): tcp/connect [: 192.168.33.70.57560 -> 81.169.174.93.80

2012:01:12-14:22:36 asg sockd[6306]: pass(1): tcp/accept [: 192.168.33.70.57561 -> 192.168.33.206.1080

2012:01:12-14:22:36 asg sockd[6307]: block(0): tcp/connect [: 192.168.33.70.57561 -> 81.169.174.93.80

2012:01:12-14:22:37 asg sockd[6306]: pass(1): tcp/accept [: 192.168.33.70.57562 -> 192.168.33.206.1080

2012:01:12-14:22:37 asg sockd[6307]: block(0): tcp/connect [: 192.168.33.70.57562 -> 81.169.174.93.80

2012:01:12-14:22:39 asg sockd[6306]: pass(1): tcp/accept [: 192.168.33.70.57563 -> 192.168.33.206.1080

2012:01:12-14:22:39 asg sockd[6307]: block(0): tcp/connect [: 192.168.33.70.57563 -> 81.169.174.93.80

2012:01:12-14:22:40 asg sockd[6306]: pass(1): tcp/accept [: 192.168.33.70.57565 -> 192.168.33.206.1080

2012:01:12-14:22:40 asg sockd[6307]: block(0): tcp/connect [: 192.168.33.70.57565 -> 81.169.174.93.80

2012:01:12-14:22:41 asg sockd[6306]: pass(1): tcp/accept [: 192.168.33.70.57566 -> 192.168.33.206.1080

2012:01:12-14:22:41 asg sockd[6307]: block(0): tcp/connect [: 192.168.33.70.57566 -> 81.169.174.93.80

2012:01:12-14:22:42 asg sockd[6306]: pass(1): tcp/accept [: 192.168.33.70.57567 -> 192.168.33.206.1080

2012:01:12-14:22:42 asg sockd[6307]: block(0): tcp/connect [: 192.168.33.70.57567 -> 81.169.174.93.80

2012:01:12-14:22:43 asg sockd[6306]: pass(1): tcp/accept [: 192.168.33.70.57568 -> 192.168.33.206.1080

2012:01:12-14:22:43 asg sockd[6307]: block(0): tcp/connect [: 192.168.33.70.57568 -> 81.169.174.93.80 


In den Socks-Optionen der Astaro stehen die betreffenden Rechner unter zugelassene Netzwerke und ein extra erstellter User für die Benutzerauthentifizierung.

In der sfirm-Software ist die IP der Astaro als Adresse für den Socks-Proxy hinterlegt, sowie Port 1080 und die Credentials.


This thread was automatically locked due to age.
  • 0 in reply to Revan
    Die URLs die angesteuert werden sind:
    sfirm.de
    download.sfirm.de

    Es läuft jetzt mit dem HTTP-Proxy und einer Ausnahme für die o.g. URLs bei der Authentication / Extension blocking / URL Filter übersprungen wird.

    Ohne dies drei Ausnahmen geht es nicht. So geht es erstmal, schön ist es aber nicht. Die Frage warum es mit dem Socks beim Banking funktioniert, beim Update aber nicht interessiert mich immer noch. Irgendwie muss man das doch herausfinden können.
  • 0
    Heute morgen gab es beim Banking Probleme, diese Fehlermeldung wurde angezeigt:
    Hinweis:
    Der Verbindungsaufbau über den eingestellten HTTP-Proxy ist fehlgeschlagen (Fehlermeldung s. unten).
    Eine direkte Kommunikation mit dem Zielserver konnte jedoch erfolgreich durchgeführt werden.

    (Fehler -5000014) Die Proxy-Authentisierung ist fehlerhaft.
    Fehler bei der Proxy-Authentisierung. Der hinterlegte Benutzername und/oder das Passwort ist nicht
    korrekt.


    Das steht im Log:

    2012:01:23-08:51:37 asg httpproxy[5407]: id="0003" severity="info" sys="SecureWeb" sub="http" request="0xa67d5c0" function="auth_adir_auth_crap_callback" file="auth_adir.c" line="888" message="Authorization denied (NT_STATUS_NO_SUCH_USER)"
    2012:01:23-08:51:37 asg httpproxy[5407]: id="0002" severity="info" sys="SecureWeb" sub="http" name="web request blocked" action="block" method="CONNECT" srcip="192.168.33.70" dstip="" user="sfirm" statuscode="407" cached="0" profile="REF_WBhBjpoheK (Standard_Profil)" filteraction=" ()" size="4803" request="0xa67d5c0" url="https://services.starfinanz.de/" exceptions="" error=""


    Ich habe mir geholfen indem ich eine Firewall-Regel erstellt habe mit den Ports für HBCI und als Ziel "Any" eingetragen habe. Das ganze wird aber immer mehr zur Bastellösung.

    Nachdem ich die URL "services.starfinanz.de/" iin die Ausnahme eingetragen und die Firewall-Regel deaktiviert habe bekomme ich nun folgende Meldung im Log:

    2012:01:23-09:27:39 asg httpproxy[5407]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="GET" srcip="192.168.33.70" dstip="81.169.174.93" user="" statuscode="200" cached="0" profile="REF_WBhBjpoheK (Standard_Profil)" filteraction="REF_DefaultHTTPCFFBlockAction (Default content filter block action)" size="3" request="0xa6faa40" url="http://download.sfirm.de/downloads/SF32/patch/onlinecheck" exceptions="auth,url,fileextension" error="" content-type="application/octet-stream"
    2012:01:23-09:27:39 asg httpproxy[5407]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="GET" srcip="192.168.33.70" dstip="81.169.174.93" user="" statuscode="200" cached="0" profile="REF_WBhBjpoheK (Standard_Profil)" filteraction="REF_DefaultHTTPCFFBlockAction (Default content filter block action)" size="1557" request="0xa6faa40" url="http://download.sfirm.de/downloads/SF32/patch/v2autoupdateinfo" exceptions="auth,url,fileextension" error="" content-type="application/octet-stream"
    2012:01:23-09:27:39 asg httpproxy[5407]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="GET" srcip="192.168.33.70" dstip="81.169.174.93" user="" statuscode="200" cached="0" profile="REF_WBhBjpoheK (Standard_Profil)" filteraction="REF_DefaultHTTPCFFBlockAction (Default content filter block action)" size="120" request="0xa6faa40" url="http://download.sfirm.de/downloads/SF32/patch/v2abo/v2autoupdateinfo" exceptions="auth,url,fileextension" error="" content-type="application/octet-stream"
    2012:01:23-09:27:39 asg httpproxy[5407]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="GET" srcip="192.168.33.70" dstip="81.169.174.93" user="" statuscode="200" cached="0" profile="REF_WBhBjpoheK (Standard_Profil)" filteraction="REF_DefaultHTTPCFFBlockAction (Default content filter block action)" size="26647" request="0xa6faa40" url="http://download.sfirm.de/downloads/SF32/patch/v2autoupdateinfo39" exceptions="auth,url,fileextension" error="" content-type="application/octet-stream"
    2012:01:23-09:27:40 asg httpproxy[5407]: id="0001" severity="info" sys="SecureWeb" sub="http" name="http access" action="pass" method="GET" srcip="192.168.33.70" dstip="81.169.174.93" user="" statuscode="200" cached="0" profile="REF_WBhBjpoheK (Standard_Profil)" filteraction="REF_DefaultHTTPCFFBlockAction (Default content filter block action)" size="1862" request="0xa6faa40" url="http://download.sfirm.de/downloads/SF32/patch/v2abo/autoupdateinfo10" exceptions="auth,url,fileextension" error="" content-type="application/octet-stream"


    Der Zugriff aufs online-Banking ist ohne die Firewall-Regel wieder gesperrt.
  • 0
    Laut dem Logfile heisst es doch das die Filteraction die ich für die betreffende Nutzergruppe erstellt habe nicht greift und daher die "default content filter action" einspringt die ich als Ersatz-Aktion definiert habe und die alles blockt.

    Wenn ich doch eine Ausnahme definiere in der ich für alle Anfragen, die obengenannte URLs betreffen, die Authentication, Extension Blocking und URL Filterung überspringe, wozu brauche ich dann noch eine Firewall-Regel für HBCI?

    Ich versteh es nicht.
  • 0 in reply to Revan
    Laut dem Logfile heisst es doch das die Filteraction die ich für die betreffende Nutzergruppe erstellt habe nicht greift und daher die "default content filter action" einspringt die ich als Ersatz-Aktion definiert habe und die alles blockt.

    Es greift die "Default content filter block action", da alle andere Bedingungen nicht erfüllt werden.


    Wenn ich doch eine Ausnahme definiere in der ich für alle Anfragen, die obengenannte URLs betreffen, die Authentication, Extension Blocking und URL Filterung überspringe, wozu brauche ich dann noch eine Firewall-Regel für HBCI?

    Der Web Proxy regelt alle Anfragen auf Port 80 (u. ggf. 443). Deine Exceptions die du baust betreffen also nur http (u. ggf. https) Anfragen.
    HBCI hat dann nichts mit dem Web-Proxy zu tun, da HBCI meines Wissens nach auf Port 3000 kommuniziert, deswegen musst du dann noch Packet Filter Rules erstellen, wenn du Port 3000 zulassen willst.
  • 0
    Entschuldigung, es heisst natürlich default content filter block action, war ein Verschreiber.
    Aha, also nur Port 80 und ggf. 443. D.h. es greifen keine andere Bedingungen weil die Anfragen für HBCI über Port 3000 laufen und daher die Ersatz-Aktion einspringt?

    Gut, dann habe ich also die Ausnahmen für die Updates und die Firewall-Regel für HBCI.

    Jetzt wäre es nur schön herauszufinden warum die Updates die über Port 80 und 443 laufen nicht per Socks-Proxy funktionieren, das Banking per HBCI und Port 3000 aber doch.
Unfiltered HTML