This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Webcam in DMZ / DNAT Regel funktioniert halb / FW-Log: Standard verwerfen

Hallo,

ich habe Webcam in der internen DMZ mit der IP: 192.168.1.8

Meine öffentliche IPv4 Adresse lautet: 212.xxx.xxx.xxx
Extern habe ich den Port: TCP2080 (Quelle: 1:65535 & Ziel: 2080) eröffnet

Die DNAT Regel anbei:

Any -> TCP2080 -> WAN IP 212.xxx
Webcam mit HTTP 80

Im Log taucht meine Anfrage (NAT Regel 7) auch auf mit dem Port 2080.

Aber die Übersetzung auf Port 80 auf die DMZ IP der Webcam funktioniert nicht.

Ich habe auch eine manuelle FW Regel (oben platziert) zum Testen mit Logging erstellt: Any -> HTTP 80 -> 192.168.1.8
Die taucht im Log nicht auf und es bleibt bei "Standard verwerfen".

Hat jemand eine Idee?

Viele Grüße

Matthias



This thread was automatically locked due to age.
Parents
  • Hallo Matthias,

    mit "automatischer Firewallregel" aktiviert, steht diese immer über allen manuell angelegten.
    Damit kann deine manuelle Rule nicht matchen.

    Du kannst aber in der Ruleliste die Ansicht auf "automatisch erstellte rules" oder "alle" ändern und siehst dann auch die automatisch erstellten.
    Hier kann mittels "bearbeiten" auch das logging für diese Rules aktiviert werden.

    Zeige dann mal bitte die automatische Rule. Ich hatte noch nie den Fall, dass diese nicht gepasst hat.


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

  • Hallo,

    die manuelle FW Regel habe ich entfernt, die automatisch angelegt sieht wie folgt aus:

  • ok, ich erkenne spontan keinen Grund, warum die Regel nicht greifen sollte.
    Es ist ja genau das erlaubt, was im Screenshot oben geblockt wurde ...

    Da müsste man evtl. noch mal genauer draufgucken ...
    Ist die Definition für "Webcam-Carport" evtl. an ein Interface gebunden? 


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

Reply
  • ok, ich erkenne spontan keinen Grund, warum die Regel nicht greifen sollte.
    Es ist ja genau das erlaubt, was im Screenshot oben geblockt wurde ...

    Da müsste man evtl. noch mal genauer draufgucken ...
    Ist die Definition für "Webcam-Carport" evtl. an ein Interface gebunden? 


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

Children
  • Ja die Definition "Webcam-Carport" ist der Schnittstelle DMZ zugewiesen. Ich habe sie einmal auf "Beliebig" gesetzt. Ändert leider auch nichts.

    Leider sehe ich im Log auch nicht mehr, wieso der Zugriff geblockt wurde.

    Die öffentliche IP ist eine gemietete von einem Provider, hier habe ich nach der Anleitung vom Provider (speziell für die Sophos UTM9) einen IPSec Tunnel aufgebaut. Die restlichen Anfragen über den WAF funktioniere alle, nur die DNAT Regel nicht.

  • Der nächste Schritt wäre ein TCP-Dump. Einmal auf die eingehenden Pakete (den Port) filtern und sehen, ob was kommt/geht und dann das für die Verbindung nach "innen".
    Hast du das logging für die automatische Rule mal aktiviert?

    PS: Funktioniert die WebCam mit WAF nicht?


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

  • Danke, im tcpdump kann ich keine Pakete an die interne DMZ IP erkennen.
    Weder auf die int. IP noch auf den Port 80 der Webcam.

    Die externen Anfragen zur öffentlichen IP auf dem Port 2080 gehen ein, anbei der tcpdump:

    utm:/root # tcpdump -i any port 2080 -nn -XX
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
    10:06:55.300853 IP 94.31.xx.xx.51185 > 212.58.xx.xx.2080: Flags [S], seq 2804849728, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 505742853 ecr 0,sackOK,eol], length 0
            0x0000:  0000 0001 0006 989b cbac 2f1c 0000 0800  ........../.....
            0x0010:  4500 0040 0000 4000 2f06 6775 5e1f 6152  E..@..@./.gu^.aR
            0x0020:  d43a 5097 c7f1 0820 a72e 9c40 0000 0000  .:P........@....
            0x0030:  b002 ffff 1b0e 0000 0204 05b4 0103 0306  ................
            0x0040:  0101 080a 1e25 0605 0000 0000 0402 0000  .....%..........

    Und das habe ich im FW Log (Protokollierung) gefunden:

    2023:12:01-10:21:00 utm ulogd[31041]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="eth1" outitf="eth1" srcmac="98:9b:cb:ac:2f:1c" dstmac="00:0c:29:68:8f:fa" srcip="94.31.xx.xx" dstip="192.168.1.8" proto="6" length="64" tos="0x00" prec="0x00" ttl="46" srcport="54275" dstport="80" tcpflags="SYN"