PfSense lässt Client nicht ins Internet trotz offener Firewall

sueimweb

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:

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 44

Im 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 0

Im Firewall-Protokoll fehlen auch diese Datenpakete....

Auch ein Wireshark-Mitschnitt zeigt weder die Datenpakete an Port 32100, noch die Push-Nachricht an Port 443.

Irgendwo/irgendwie 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

sueimweb

Die Sache hat sich erledigt, vielen Dank für's Lesen.
Ich hatte einen Fehler im Captiveportal gemacht und gehe jetzt in die Ecke mich schämen.

JeGr

Ich bin mal so frech und reaktiviere das bevors im Nirvana verschwindet, da ich denke - selbst wenn dus selbst gelöst hast und es trivial war - es hilft vielleicht jemand anderem der den gleichen Fehler macht. Daher bitte:

Schämt euch nie Fehler zuzugeben oder zu machen, nur dazulernen bringt einen weiter. Und das kann man nicht nur dadurch immer alles "perfekt" zu machen :)

@S-Block Daher fürs selbst finden, jetzt wär ich nur neugierig was es denn war :)

sueimweb

Hi JeGr,

ok, es war wirklich ein ganz doofer Fehler.

Auf der PfSense ist das CaptivePortal für das betreffende WLAN aktiv. Ein paar Benutzer sind in der Liste der freigegebenen MACs eingetragen, unter anderem natürlich auch die Gegensprechanlage, da die ja nicht auf einen Login Button klicken kann. Tja, beim Copy and Paste der Mac Adresse war ich in der Zeile verrutscht und hatte eine falsche Mac Adresse dort hinterlegt.

Gruß
Susanne

JeGr

@sueimweb said in PfSense lässt Client nicht ins Internet trotz offener Firewall:

ok, es war wirklich ein ganz doofer Fehler.

Die machen wir doch alle

Tja, beim Copy and Paste der Mac Adresse war ich in der Zeile verrutscht und hatte eine falsche Mac Adresse dort hinterlegt.

Aber genau diese Art Fehler vergisst man viel zu häufig und sucht sich dann zu Tode bis man vielleicht mal drauf gestoßen wird! Mir selbst auch schon an anderer Stelle passiert, daher: lieben Dank dass du uns teilhaben lässt und ggf. nochmal anstößt, nachzuschauen ob da sich nicht doch irgendwo ein CopyPasta Fehler eingeschlichen hat

Außerdem hätte ich den Post ungern gelöscht gesehen, wo hier so schön vorgelegt und debuggt wurde mit Packet Captures und Beschreibung - sowas muss auch mal gelobt werden!