Bosch IP Kamera Stream über TMG 2010

[Drillsergeant 10]

Hallo zusammen,

 

ich möchte den Videostream einer Bosch Dinion IP NWC-0495 über mein TMG übertragen, was mir bisher nicht gelingen will. Die Bosch Software meldet die Kamera als verfügbar, aber der Stream kommt nicht an. Die Kamera befindet sich in DMZ3 192.168.100.x und ich möchte den Stream im Internal LAN 172.16.20.x empfangen, später soll der Stream via VPN übertragen werden.

Zum Test habe ich eine Firewall Regel von Internal auf DMZ3 mit "All Outbound Traffic" und All Users angelgt. Dazu unter Networking --> Networkrules eine Route von Internal zur DMZ3.

Aus meiner Sicht sollte das Regelwerk so passen, allerdings hatte ich mit TMG bisher wenig zu tun, da bei meinen alten Arbeitgebern StoneGate oder Watchguard eingesetzt wurde.

 

Hat jemand eine ähnliche Konfiguration bereits erfolgreich zum laufen bekommen und kann mir beim TMG weiterhelfen?

 

Beste Grüße

 

Stephan

[Daniel -MSFT- 129]

Wenn aus der DMZ in Richtung INTERNAL gesendet werden soll, hilft eine Regel von INTERNAL nach DMZ wenig. Was steht denn im Log? Was blockiert der TMG? Mit welchem Protokoll streamed die Kamera?

[Doso 77]

Wir haben Forefront TMG und auch IP Kameras im Einsatz. Ist eine einfache Regel, Netz A -> Netz B allow Ports XXX + YYY

bearbeitet 12. Juni 2014 von Doso

[Drillsergeant 10]

Hallo ihr zwei,

 

leider schaffe ich es heute nicht mehr die Log´s zu ziehen, ich melde mich Anfang nächster Woche nochmal.

 

Beste Grüße und schönes Wochenende,

 

Stephan

[Drillsergeant 10]

Guten morgen,

 

die Kamera schickt den Stream via UDP zum Client, deshalb brauche ich tatsächlich eine Regel aus DMZ3 nach Internal. Das klappt soweit ausgezeichnet, allerdings verweigert das TMG die Verbindung von DMZ3 zu den VPN Clients. Im Log sehe ich dazu folgenden Eintrag:

 

Denied Connection TMG01 6/16/2014 10:01:48 AM Log type: Firewall service Status: The action cannot be performed because the session is not authenticated. Rule: Test VPN Access Source: DMZ 03 (192.168.100.39:2050) Destination: VPN Clients (10.1.2.107:64995) Protocol: Unidentified IP Traffic (UDP:64995)

• Number of bytes sent: 0 Number of bytes received: 0
• Processing time: 0ms Original Client IP: 192.168.100.39
• Additional information

 

In der Regel ist der Zugriff von VPN Clients nach DMZ3 und umgekehrt erlaubt, muss noch mehr eingefügt werden?

 

Gruß Stephan

[Daniel -MSFT- 129]

Hast Du in der Test VPN Access-Regel hinterlegt, dass nur authentifizierter Traffic erlaubt ist?

 

Generell gibt es eigentlich keinen Grund, warum ein DMZ-System aktiv Daten an einen VPN-Client senden können soll. Daher wundert mich Deine Aussage in dieser Hinsicht.

Ohne Dein Regelwerk zu kennen ist es eh schwer, eine Empfehlung auszusprechen. Kann die Kamera auf den UDP-Port festgelegt werden? Dann diesen Port von der DMZ in Richtung VPN erlauben.

[Dunkelmann 96]

die Kamera schickt den Stream via UDP zum Client, deshalb brauche ich tatsächlich eine Regel aus DMZ3 nach Internal. Das klappt soweit ausgezeichnet, allerdings verweigert das TMG die Verbindung von DMZ3 zu den VPN Clients. Im Log sehe ich dazu folgenden Eintrag:

Moin,

 

ich kann mir nicht vorstellen, dass die Kamera unaufgefordert einen Stream zum Client sendet - es sei denn der Streaming-CLient ist auf der Kamera als Recording Device konfiguriert oder es wird Muticast genutzt.

I.d.R. wird die Kommunikation vom Client initiiert und erst dann startet der Stream. Das es im LAN (Internal) funktioniert, würde ich pauschal auf eine existierende 'any-any' Regel schieben.

 

Ich würde hier eine eigene Protokolldefinition erstellen. http://www.isaserver.org/articles-tutorials/configuration-general/TMG-Back-Basics-Part3.html

Du musst eventuell etwas pröbeln um herauszufinden, welche Richtung die richtige ist. (Receive, Receive Send, Send and Send Receive). Alternativ mit Wireshark oder MS Netzwerkmonitor den Datenfluss analysieren und die Protokolldefinition auf Basis der Ergebnisse erstellen.

... wenn Du Glück hast, findest Du sogar im Handbuch der Kamera Hinweise für die Kommunikation durch Firewalls.

bearbeitet 17. Juni 2014 von Dunkelmann

