Fernwartung bei IPCop 1.3 funzt nicht....

#1 hallo zusammen,

habe mir vor einem weilchen die IPCop 1.3 aufgesetzt. das teil ist folgendermassen konfiguriert:

red --> DHCP (Internet)
orange --> 192.168.100.1 (DMZ)
green --> 192.168.0.1 (intern)

aus dem internen netz kann ich die administrationsseiten im browser problemlos öffnen. dazu nehme ich folgende URL:

https://192.168.0.1:445

unter IPCop 1.2 konnte ich mit der URL:

https://meineURL.com:445

ebenfalls auf die administration zugreifen. jetzt geht das aber nicht mehr.
über SSH kann ich aber problemlos zugreifen. dazu verwende ich den putty mit folgender URL:

meineURL.com:222

in der xtaccess-Datei habe ich folgende einträge:

tcp,[fixe.IP.meines.Arbeitgebers],222,0.0.0.0 --> für SSH (funzt)
tcp,[fixe.IP.meines.Arbeitgebers],445,0.0.0.0 --> für Web-Admin (funzt nicht)

kann mir jemand sagen woran das liegen kann? meiner ansicht nach sollte das so klappen. tat's früher wenigstens.

die verfügbaren hotfixes habe ich übrigens alle installiert.


bin für jede anregung dankbar.


Gruss
Philipp

#2 445 ist doch ssl - unterstüzt dein webserver überhaupt ssl? Scho mal in httpd.conf nachgeschaut? Kann dein IPcop kein SSH? das sollte auf jedenfall funktionieren.
__________
E-Mail: therion at ninth-art dot de
IRC: megatherion @ Freenode

#3 ich weis dass das ssl ist. normalerweise sollte ja auch die aufforderung zum aktzeptieren des zertifikates kommen... wie gesagt, wenn ich vom internen netz her komme, funktioniert das auch. nur wenn ich von extern, sprich von meinem büro aus, auf die firewall will, kommt immer die meldung "die seite kann nicht angezeigt werden blablablablablabla".

das ssh funzt wie schon oben gesagt wunderprächtig, und die httpd.conf hab ich gar nicht erst angerührt. .....

habs auch schon mal versucht, wenn ich anstelle des port 445 den eigentlichen https-port 81 als fernwartungszugangsport freigebe. --> fehlanzeige...

ist ja so gesehen auch nicht so tragisch, so nach dem motto: wenn ich auf meine eigene firewall nicht draufkomme, dann schaffts wohl auch kein anderer *grins*

aber lästig ist's halt doch

gruss philipp

#4 Ähhh ... mal ganz blöd gefragt:

Hast Du das Häkchen bei "Dienste / Fernwartung / aktivert" gesetzt?

Ist nur so eine Idee ...


Gruss

Aahz

#5 na ja, obwohl ich das häckchen gesetzt habe,... so dumm ist die frage gar nicht. ist ja sicher schon jedem mal passiert, dass er nach einem fehler gesucht hat, der eigentlich offensichtlich vor der nase liegt....

aber wie gesagt. die einträge sind aktiv. geht aber dennoch nicht...


gruss
philipp

#6 @philippCH

Vielleicht kümmerst du dich weniger um das Häkchen und dafür mehr um deine httpd.conf alles hat eine Ursache.
__________
E-Mail: therion at ninth-art dot de
IRC: megatherion @ Freenode

#7 also, an der httpd.conf hab ich nie was rumgeschraubt. kann mir also nicht vorstellen, dass das daran liegen soll. zumal ja das teil aus dem internen netz heraus funktioniert. und da greif ich ja auf die genau gleiche httpd.conf zu.

aber nichts desto trotz,.... hier mal die meiner meinung nach relevanten abschnitte aus der conf-datei:

****************************************
LoadModule ssl_module modules/libssl.so

<IfDefine SSL>
Listen 81
Listen 445
</IfDefine>


<IfDefine SSL>
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl
</IfDefine>

<IfModule mod_ssl.c>
SSLPassPhraseDialog builtin
SSLSessionCache dbm:/var/log/httpd/ssl_scache
SSLSessionCacheTimeout 300
SSLMutex file:/var/log/httpd/ssl_mutex
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
SSLLog /var/log/httpd/ssl_engine_log
SSLLogLevel info
</IfModule>

<IfDefine SSL>
<VirtualHost _default_:445>
DocumentRoot /home/httpd/html
ServerAdmin root@localhost
ErrorLog /var/log/httpd/error_log
TransferLog /var/log/httpd/access_log
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/httpd/server.crt
SSLCertificateKeyFile /etc/httpd/server.key
<Files ~ "\.(cgi|shtml?)$">
SSLOptions +StdEnvVars
</Files>
<Directory /home/httpd/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
CustomLog /var/log/httpd/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>

</IfDefine>
******************************************

