Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 18 replies
  • Subscribers 28 subscribers
  • Views 22058 views
  • Users 0 members are here
Options
Suggested
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

NAT Regel ANY -> VM Kaspersky Port 13292NAT

Oliver Heinlein

Hallo zusammen,

wir haben Kaspersky Security Center 10 bei uns im Einsatz. Nun sollen unsere AD Mitarbeiter Smartphones erhalten welche Kaspersky Endpoint Secutity installiert haben, und mit Security Center verbunden sind.

Damit die auch funktioniert, wenn man Außerhalb der Firma ist, habe ich eine Full-NAT Regel erstellt. Welche folgendes besagt:

ANY IP -> Dienst 13292 (Kaspersky) -> Öffentliche WAN

Ziel ändern -> IP der VM

Quelle ändern -> IP der Sophos

Wenn ich nun einen Sync mit Kaspersky versuche, bekomme einen Fehler angezeigt. Der Log vom in der Firewall ist mal weiß, mal rot hinterlegt. Obwohl der Eintrag Identisch ist.

Trage ich eine Firewall Regel ein welche besagt "Any -> 13292 -> öffentliche IP", akzeptiert es zwar die Firewall, aber er leitet meinen Port ja dann nicht wie die NAT Regel an die VM weiter.

 

Ich danke schon mal für eure Hilfe.



This thread was automatically locked due to age.
Parents Reply
  • 0 in reply to ThorstenSult

    Die Regel ist aktiv wie man im Log sieht.

    IPs und MAc hab ich aus Sicherheitsgründen zum teil geschwärzt. relevante teile zur Unterscheidung sind aber noch sichtbar.

    im Kaspersky Endpoint Secirity ist unter Server die richtige IP eingetragen, und unter Port auch 13292.

    Dennoch erhalte ich die Fehlermeldung "Fehler: Anfrage an Kaspersky Security Center konnte nicht gesendet werden"

     

Children
  • 0 in reply to Oliver Heinlein

    Die roten Einträge wären jetzt interessant gewesen...

  • 0 in reply to ThorstenSult

    Entschuldige bitte.

    Hier ein roter Eintrag:

    Die weiteren roten Einträge unterscheiden sich nicht wirklich von diesem. Lediglich der Port ist ab und an mal anders.

     

    Vielen Dank schon mal für die Bemühungen.

  • 0 in reply to Oliver Heinlein

    Hallo Oliver,

    Erstmal herzlich willkommen hier in der Community !

    (Sorry, my German-speaking brain isn't creating thoughts at the moment. [:(])

    Instead of a Full NAT, I would have used a simple DNAT and a traffic selector of 'Internet IPv4 -> Kaspersky -> WAN (SDSL)', but I don't think that would change this situation.

    Alone among the logs, the Firewall Live Log presents abbreviated information in a format easier to read quickly.  Usually, you can't troubleshoot without looking at the corresponding line from the full Firewall log file.  Please post one line corresponding to the red line above.  When obfuscating information, please leave enough to make it easy to understand the difference between internal and external addresses, like 10.x.y.21.

    MfG - Bob (Bitte auf Deutsch weiterhin.)

  • 0 in reply to BAlfson

    Hallo Bob,

    vielen Dank für den Willkommensgruß und deine Antwort

     

    Entschuldige bitte das ich erst so späte Antworte, hatte ein verlängertes Wochenende. [:D]

    Nun zu meinem Problem:

    1: Ich habe die NAT Regel jetzt auf unsere zweite IP gelegt, da die erste über den Port 13292 mit unserem Webshop Kommuniziert. Hier ist mal der gewünschte ungekürzte Log:

    2018:02:28-07:54:33 vofuefw-2 ulogd[970]: id="2000" severity="info" sys="SecureNet" sub="packetfilter" name="Packet logged" action="log" fwrule="62004" initf="ppp0" srcip="80.1xx.xx.204" dstip="217.xx.xxx.185" proto="6" length="60" tos="0x00" prec="0x00" ttl="53" srcport="24338" dstport="13292" tcpflags="SYN"

    80.1xx.xx.204 = Smartphone

    217.9x.xxx.185 = Unsere zweite Leitung

     

    Im Live-log sieht man nun auch das er versucht auf den Kaspersky Server weiterzuleiten. Jedoch stört anscheinend irgend etwas.

     

    Ich hoffe man sieht genug von der IP um sie unterscheiden zu können. Da es sich allerdings nur um diese drei handelt, und alle unterschiedlich Anfangen, sollte es keine Probleme geben.

     

    Vielen Dank.

    MFG Oliver

     

  • 0 in reply to Oliver Heinlein

    The line above has action="log" and we're looking for one with action="drop" and a fwrule of 60001, 60002 or 60003.  I expect it will be 60002, but we need to confirm that.

    The picture of the line in your earlier post showed that it was for a RST packet.  Normally, that's not anything to worry about if there are no problems.

    MfG - Bob (Bitte auf Deutsch weiterhin.)

  • 0 in reply to BAlfson

    Nach langer Suche habe ich nun solche Einträge gefunden:

    2018:02:28-08:32:28 vofuefw-2 ulogd[970]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="ppp0" srcip="80.1xx.xx.204" dstip="217.9x.xxx.185" proto="6" length="40" tos="0x00" prec="0x00" ttl="53" srcport="23320" dstport="13292" tcpflags="RST"

    2018:02:28-09:10:43 vofuefw-2 ulogd[970]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="ppp0" srcip="80.1xx.xx.204" dstip="217.9x.xxx.185" proto="6" length="40" tos="0x00" prec="0x00" ttl="53" srcport="27562" dstport="13292" tcpflags="RST"

    2018:02:28-09:16:57 vofuefw-2 ulogd[970]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="ppp0" srcip="80.1xx.xx.204" dstip="217.9x.xxx.185" proto="6" length="40" tos="0x00" prec="0x00" ttl="53" srcport="14377" dstport="13292" tcpflags="RST"

    2018:02:28-09:17:33 vofuefw-2 ulogd[970]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="ppp0" srcip="80.1xx.xx.204" dstip="217.9x.xxx.185" proto="6" length="40" tos="0x00" prec="0x00" ttl="53" srcport="16039" dstport="13292" tcpflags="RST"

    2018:02:28-09:25:44 vofuefw-2 ulogd[970]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="ppp0" srcip="80.1xx.xx.204" dstip="217.9x.xxx.185" proto="6" length="40" tos="0x00" prec="0x00" ttl="53" srcport="5911" dstport="13292" tcpflags="RST"

    Ich hoffe diese Meldungen helfen weiter.

     

    Vielen Dank

    MFG Oliver

  • 0 in reply to Oliver Heinlein

    Hey Oliver,

    das sollte eig. gar keine Auswirkung haben aber versuch mal in der NAT Regel in Quelle und Ziel bei "Dienst ändern in" jeweils nochmal den Kaspersky Port einzutragen.

    Zusätzlich guck dir doch mal die automatisch erstellten Firewallregeln an, ob die auch wirklich Sinn ergeben oder ob da etwas komisch aussieht.

    Alternativ kannst du auch mal ganz oben eine Allow-Regel bauen mit "ANY -> ANY -> Kaspersky-Server", das Logging aktivieren, im Live Log nach der IP des Kaspersky Servers filtern und testen.

    Dann siehst du zumindest schonmal, was da erfolgreich durch geht. Vllt. hilft dir das weiter.

     

    Beachte bitte, dass die die Regel nur für den aktiven Test einschaltest wegen dem vielen ANY und direkt wieder weg haust, wenn nicht mehr benötigt. ^^

     

    LG,

    Flo

  • 0 in reply to Florian Bartsch

    Hi nochmal,

     

    seh ich jetzt erst.

    Müsste in "Quelle ändern in" nicht ebenfalls das WAN Interface eingetragen sein wie in "Datenverkehrsziel"?

    LG,

    Flo

  • 0 in reply to Oliver Heinlein

    Florian, I wouldn't make those changes in the NAT rule.  See #4 and #5 in Rulz.

    Olivier, those drops mean that the connection tracker believes that the conversation with the phone has been concluded.  I suspect that there's a ip_conntrack_tcp_timeout_???? value to be set at the command line, but I'm not knowledgeable enough about the inner workings of TCP to know which one.

    Then again, do you have more than one WAN connection?

    MfG - Bob (Bitte auf Deutsch weiterhin.)

  • 0 in reply to BAlfson

    BAlfson said:

    Florian, I wouldn't make those changes in the NAT rule.  See #4 and #5 in Rulz.

     

    Hey Bob,

    ja, dass das zusätzliche Eintragen der Ports nicht sinnvoll ist und auch nicht ratsam ist habe ich mir schon gedacht.

    Allerdings hat genau das einmal bei uns ein ähnliches Problem gelöst, daher der Rat zu diesem "versuch".

     

    Ich hätte vllt. noch dazu erwähnen sollen, dass das so nicht gewollt ist und man es am Ende wieder zurückbauen sollte. :-)

     

    LG,

    Flo