[Daniel -MSFT- 129]

Any-Any-Allow zwischen LAN und DMZ macht hebt die Trennung der DMZ völlig auf. Solltest Du Recht haben und eine solche Regel existieren, wäre das ein grober Designfehler. Aber ihn Kenntnis des gesamten Regelwerks kann man bei Firewallfragen nicht wirklich antworten.

[Drillsergeant 10]

Eine allow Any to Any Regel gibt es nicht, im Handbuch der Kamera ist die IP Kommunikation sehr allgemein gehalten.

Im Logging des TMG baut der Client auf Port 1756 TCP eine Verbindung zur Kamera auf, um im Anschluss den Stream via UDP (Port nicht definierbar) zu erhalten. Diese Art der Kommunikation wurde vom Bosch Support so beschrieben, deshalb auch die Regel aus der DMZ in Richtung Internal. Entferne ich die Konfigurierte Testregel, fängt die Default rule (deny all) den Traffic ab. Meine Testregel habe ich nach den ersten Posts folgendermaßen aufgebaut.

 

Allow, All outbound Traffic From: Internal, DMZ3 To: DMZ3, Internal; All Users

 

Entferne ich From: DMZ3 To: Internal aus der Regel bleibt das Bild schwarz, Multicast kommt nicht zum Einsatz.

 

@Daniel: Eine Option nur authentifizierten Traffic über die VPN Regel zu erlauben kann ich nicht finden.

 

 

Gruß Stephan

 

 

 

 

[Dunkelmann 96]

Die 'nicht authentifiziert' Meldung ist etwas wiedersprüchlich. Es kann auch so gelesen werden, dass die Kamera den Stream schicken möchte, aber der TMG keine passende Session auf der Gegenseite (dem Streaming Client) findet.

 

Ich würde bei der Protokolldefinition auf UDP (send receive) tippen, wenn alles über einen Kanal läuft. Manche Systeme nutzen jedoch einen Kanal für die Steuerung und einen zweiten Kanal für den Stream. Dann müsste Deine Protokolldefinition einmal 'send' für Client an Kamera und einmal 'receive' für Kamera an Client beinhalten. Wichtig ist hierbei, dass es in einer einzigen Protokolldefinition konfiguriert wird, sonst kann der TMG den 'receive' Kanal nicht der 'send' Session zuordnen.

[Daniel -MSFT- 129]

@Daniel: Eine Option nur authentifizierten Traffic über die VPN Regel zu erlauben kann ich nicht finden.

 

 

Gruß Stephan

 

Wie schon gesagt: Ohne Kenntnis Deines genauen Regelsets ist es sehr schwer zu helfen. Hast Du die Kamera über eine Server-Veröffentlichungsregel veröffentlicht? Ist die VPN-Regel eine Regel, die für User gilt? Dann lies mal folgendes:

 

Understanding the ISA 2004 Access Rule Processing

4.2. Users

When you create firewall policy rules, you can apply them to specific IP addresses or to users. When you apply a rule to a user, the user will have to authenticate, presenting authentication credentials, as required for the specific rule. You can group users together in User Sets. User sets can include one or more users from any authentication scheme. For example, a user set might include a Windows user, a user from a RADIUS namespace, and another user from the SecurID namespace. ISA Server comes preconfigured with the following user sets:

• All Authenticated Users: predefined user set representing all authenticated users. A rule defined using this set will apply to authenticated users only. 

  Note that SecureNET clients can never authenticate, unless they are also VPN clients. In this case the credentials of the logged on VPN user will be used for authorization.

• All Users: predefined user set representing all users. A rule defined using this set will apply to all users, both authenticated and unauthenticated or anonymous.
• System and Network Service: predefined user set representing the Local System service and the Network service on the ISA Server computer. This user set is used in some system policy rules.

How the clients authenticate to the ISA server depends on the ISA client type handling the request:

• Firewall client: ISA Server requests credentials when a session is established. Then, when the Firewall client requests an object, ISA Server does not ask that the client reauthenticate because the session already has an identity. Keep in mind that the Firewall client authenticates the user to the ISA Server on behalf of the application requesting the access.
• Web Proxy client: after enabling Web Proxy client access for the specific network on which the user is located, you can configure the authentication mechanisms that will be used to authenticate the Web Proxy clients. When the setting Require all users to authenticate on the Web Proxy listener is selected, ISA Server will always ask for user credentials before checking the firewall policy. Otherwise, ISA Server will only request that the client authenticate if the rule requires client authentication to validate the match.

Furthermore, you should be aware of two interesting situations regarding user authentication:

• If the rule applies to the All Users user set, ISA Server will not request user credentials. However, the Firewall client will always send credentials to the ISA Server. You'll see this in effect in the MMC in the session and logging tab when a user name has a question mark (?) next to it. This means in fact that user credentials are presented but that they are not validated.
• When you configure access rules that apply to users and the user can not authenticate themselves for any reason, then the request will be denied by the rule requiring authentication, even if it is an allow rule. This situation can arise if you forget to enable at least one authentication mechanism on the Web Proxy listener. By the same token, ISA server will deny any request from a SecureNET client, not being a VPN client at that moment, when hitting a rule requiring user authentication.

