bei uns blockt die Firewall des TI-Connector seit heute Anfragen der Clients. Wenn z.B. Karten ausgelesen werden sollen, kommt die Meldung, TI-Connector sei nicht erreichbar. Ping auf den Connector funktioniert aber einwandfrei.
Im Sicherheitslog der Kocobox:
BlockedPacket=Von xxx.xxx.xxx.xxx(IP des Clients):51849 nach yyy.yyy.yyy.yyy(IP Kocobox):8080 mit Protokoll TCP über Adapter lan.; Aktion=Drop
Was kann ich tun, damit die Firewall diese Anfragen wieder erlaubt? Die Kocobox wird im IA-Modus betrieben.
Diese Anfrage wird von den Clientsystemen aber so an die Kocobox gesendet und hat bis gestern auch funktioniert. Die TI-Komponenten stehen in einem eigenen Subnetz (VLAN2). Die Clients stehen in VLAN 1.
Wenn ich mir das Firewall-Log zwischen den Netzen ansehe, geht die Anfrage vom Client (VLAN 1) zur Kocobox (VLAN 2) über Port 80 raus. Trotzdem kommt die Meldung über Port 8080 in der FW der Kocobox.
Die Intranetroute ist korrekt gesetzt. (VLAN 1)/24 -> GW von VLAN2
Im Firewall-Log kommt also Anfrage auf dem Interface VLAN1 für Port 80 rein und geht auch auf Interface VLAN2 für Port 80 raus? Und es gibt nichts zusätzliches auf Port 8080 (sprich: was wird geloggt)?
Das Firewalllog unserer OPNsense: Clientsystem (in VLAN1) xxx.xxx.xxx.xxx:524xx -> Connector(in VLAN2) yyy.yyy.yyy.yyy:80 leitet die Anfrage in das VLAN 2 korrekt.
Das Firewalllog in der Kocobox meldet diese Anfrage: von xxx.xxx.xxx.xxx:524xx zum Port 8080 des Connectors yyy.yyy.yyy.yyy:8080 wird geblockt.
Ein Portmapping findet auf der OPNSense-Firewall (dies ist die zentrale Firewall, die den Traffic zwischen den VLANs regelt) nicht statt.
Die Umstellung auf Redirect unter LAN/WAN hat leider auch nichts gebracht. Entsprechende Routing-Regeln existieren. Ich habe bei einer anderen,vergleichbaren Konstellation mit der Block-Einstellung keine Probleme. Dort sind auch diverse VLANs im Einsatz.
Kann man die Kocobox sichern, um dann ein Werksreset durchzuführen und die Sicherung im Anschluß wieder einspielen ?
Zitat von MiRei im Beitrag #7Kann man die Kocobox sichern, um dann ein Werksreset durchzuführen und die Sicherung im Anschluß wieder einspielen ?
Sicherung geht hier:
SMCB muss zugeordnet werden, dann Freigabe mit SMC-B Pin über Kartenterminal und dann kriegt man noch einen importschlüssel den man neben der Konfidatei aufbewahren muss u bei import mit eingeben muss .
Soweit weiß ich und hab es schon probiert u mit CGM, als die damals noch ans Telefon gingen;-) abgeglichen, ob dann Rücksicherung der Konfi nach Werksreset aber auch wirklich praktisch klappt habe ich allerdings selbst auch noch keine Erfahrungen
Zitat von MiRei im Beitrag #5Das Firewalllog unserer OPNsense: Clientsystem (in VLAN1) xxx.xxx.xxx.xxx:524xx -> Connector(in VLAN2) yyy.yyy.yyy.yyy:80 leitet die Anfrage in das VLAN 2 korrekt.
Steht da kein Interface im Log? Dass das so reinkommt, sollte klar seindamit. Wenn das so auch für das ausgehende Interface (also das mit VLAN2) gilt, kommt das dann auch so auf der KocoBox an (sprich kein gemappe). Das würde ich mich mal vergewissen wollen. Bei Opensense sollte es doch tcpdump geben. Dump machen, angucken, was auf dem Interface von VLAN2 rausgeht, dass man mal sicher weiß, was auf's Kabel kommt - das wäre meine Vorgehensweise, um den Fehlerort einzugrenzen.
"BlockedPacked" kann auch passieren, wenn die Authentifizierung am Konnektor durch den PC nicht (mehr) richtig funktioniert.
* Ist TLS aktiviert? / Authentifizierung verpflichtend / Authenrisierungsmodus? * Wurde in letzter Zeit etwas in den Konnektor-Einstellungen geändert? * Wird ein Zertifikat benötigt um sich am Konnektor anzumelden und ist dort das PW richtig? * Ist im PVS irgendwas mit "Verschlüsselung" oder "TLS" aktiviert?
Der Reset und die Wiederherstellung hat funktioniert. Das eigentliche Probleme wurde dadurch aber nicht abgestellt.
Ich habe jetzt TLS deaktiviert. Nun funktioniert der Zugriff wieder auf die Kocobox aus der Applikation. Warum es vorher funktioniert hat, ist mir eigentlich nicht wirklich klar, denn an der Applikation und an der Kocobox ist nichts verändert worden. Die Applikation war so eingerichtet dass keine Verschlüsselung zum Konnektor verwendet wurde, dort war TLS aber aktiviert.
Da werde ich noch einmal am Wochenende genauer recherchieren.
In dem Moment, wo TLS in der Koco-Box aktiviert wird, erwartet der Konnektor bei jeder Verbindung die Authentisierung bzw. die Zugangsdaten (z.B. Zertifikat und Passwort). Dies sollte in der Regel im PVS eingestellt werden.
Zitat von VKirschbaum im Beitrag #13In dem Moment, wo TLS in der Koco-Box aktiviert wird, erwartet der Konnektor bei jeder Verbindung die Authentisierung bzw. die Zugangsdaten (z.B. Zertifikat und Passwort).
Damit keine Authentisierungs-/Zugangsdaten von der Kocobox abgefragt werden, reicht es nach meinen bisherigen Erfahrungen (PVS Charly, KIM CGM, Kocobox) lediglich die Option "zusätzliche Authentisierung" zu deaktivieren. TLS hingegen kann IMHO weiter aktiv bleiben.
Ich kann in dieser Konstellation jedenfalls die Verbindung von meinem PVS auf den Konnektor "mit TLS" einrichten.
Streng genommen kann PVS Charly ja auch "nur" TLS + zusätzliche Authentifizierung- im ggs. zur Kocobox wird hier eben nicht zwischen TLS MIT und TLS OHNE Authent. /Zugangsdaten differenziert - wenn man nur will , dass das läuft und allein für Feature VSDM , kann man auch "mit Authent." beim Konnektor laufen lassen, das funktioniert. Aktuell habe ich aber eben wegen CGM KIM , der NICHT mit zusätzliche Authentifizierung via Zertifikat läuft, die Authentisierung rausgenommen- TLS aber beibehalten- dann prüft halt der Konnektor nicht das Zertifikat, es bleibt aber trotzdem alles TLS basiert . (Der KIM Dienst CGM ist aktuell ungesichert aufgesetzt bei mir, also ohne Zertifikate, weil ich den mit Zeritifkat /gesichert nicht ans laufen bekommen habe und CGM bislang bei mir auch nicht- und auch wenn er im Frontend "ungesichert" aufgesetzt wurde, nutzt dieser Dienst trotzdem, was man in den Konfidaten sehen kann, "https", nicht http.
TI-Community
»
TI-Nutzung und Nutzen aus Anwendersicht
»
sichere eMail (KIM)
»
Kocobox Firewall blockt Anfragen von Clientsystemen
10.01.2022 12:06 (zuletzt bearbeitet: 10.01.2022 12:08)
Thema drucken
Antworten
