Blockierende ACCEPT-VPN Regel

[geppi]

Ich habe ein VLAN (10.6.0.0/16 mit Tag 600) in dem ich einem Drucker erlauben möchte, Benachrichtigungen per SMTP an ein Mail-Relay im INTRANET (10.1.0.0/16 mit Tag 0) zu schicken.
Dazu habe ich eine Firewall Regel die entsprechende Pakete umetikettiert:

Code: Alles auswählen

/Setup/IP-Router/Firewall
> ls Rules

Name                              Prot.       Source                                    Destination                               Action                                    LB-Policy                         LB-Switchover  Linked      Prio   Firewall-Rule  Stateful  Src-Tag    Rtg-tag
==================================---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
....
ALLOW_SMTP_FROM_VLAN600           ANY         PRINTER                                   SMTP MAILSERVER                           ACCEPT                                                                      No             No          0      Yes            Yes       600        65535   
....

Das hatte bisher funktioniert, kommt aber neuerdings nicht mehr zum Tragen, weil jetzt die folgende ACCEPT-VPN Regel mit höherer Priorität die Pakete blockiert,

Code: Alles auswählen

/Setup/IP-Router/Firewall
> ls Rules

Name                              Prot.       Source                                    Destination                               Action                                    LB-Policy                         LB-Switchover  Linked      Prio   Firewall-Rule  Stateful  Src-Tag    Rtg-tag
==================================---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ALLOW-VPN-ROUTING                 ANY         ANYHOST                                   ANYHOST                                   ACCEPT-VPN                                0                                 No             No          1      Yes            Yes       0          0      
....

/Setup/IP-Router/Firewall
> ls Actions/

Name                              Description
==================================----------------------------------------------------------------
ACCEPT-VPN                        %Lcds0 @v %A

wie man am Trace sieht:

Code: Alles auswählen

[Firewall] 2023/03/28 20:18:39,193  Devicetime: 2023/03/28 20:18:39,410
Packet matched rule ALLOW-VPN-ROUTING
DstIP: 10.1.0.75, SrcIP: 10.6.0.20, Len: 60, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 25, SrcPort: 1042, Flags: S
Seq: 3987911761, Ack: 0, Win: 16384, Len: 0
Option: Maximum segment size = 1460
Option: NOP
Option: Window scale = 0 (multiply  by 1)
Option: NOP
Option: NOP
Option: 08 = 00 0c b9 4f 00 00 00 00

block-route for 10.1.0.75@600, packet rejected

Kann mir bitte jemand erklären warum eine bedingte ACCEPT Regel Pakete blockiert?

[Dr.Einstein]

Welche Routing Tabelle hat das Netzwerk 10.6.0.0/16 mit Tag 600, hat dies z.B. eine Default Route auf den VPN-Tunnel?

Die Lösung ist ja recht simpel, Priorität der ALLOW_SMTP_FROM_VLAN600 erhöhen. Schließlich ist diese genauer als die allgemeine VPN Regel.

[geppi]

Welche Routing Tabelle hat das Netzwerk 10.6.0.0/16 mit Tag 600, hat dies z.B. eine Default Route auf den VPN-Tunnel?

Code: Alles auswählen

> show ipv4-fib
IPv4 Unicast FIB
 Rtg-Tag 600

  Prefix             Next-Hop        Interface                 ID         Masquerading Redistribution Type (Distance)
  --------------------------------------------------------------------------------------------------------------------------
  0.0.0.0/0          0.0.0.0         O2-DSLITE                 13         no           Redistribute   Static (5)
  10.0.0.0/8         0.0.0.0         #Null                     0          no           Never          Static (5)
  10.6.0.0/16        0.0.0.0         DEVICES                   3          no           Redistribute   Connected LAN (2)
  10.6.0.1/32        0.0.0.0         #Loopback                 1          no           Redistribute   Local LAN (0)
  93.xxx.xxx.x/32    0.0.0.0         #Loopback                 1          no           Redistribute   Local WAN (0)
  127.0.0.0/8        0.0.0.0         #Loopback                 1          no           Never          Loopback (0)
  127.0.0.1/32       0.0.0.0         #Loopback                 1          no           Never          Loopback (0)
  172.16.0.0/12      0.0.0.0         #Null                     0          no           Never          Static (5)
  192.0.0.2/32       0.0.0.0         #Loopback                 1          no           Redistribute   Local WAN (0)
  192.168.0.0/16     0.0.0.0         #Null                     0          no           Never          Static (5)

Es besteht eigentlich keine aktive VPN-Verbindung. Die '93.xxx.xxx.x/32' ist die Addresse des zweiten WAN-Interface.

Die Lösung ist ja recht simpel, Priorität der ALLOW_SMTP_FROM_VLAN600 erhöhen. Schließlich ist diese genauer als die allgemeine VPN Regel.

Schon klar, aber ich würde das Verhalten gerne verstehen um in Zukunft nicht weitere Überraschungen zu erleben.

[backslash]

Hi geppi

Kann mir bitte jemand erklären warum eine bedingte ACCEPT Regel Pakete blockiert?

das bedingte ACCEPT blockiert nicht... Was blockiert ist, daß der Drucker in Tag 600 ist und die ALLOW-VPN-ROUTING nicht das Tag 0 (aka 65535) erzeingt. Dadurch findet der Routenlookuop im Kontext 600 die Sperr-Route

Code: Alles auswählen

 10.0.0.0/8         0.0.0.0         #Null                     0          no           Never          Static (5)

Da die Auswertung der Route VOR der Auswertung der Bedingung der Aktion erfolgt, wird das Paket verworfen..

Als Abhilfe muß du die Prio der Drucker-Regel passend erhöhen - mindestens auf die Prio der VPN-Regel.
Oder du deaktivierst die Sperr-Route

Gruß
Backslash

[geppi]

Da die Auswertung der Route VOR der Auswertung der Bedingung der Aktion erfolgt, wird das Paket verworfen..

Ahh, das ist der Knackpunkt. Danke!

[Hagen2000]

Ich habe eine sehr ähnliche Fragestellung, deshalb erlaube ich mir, diesen alten Thread hervorzuholen.
Ich möchte die Firewall-Regeln vereinfachen bzw. nicht benötigte entfernen und bin auf folgende Regel gestoßen:

Code: Alles auswählen

VPN-LAN-TO-LAN-ERLAUBEN           ANY         LOCALNET         LOCALNET         %Lcds0 @v %A               No             No          0      No             Yes       0          0        

Mein Kommentar "VPN-Zugriffe innerhalb des LANs erlauben" ergibt für mich keinen Sinn und insgesamt wüsste ich nicht, warum die explizit erlaubt werden müssten und daher habe ich die Regel deaktiviert.

Nun kann ein PC (den wir als Jump-Host benutzen) im lokalen Netz des Routers keine DNS-Anfragen mehr durchführen.
Ein trace # firewall liefert kein Ergebnis.
Ein trace # DNS hingegen liefert folgendes Ergebnis:

Code: Alles auswählen

[DNS] 2024/02/08 16:32:11,827
DNS Rx (INTRANET): Src-IP 10.0.1.161, RtgTag 0
Transaction ID: 0xdfee
Flags: 0x0100 (Standard query, No error)
Queries
  www.google.de: type A, class IN

STD A for www.google.de
Not found in local DNS database => forward to next server


[DNS] 2024/02/08 16:32:11,828 [info] :
query blocked by firewall rule VPN-PROTECT-LAN
 => refuse request from 10.0.1.161

Die Regel VPN-PROTECT-LAN ist eine Catch-All-Regel, falls über VPN ein nicht gewünschten Zugriff erfolgt und soll einen SNMP-Trap sowie eine E-Mail erzeugen. Die Regel schaut wie folgt aus:

Code: Alles auswählen

VPN-PROTECT-LAN                   ANY         ANYHOST           LOCALNET         %Lcds0 @v %R %M %N          No             No          0      Yes            Yes       0          0        

Warum greift diese Regel - sie soll durch nur bei einem Paket über VPN-Route greifen?
Und obwohl diese Regel greift, wird kein SNMP-Trap erzeugt und keine E-Mail verschickt. Beides funktioniert aber, wenn ich über VPN explizit eine unerwünschte Aktion auslöse, beispielsweise ping an eine nicht erlaubte Maschine.

Die Regel VPN-PROTECT-LAN dürfte doch nur greifen, wenn das Paket irgendwie mit VPN zu tun hat?
Die sonstige Internet-Konnektivität des PCs ist nicht beeinträchtigt, alles, was ohne DNS funktioniert, läuft auch.
Insbesondere bin ich zu diesem Zeitpunkt über eine Site-2-Site-VPN-Verbindung per Remote-Desktop auf dem PC eingeloggt.

Ich verstehe nicht was hier schief läuft und bräuchte Eure Tipps.

[backslash]

Hi Hagen2000,

das hat zwar rein gar nichts mit dem zu tun, was in diesem Thread behandelt wurde, aber ich antworte trotzdem mal hier...

Hier ist das Problem, daß irgendwann einmal ein Kunde unbedingt haben wollte, daß man den DNS-Traffic über Firewallregeln regulieren kann (wozu auch immer) - und dummerweise haben da die Projektmanager zugestimmt und daher hat man den Mist jezt in der Firewall drin...

Der Punkt ist, daß der DNS-Forwarder nicht so tief in die Regeln schaut (nicht schauen kann) wie bei dieser Regel nötig wäre, um zu erkennen, daß die gar nicht greifen soll (wegen der Bedingung "nur über VPN"). Hier mußt du am Ende eine Regel erstellen, die DNS explizit zuläßt, z.B.

Code: Alles auswählen

LAN-DNS-ERLAUBEN           DNS         LOCALNET         LOCALNET        %A               No             No          0      No             Yes       0          0       

hier reicht als Ziel tatsächlich "LOCALNET" aus, da der DNS-Forwarder das Paket prüft, bevor es weitergeleitet wird, d.h. da hat das Paket noch als Zieladresse die IP des LANCOMs (die kannst du i.Ü. natürlich auch als Ziel eintragen, wenn du nur ein LAN hast)

sauberer wären echte Inbound-Filter, so wie sie in der IPv6-Firewall existieren, dann wäre dieser krude Murks für das DNS nicht nötig...

Gruß
Backslash

[Hagen2000]

Hallo backslash,

Vielen Dank!
Ich dachte die ganze Zeit, dass das Paket irgendwie versehentlich mit dem Attribut VPN-Route versehen wird und es daher abgefangen wird.

Ich habe noch weitere Fragen zur Optimierung der Firewall-Regeln, aber dafür mach ich dann wirklich ein neues Thema auf.

[Hagen2000]

Dein Vorschlag enthielt leider zwei Fehler:

• DNS muss bei den Ziel-Diensten statt bei den Quell-Diensten angegeben werden
• Die Regel war nicht aktiv (das vorletzte "No" muss ein "Yes" sein)

Hier die korrekte Regel:

Code: Alles auswählen

LAN-DNS-ERLAUBEN                  ANY         LOCALNET       DNS LOCALNET        ACCEPT                        No             No          0      Yes            Yes       0          0

[backslash]

Hi Hagen2000

• DNS muss bei den Ziel-Diensten statt bei den Quell-Diensten angegeben werden

das sollten nicht die Quell-Dienste sein, sondern die Protokoll-Spalte (deshalb war da mehr als ein Leerzeichen zwischen). Der Parser "verschiebt" das intern dann automatisch in die Quell-Spalte...

• Die Regel war nicht aktiv (das vorletzte "No" muss ein "Yes" sein)

dann war deine Regel (VPN-LAN-TO-LAN-ERLAUBEN) auch schon falsch, denn ich hatte sie einfach als Vorlage genommen und die Protokoll- und die Aktions-Spalte angepaßt - ggf. hast du das auch einfach falsch gesehen, weil du dachtest DNS stünde in der Quell-Spalte...

Gruß
Backslash

[Hagen2000]

Hm, die Protokoll-Spalte listet bei mir Protokolle wie TCP, UDP und ICMP. Ist DNS nicht eine Schicht höher?
Vielleicht beziehen wir uns auch auf verschiedene Menüs. Ich habe die Ausgabe von

Code: Alles auswählen

ls /Setup/IP-Router/Firewall/Rules/

als Referenz genommen. Eine Protokoll-Spalte gibt es ja in der LANconfig-GUI nicht, dort kann ich nur Quell-Dienste oder Ziel-Dienste konfigurieren.

dann war deine Regel (VPN-LAN-TO-LAN-ERLAUBEN) auch schon falsch

Habe ich mir schon gedacht, dass Du da einfach Copy&Paste gemacht hast - meine Regel war deaktiviert, weil ja in dem Fall der Fehler auftrat.

[backslash]

Hi Hagen2000

Hm, die Protokoll-Spalte listet bei mir Protokolle wie TCP, UDP und ICMP. Ist DNS nicht eine Schicht höher?

im Prinzip ja, aber die Protokoll-Spalte akzeptiert auch "Objekte" mit Portangabe, z.B. "DNS", was gleichbedeutend mit "UDP %s53" ist
Sobald in der Protokollspalte etwas anderes als "ANY" steht (was ein leeres Objekt referenziert), wird das Objekt, das in der Protokollspalte steht, vom Parser quasi an die Zielpalte agehängt...

Eine Protokoll-Spalte gibt es ja in der LANconfig-GUI nicht, dort kann ich nur Quell-Dienste oder Ziel-Dienste konfigurieren.

richtig, siehe dazu auch fragen-zum-thema-firewall-f15/deny-all- ... ml#p116123

Gruß
Backslash