wenn jemand hier einen fehler sieht,... ich bin dankbar für die hilfe....


gruss
philipp

#8 Nö sieht ganz in Ordnung aus. Dann muss es halt der Netfilter sein. Auf jedenfall wird deine Verbindung ja abgewiesen - also kann es nur noch der Netfilter sein dann musst du halt mal da nachhaken.
__________
E-Mail: therion at ninth-art dot de
IRC: megatherion @ Freenode

#9 Netfilter....? wo soll ich denn da noch suchen...? ich habe doch die verbindung im fernwartungszugang freigeschaltet, d.h. innerhalb des system einen eintrag in die xtaccess gemacht!

also müsste ja irgendwo eine regel sein, die diese entweder gar nicht erst greifen lässt, oder aber gleich wieder aushebelt. doch auch das ist für mich schwer zu glauben, da ja in der gleichen xtaccess der ssh-zugang definiert ist und der funktioniert ja....

nun ja, ich habe also keinen schimmer, wo ich noch was konfigurieren müsste. habe dieses problem ja auch zum erstem mal. alles was ich jetzt an der konfig verändern würde kann eigentlich nur falsch sein.


gruss philipp

#10 Nunja bunti-clicki hilft dir bei solch ein Problem nicht weiter - manchmal muss man halt doch etwas tiefer gehen als nur bis zum nächsten GUI - selbst bei IPcop. Wenn der SSH Zugang funktioniert (port tcp/22) und der SSL Zugang nicht und das nur von außen liegt es auf der Hand das es A) Der Apache ist (das hast du ja schon nachgeschaut - Listen 445 besagt das Apache alle IP's abhört sofern diese nicht definiert sind) B) Dein Netfilter Probleme bereitet. Deswegen könntest du dir mal die Regeln per 'iptables -L' ausgeben lassen oder wenn du die älteren ipchains nutzt dann über dem selbigen Programm - aber ipchains habe ich noch nie wirklich benutzt war mal irgendwo im 2.2 kernel angesagt (scho lange vorbei...) da müßtest du dann die manpage mal selber lesen.
__________
E-Mail: therion at ninth-art dot de
IRC: megatherion @ Freenode

#11 hab mir mal die iptables angeschaut.

innerhalb dieser habe ich folgenden eintrag entdeckt:

Chain XTACCESS (1 references)
target prot opt source destination
ACCEPT tcp -- XXX.XXX.XXX.X dclientXX-XXX-XXX-XXX.hispeed.chtcp dpt:222
ACCEPT tcp -- XXX.XXX.XXX.X dclientXX-XXX-XXX-XXX.hispeed.chtcp dpt:microsoft-ds

ich geh mal davon aus, dass dieser eintrag für die kontrolle des fernwartungszugang verantwortlich ist. und wenn ich diesen nicht komplett falsch interpretiere, sollte dieser den zugang zur fernwartung von aussen regeln.

nun ja, ich muss aber auch zugeben, das ich von den iptables und deren bedeutung etwa soviel verstehe, wie ein fisch vom fliegen. also gar nichts.
vielleicht kennt ja auch jemand von euch ein gutes (deutsches) howto. wenn ich mir das ganze nämlich so anschaue, geh ich mal davon aus, dass man damit ganz schön viel regeln, aber auch verbrechen kann. wenn man dann nur wüsste was man gerade macht.


gruss philipp

#12 @phillippCH

iptables ist ein high-level user tool zum verwalten des Netfilters (www.netfilter.org).

Die Funktion der iptables sind in der manpage erklärt.
Ein gutes Deutsches How-To kannst du unter http://www.pl-forum.de/t_netzwerk/iptables.html
finden. Diese Regeln in der Chain XTACCESS sind dafür verantwortlich welcher Port gefiltert wird und welcher nicht - wenn du dort eine Regel einfügst die alle Verbindungen von außen für Port 445 akzeptiert wird dein Problem evntl. Geschichte sein. Allerdings bin ich mir nicht sicher was genau XTACCESS macht und warum überhaupt IPcop eine extra chain hat was ja gar nicht nötig wäre. Man müßte die Policys kennen die besagen wie standardmäßig mit einem Paket verfahren wird. (ACCEPT|REJECT|DROP).

MFG

Xeper
__________
E-Mail: therion at ninth-art dot de
IRC: megatherion @ Freenode

#13 ups,... das ist ja wie ich gedacht habe ziemlich umfangreich. so einfach im vorbeigehen lerne ich das wohl nicht. werde mich mal übers wochenende damit beschäftigen. vielleicht finde ich ja was raus. bei dem "schönen" wetter das uns am wochenende erwartet, habe ich ja nicht viel besseres vor.

aber danke erstmal für die hilfe. werde mich allenfalls nächste woche wieder melden. und wenn nicht, dann habe ich entweder das problem lösen können oder habs aufgegeben...


gruss
philipp