Insbesondere der letzte Absatz ist vermutlich für Dich wichtig.

 

Was die Kamera angeht, schau mal in das Handbuch unter http://www.bosch-securitysystems.cz/store/manualy_en/NWC-0495DinionX_InstallationGuide_en.pdf auf Seite 77. Du musst bei 'Video Transmission' TCP Port 80 für HTTP (und nicht UDP) als Protokoll wählen. Dann kannst Du die Kamera vermutlich einfach über eine Serververöffentlichungsregel wie einen Webserver veröffentlichen. 

[Drillsergeant 10]

Wie im letzten Absatz beschrieben, müsste bei meiner Regel jeglicher Traffic durch einen Benutzer der Gruppe "Test VPN Users" authentifiziert werden?! So wie ich die Regel im Screenshot aufgebaut habe, würde ich sie im Normalfall definieren, ohne das DMZ3 zum VPN Client senden darf.

Gehen wir davon aus, das die Kamera den Stream nach Aufforderung des Clients auf Port 1756 TCP als Stream über einen belibigen Port schicken möchte, hätte sie keine Chance, da sie sich am TMG authentifizieren muss. Verstehe ich das so richtig? Wenn ja, wie kann ich unterschiedlichen VPN Usern, Zugriff auf bestimmte IP Bereiche gewähren?

Die Regel wurde als Access Regel angelegt. Eine Umstellung an der Kamera auf TCP, hat keine Änderung bewirkt. Gebe ich DMZ3 den Zugriff auf Internal nicht frei, bleibt es dunkel.

 

Beste Grüße

 

Stephan

bearbeitet 18. Juni 2014 von Drillsergeant

[Dunkelmann 96]

Wie im letzten Absatz beschrieben, müsste bei meiner Regel jeglicher Traffic durch einen Benutzer der Gruppe "Test VPN Users" authentifiziert werden?! So wie ich die Regel im Screenshot aufgebaut habe, würde ich sie im Normalfall definieren, ohne das DMZ3 zum VPN Client senden darf.

Gehen wir davon aus, das die Kamera den Stream nach Aufforderung des Clients auf Port 1756 TCP als Stream über einen belibigen Port schicken möchte, hätte sie keine Chance, da sie sich am TMG authentifizieren muss. Verstehe ich das so richtig? Wenn ja, wie kann ich unterschiedlichen VPN Usern, Zugriff auf bestimmte IP Bereiche gewähren?

Die Regel wurde als Access Regel angelegt. Eine Umstellung an der Kamera auf TCP, hat keine Änderung bewirkt. Gebe ich DMZ3 den Zugriff auf Internal nicht frei, bleibt es dunkel.

 

Beste Grüße

 

Stephan

Die Kamera muss sich nicht am TMG authentifizieren, wenn

1. der Client die Kommunikation initiiert hat und der TMG den Stream der Clientanforderung zuordnen kann (hier kann der MS Netzwerk Monitor auf einem Client helfen)
2. anonyme Kommunikation erlaubt ist (bei Protokoll <> http)
3. bei http der Webproxy für die Ziele deaktiviert ist http://technet.microsoft.com/en-us/library/cc441482.aspx
4. bei http ggf. zusätzlich ein benutzerdefiniertes http-Protokoll mit nachfolgender 'deny' Regel verwendet wird um den Webproxy für SecureNAT Clients restlos zu deaktivieren http://blogs.technet.com/b/isablog/archive/2006/09/25/why-do-i-need-a-deny-rule-to-make-an-allow-rule-for-a-custom-protocol-work-correctly.aspx
5. ... usw ...

Bei vielen embedded Systemen ist häufig Kreativität bei der Fehlersuche und -behebung gefragt (Wireshark, Netwerkmonitor). Das Systeme Port 80 für die Kommunikation nutzen, muss nicht zwangsläufig bedeuten, dass auch 'echtes' http als Protokoll verwendet wird. Der TMG kann auf solche Abnormitäten recht garstig reagieren. Der TMG führt bspw. eine Liste zulässiger http Requests, String Längen usw.

 

Viele - auch namhafte - Hersteller bauen gute Geräte und 'basteln' dann Netzfuktionalität dazu. Das ist nicht immer gut durchdacht, dokumentiert und funktioniert bestenfalls in einem single Subnet LAN mit NAT Router problemlos.

[Drillsergeant 10]

Hallo zusammen,

 

es funktioniert  :)  

Ausschlaggebend war das benutzerdefinierte http, sodass der Traffic nicht durch den Webproxy gefiltert wird. Ich war bei "all outbound Traffic" davon ausgegangen, das der Proxy seine Finger nicht im Spiel hat.

 

Danke für eure Unterstützung :thumb1:

 

Schönes Wochenende

 

Gruß Stephan

[Dunkelmann 96]

Danke für die Rückmeldung und viel Spass beim Videogucken ... oder doch lieber Fußball :cool: