9
Ist Erledigt.war mein Fehler
Hallo an alle,
ich versuche hier seit Tagen eine Lösung für ein Problem zu finden und bin mit meinem Latein am Ende:
Ich arbeite in einer Klinik mit integrierter Arztpraxis, die eine eigene Eingangstür besitzt. Um im Rahmen der Corona-Maßnahmen den Zugang zu kontrollieren, haben wir vom Elektriker eine IP Gegensprechanlage mit Kamera installieren lassen, die in unserem WLAN-Netz hängt. Außerdem ist die Anlage per Klingeldraht (2-adrig) angeschlossen, um den Türöffner zu steuern. Der Zugriff auf die Anlage kann ausschließlich über Apps erfolgen, die für iOS und für Android verfügbar sind. Die Einstellungsmöglichkeiten sind sehr dürftig (man kann z. B. keine statische IP-Adresse vergeben). Das Klingeln eines Besuchers wird an das mobile Endgerät mittels Push-Nachricht über das Internet (Amazon Web Services) gemeldet.
Für das WLAN-Netz läuft eine PfSense in einer Hyper-V VM. Dieses WLAN läuft schon seit Jahren ohne Probleme.
Im DHCP-Server habe ich die MAC Adresse der Gegensprechanlage einer festen IP-Adresse zugewiesen. Außerdem habe ich in der Firewall für die entsprechende IP-Adresse eine "ALLOW-ALL" Regel erstellt. Zu Diagnosezwecken habe ich außerdem in der Firewall die Protokollierung aktiviert.
Die Gegensprechanlage bezieht ihre voreingestellte IP-Adresse.
Die Anlage ist per App aus dem WLAN-Netz erreichbar, kann konfiguriert werden und das Kamerabild wird an ein iPad übertragen.
Auch der Türöffner funktioniert aus der App heraus.
Aber die Anlage kommt nicht ins Internet!
Paketmitschnitt auf der PfSense:
Die Anlage versucht wohl, sich auf AWS zu registrieren:
Im Firewall-Protokoll sind diese Pakete trotz aktivierter Protokollierung NICHT SICHTBAR.....!?!?!?!?!?
Die Anlage versendet eine Push-Nachricht beim Klingeln:
Im Firewall-Protokoll sind auch diese Pakete trotz aktivierter Protokollierung NICHT SICHTBAR.....!?!?!?!?!?
Auch ein Wireshark-Mitschnitt zeigt weder die Datenpakete an Port 32100, noch die Push-Nachricht an Port 443.
Irgendwo scheint die PfSense die Datenpakete zu "verschlucken" und ich habe keine Ahnung, wie ich das lösen soll.
Kann mir bitte jemand helfen, hat einer von euch eine Idee?
Viele Grüße aus dem kalten, grauen Hessen
Susanne
ich versuche hier seit Tagen eine Lösung für ein Problem zu finden und bin mit meinem Latein am Ende:
Ich arbeite in einer Klinik mit integrierter Arztpraxis, die eine eigene Eingangstür besitzt. Um im Rahmen der Corona-Maßnahmen den Zugang zu kontrollieren, haben wir vom Elektriker eine IP Gegensprechanlage mit Kamera installieren lassen, die in unserem WLAN-Netz hängt. Außerdem ist die Anlage per Klingeldraht (2-adrig) angeschlossen, um den Türöffner zu steuern. Der Zugriff auf die Anlage kann ausschließlich über Apps erfolgen, die für iOS und für Android verfügbar sind. Die Einstellungsmöglichkeiten sind sehr dürftig (man kann z. B. keine statische IP-Adresse vergeben). Das Klingeln eines Besuchers wird an das mobile Endgerät mittels Push-Nachricht über das Internet (Amazon Web Services) gemeldet.
Für das WLAN-Netz läuft eine PfSense in einer Hyper-V VM. Dieses WLAN läuft schon seit Jahren ohne Probleme.
Im DHCP-Server habe ich die MAC Adresse der Gegensprechanlage einer festen IP-Adresse zugewiesen. Außerdem habe ich in der Firewall für die entsprechende IP-Adresse eine "ALLOW-ALL" Regel erstellt. Zu Diagnosezwecken habe ich außerdem in der Firewall die Protokollierung aktiviert.
Die Gegensprechanlage bezieht ihre voreingestellte IP-Adresse.
Die Anlage ist per App aus dem WLAN-Netz erreichbar, kann konfiguriert werden und das Kamerabild wird an ein iPad übertragen.
Auch der Türöffner funktioniert aus der App heraus.
Aber die Anlage kommt nicht ins Internet!
Paketmitschnitt auf der PfSense:
Die Anlage versucht wohl, sich auf AWS zu registrieren:
12:06:47.729292 ec:3d:fd:54:fa:9a (oui Unknown) > 00:15:5d:1f:05:03 (oui Unknown), ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 72)
192.168.200.76.17624 > ec2-23-21-195-143.compute-1.amazonaws.com.32100: [udp sum ok] UDP, length 44
12:06:47.729301 ec:3d:fd:54:fa:9a (oui Unknown) > 00:15:5d:1f:05:03 (oui Unknown), ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 72)
192.168.200.76.17624 > ec2-122-248-232-207.ap-southeast-1.compute.amazonaws.com.32100: [udp sum ok] UDP, length 44
12:06:47.729305 ec:3d:fd:54:fa:9a (oui Unknown) > 00:15:5d:1f:05:03 (oui Unknown), ethertype IPv4 (0x0800), length 86: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 72)
192.168.200.76.17624 > ec2-176-34-104-236.eu-west-1.compute.amazonaws.com.32100: [udp sum ok] UDP, length 44Im Firewall-Protokoll sind diese Pakete trotz aktivierter Protokollierung NICHT SICHTBAR.....!?!?!?!?!?
Die Anlage versendet eine Push-Nachricht beim Klingeln:
12:12:17.447162 ec:3d:fd:54:fa:9a (oui Unknown) > 00:15:5d:1f:05:03 (oui Unknown), ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 38294, offset 0, flags [DF], proto UDP (17), length 64)
192.168.200.76.41162 > pfSense.naturana.local.domain: [udp sum ok] 10118+ A? apns01.omguard.com. (36)
12:12:17.479945 00:15:5d:1f:05:03 (oui Unknown) > ec:3d:fd:54:fa:9a (oui Unknown), ethertype IPv4 (0x0800), length 188: (tos 0x0, ttl 64, id 33402, offset 0, flags [none], proto UDP (17), length 174, bad cksum 0 (->e625)!)
pfSense.naturana.local.domain > 192.168.200.76.41162: [bad udp cksum 0x124b -> 0x11aa!] 10118 q: A? apns01.omguard.com. 4/0/0 apns01.omguard.com. CNAME pushapi-sslv3-592863544.us-east-1.elb.amazonaws.com., pushapi-sslv3-592863544.us-east-1.elb.amazonaws.com. A 54.159.78.101, pushapi-sslv3-592863544.us-east-1.elb.amazonaws.com. A 54.146.105.111, pushapi-sslv3-592863544.us-east-1.elb.amazonaws.com. A 107.23.108.214 (146)
12:12:17.486444 ec:3d:fd:54:fa:9a (oui Unknown) > 00:15:5d:1f:05:03 (oui Unknown), ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 6854, offset 0, flags [DF], proto TCP (6), length 60)
192.168.200.76.47177 > ec2-54-159-78-101.compute-1.amazonaws.com.https: Flags [S], cksum 0xb436 (correct), seq 1791725404, win 14600, options [mss 1460,sackOK,TS val 50763162 ecr 0,nop,wscale 2], length 0Im Firewall-Protokoll sind auch diese Pakete trotz aktivierter Protokollierung NICHT SICHTBAR.....!?!?!?!?!?
Auch ein Wireshark-Mitschnitt zeigt weder die Datenpakete an Port 32100, noch die Push-Nachricht an Port 443.
Irgendwo scheint die PfSense die Datenpakete zu "verschlucken" und ich habe keine Ahnung, wie ich das lösen soll.
Kann mir bitte jemand helfen, hat einer von euch eine Idee?
Viele Grüße aus dem kalten, grauen Hessen
Susanne
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 625626
Url: https://administrator.de/contentid/625626
Printed on: April 19, 2024 at 23:04 o'clock
9 Comments
Latest comment
Moin,
vielleicht würde es anderen helfen wenn du noch kurz die Lösung anhängst.
Gruß
Spirit
vielleicht würde es anderen helfen wenn du noch kurz die Lösung anhängst.
Gruß
Spirit
1
Moin,
Lösung wäre super.
Dazu: Wenn Ihr eine Klinik seid, wollen eure Kunden/Patienten wirklich, dass alle Ihre Gesichter in die AWS geschoben werden (was zu vermuten ist)? Das gilt es kritisch zu überprüfen!
Grüße
Lösung wäre super.
Dazu: Wenn Ihr eine Klinik seid, wollen eure Kunden/Patienten wirklich, dass alle Ihre Gesichter in die AWS geschoben werden (was zu vermuten ist)? Das gilt es kritisch zu überprüfen!
Grüße
1
Zitat von @falscher-sperrstatus:
Moin,
Lösung wäre super.
Dazu: Wenn Ihr eine Klinik seid, wollen eure Kunden/Patienten wirklich, dass alle Ihre Gesichter in die AWS geschoben werden (was zu vermuten ist)? Das gilt es kritisch zu überprüfen!
Grüße
Moin,
Lösung wäre super.
Dazu: Wenn Ihr eine Klinik seid, wollen eure Kunden/Patienten wirklich, dass alle Ihre Gesichter in die AWS geschoben werden (was zu vermuten ist)? Das gilt es kritisch zu überprüfen!
Grüße
Ich gehe mal davon aus, dass lediglich die Klingelbenachrichtigung darüber läuft und nicht das Bild - hoffe ich
Grüße
Solche kritischen Anlagen sollten auch nicht ins Internet. Da gehört eine Firewall davor, die das verhindert!
Ich glaube du solltest mit deinem Sicherheitsbeauftragten nochmal reden.
lks
1Solche kritischen Anlagen sollten auch nicht ins Internet. Da gehört eine Firewall davor, die das verhindert!
Firewall hat er doch, aber wenn die blockiert, gibt's (offensichtlich) kein Signal...
Zitat von @falscher-sperrstatus:
Firewall hat er doch, aber wenn die blockiert, gibt's (offensichtlich) kein Signal...
Solche kritischen Anlagen sollten auch nicht ins Internet. Da gehört eine Firewall davor, die das verhindert!
Firewall hat er doch, aber wenn die blockiert, gibt's (offensichtlich) kein Signal...
Dann haben sie die falsche Anlage angeschafft.
lks
1Zitat von @Lochkartenstanzer:
Dann haben sie die falsche Anlage angeschafft.
lks
Zitat von @falscher-sperrstatus:
Firewall hat er doch, aber wenn die blockiert, gibt's (offensichtlich) kein Signal...
Solche kritischen Anlagen sollten auch nicht ins Internet. Da gehört eine Firewall davor, die das verhindert!
Firewall hat er doch, aber wenn die blockiert, gibt's (offensichtlich) kein Signal...
Dann haben sie die falsche Anlage angeschafft.
lks
Nunja, das kommt ganz drauf an. Es gibt genug, die sich auf "alles zu Amazon/Cloud" einen sprichwörtlich...
Hallo,
Und warum fragst Du nicht den und lässt ihn sein Geraffel nachbessern?
Umso besser!
Vielleicht schubst die Anlage das Geraffel durch einen VPN-Tunnel? Was sagt denn der Elektriker dazu?
Gruß,
Jörg
Übrigens: Es ist übrigens unüblich, kritische Infrastrukturen über W-LAN und das Internet zu blasen. Ich hatte da mal 'ne Apotheke, die haben aufgrund einer Störung nicht mal ihre Tür abgeschlossen bekommen. Der Laden musste 2 Tage lang rund um die Uhr bewacht werden, verschreibungspflichtiges Geraffel wurde so lange extern verwahrt. Im Anschluss gab's dann wieder was mit Schließzylinder
Zitat von @SueImWeb:
Ich arbeite in einer Klinik mit integrierter Arztpraxis, die eine eigene Eingangstür besitzt. Um im Rahmen der Corona-Maßnahmen den Zugang zu kontrollieren, haben wir vom Elektriker eine IP Gegensprechanlage mit Kamera installieren lassen, die in unserem WLAN-Netz hängt.
Ich arbeite in einer Klinik mit integrierter Arztpraxis, die eine eigene Eingangstür besitzt. Um im Rahmen der Corona-Maßnahmen den Zugang zu kontrollieren, haben wir vom Elektriker eine IP Gegensprechanlage mit Kamera installieren lassen, die in unserem WLAN-Netz hängt.
Und warum fragst Du nicht den und lässt ihn sein Geraffel nachbessern?
Aber die Anlage kommt nicht ins Internet!
Umso besser!
Im Firewall-Protokoll sind diese Pakete trotz aktivierter Protokollierung NICHT SICHTBAR.....!?!?!?!?!?
Vielleicht schubst die Anlage das Geraffel durch einen VPN-Tunnel? Was sagt denn der Elektriker dazu?
Gruß,
Jörg
Übrigens: Es ist übrigens unüblich, kritische Infrastrukturen über W-LAN und das Internet zu blasen. Ich hatte da mal 'ne Apotheke, die haben aufgrund einer Störung nicht mal ihre Tür abgeschlossen bekommen. Der Laden musste 2 Tage lang rund um die Uhr bewacht werden, verschreibungspflichtiges Geraffel wurde so lange extern verwahrt. Im Anschluss gab's dann wieder was mit Schließzylinder
1
Huhu,
sorry, dass ich mich erst jetzt melde, ich hatte gar keine Antworten mehr erwartet, da ich kurz nach dem Posten "schon" auf die Lösung gestoßen war. Das "schon" deshalb in Anführungszeichen, weil ich eigentlich in die Ecke gehen und mich schämen müsste.
Der Fehler lag schlicht darin, dass auf der PfSense ein Captive Portal läuft und ich beim Copy und Paste aus Versehen die falsche MAC Adresse für den Eintrag in die Liste der freigegebenen MACs erwischt hatte. Na und die Anlage kann natürlich nicht auf den Login Button des Captive Portals klicken. Das ist mir heute nach 3 Tagen tracen und suchen endlich aufgefallen. *rotwerd*
Die Bilder werden nur dann über das Internet übertragen wenn sich jemand aus einem externen Netzwerk mit den entsprechenden Zugangsdaten über die App auf die Anlage verbindet, was in unserem Fall nicht stattfindet. Und selbstverständlich ist auch die Speicherfunktion deaktiviert.
Die Internetverbindung zu AWS wird bei dieser Anlage ausschließlich für den Versand der Pushnachrichten (Klingeln) benötigt.
Ich hätte dieses Ding auch nicht angeschafft, aber die GF wollte für "die paar Monate" nicht übermäßig viel investieren. Mir blieb nur, die beiden Firewalls davor so gut wie möglich abzuschotten. Bei den heutigen Protokollen konnte ich keine verdächtigen Pakete erkennen, die nicht geblockt wurden.
Da sind sogar zwei davor und entsprechend konfiguriert.
Der Sicherheitsbeauftragte hat damit übrigens nichts zu tun, zumindest nicht bei uns, der hat von IT keine Ahnung.
Vielen Dank an alle für eure Bemühungen und eure Zeit!
Ich wünsche ein schönes Wochende
Susanne
sorry, dass ich mich erst jetzt melde, ich hatte gar keine Antworten mehr erwartet, da ich kurz nach dem Posten "schon" auf die Lösung gestoßen war. Das "schon" deshalb in Anführungszeichen, weil ich eigentlich in die Ecke gehen und mich schämen müsste.
Der Fehler lag schlicht darin, dass auf der PfSense ein Captive Portal läuft und ich beim Copy und Paste aus Versehen die falsche MAC Adresse für den Eintrag in die Liste der freigegebenen MACs erwischt hatte. Na und die Anlage kann natürlich nicht auf den Login Button des Captive Portals klicken. Das ist mir heute nach 3 Tagen tracen und suchen endlich aufgefallen. *rotwerd*
Dazu: Wenn Ihr eine Klinik seid, wollen eure Kunden/Patienten wirklich, dass alle Ihre Gesichter in die AWS geschoben werden (was zu vermuten ist)? Das gilt es kritisch zu überprüfen!
Die Bilder werden nur dann über das Internet übertragen wenn sich jemand aus einem externen Netzwerk mit den entsprechenden Zugangsdaten über die App auf die Anlage verbindet, was in unserem Fall nicht stattfindet. Und selbstverständlich ist auch die Speicherfunktion deaktiviert.
Die Internetverbindung zu AWS wird bei dieser Anlage ausschließlich für den Versand der Pushnachrichten (Klingeln) benötigt.
Übrigens: Es ist übrigens unüblich, kritische Infrastrukturen über W-LAN und das Internet zu blasen.
Ich hätte dieses Ding auch nicht angeschafft, aber die GF wollte für "die paar Monate" nicht übermäßig viel investieren. Mir blieb nur, die beiden Firewalls davor so gut wie möglich abzuschotten. Bei den heutigen Protokollen konnte ich keine verdächtigen Pakete erkennen, die nicht geblockt wurden.
Solche kritischen Anlagen sollten auch nicht ins Internet. Da gehört eine Firewall davor, die das verhindert!
Ich glaube du solltest mit deinem Sicherheitsbeauftragten nochmal reden.
Ich glaube du solltest mit deinem Sicherheitsbeauftragten nochmal reden.
Da sind sogar zwei davor und entsprechend konfiguriert.
Der Sicherheitsbeauftragte hat damit übrigens nichts zu tun, zumindest nicht bei uns, der hat von IT keine Ahnung.
Vielen Dank an alle für eure Bemühungen und eure Zeit!
Ich wünsche ein schönes Wochende
Susanne
