DNS-Forwarder landet in DENY_INTERNET

[JensK]

Liebe Spezies,

es geht um einen 1790VA mit LCOS 10.92RU3 in einem Homeoffice. Der Router hängt am lokalen LAN des Mitarbeiters (Gegenstelle INET_VIA_HO-LAN). Netze der Zentrale (192.168.21.0/24 und 192.168.21.0/24) werden via VPN (Gegenstelle ZENTRALE) geroutet, alles andere ist verboten. Clients im Homeoffice (192.168.130.16/28) nutzen den LANCOM-Router (192.168.130.17) als DNS-Server (per DHCP zugewiesen). DNS-Ziele der Windows-Domain sollen per Weiterleitung von einem Domaincontroller in der Zentrale beantwortet werden.

Der IKEv2-Tunnel zur Zentrale ist aktiv, Ziele in der Zentrale können vom Client aus erreicht werden. Leider scheint aber die Namensauflösung auf einem Windows-Client (192.168.130.19) nicht zu funktionieren:

Code: Alles auswählen

C:\>nslookup fileserver 192.168.130.17
Server:  homeoffice-gw.ad.my-domain.net
Address:  192.168.130.17

*** fileserver wurde von homeoffice-gw.ad.my-domain.net nicht gefunden: Query refused.

Der LANCOM-Trace zeigt folgendes:

Code: Alles auswählen

# Trace config
trace + IP-Router @ +"port: 53" +192.168.21.
trace + Firewall @ +"port: 53" +192.168.21.
trace + DNS
trace + IPv4-Host @ +53 +192.168.21.

[DNS] 2025/11/29 08:44:40,951  Devicetime: 2025/11/29 08:44:39,973
DNS Rx (INTRANET): Src-IP 192.168.130.19, RtgTag 0
Transaction ID: 0x0001
Flags: 0x0100 (Standard query, No error)
Queries
  17.130.168.192.in-addr.arpa: type PTR, class IN

STD PTR for 17.130.168.192.in-addr.arpa
Name resolved to homeoffice-gw.ad.my-domain.net

[DNS] 2025/11/29 08:44:40,951  Devicetime: 2025/11/29 08:44:39,981
DNS Rx (INTRANET): Src-IP 192.168.130.19, RtgTag 0
Transaction ID: 0x0002
Flags: 0x0100 (Standard query, No error)
Queries
  fileserver.ad.my-domain.net: type A, class IN

STD A for fileserver.ad.my-domain.net
DnsGetDest: Match found: forwarding fileserver.ad.my-domain.net to 192.168.21.5 192.168.21.2
Not found in local DNS database => forward to next server

[DNS] 2025/11/29 08:44:40,951  Devicetime: 2025/11/29 08:44:39,982 [info] : 
query blocked by firewall rule DENY_INTERNET
 => refuse request from 192.168.130.19

[DNS] 2025/11/29 08:44:40,951  Devicetime: 2025/11/29 08:44:39,984
DNS Rx (INTRANET): Src-IP 192.168.130.19, RtgTag 0
Transaction ID: 0x0003
Flags: 0x0100 (Standard query, No error)
Queries
  fileserver.ad.my-domain.net: type AAAA, class IN

STD AAAA for fileserver.ad.my-domain.net
DnsGetDest: Match found: forwarding fileserver.ad.my-domain.net to 192.168.21.5 192.168.21.2
Not found in local DNS database => forward to next server

[DNS] 2025/11/29 08:44:40,951  Devicetime: 2025/11/29 08:44:39,984 [info] : 
query blocked by firewall rule DENY_INTERNET
 => refuse request from 192.168.130.19

Was ich nicht verstehe: Warum landet die DNS-Anfrage in der DENY_INTERNET-Regel?
Diese Regel sollte doch nur greifen, wenn der Datenverkehr zum lokalen Internetzugang des Mitarbeiters geroutet wird.
Die Ziel-DNS-Server liegen jedoch im Netz der Zentrale, und laut Routing müsste die Anfrage über den VPN-Tunnel gehen.
Wo liegt hier mein Denkfehler bzw. warum wird die Anfrage trotzdem als "Internet-Ziel" klassifiziert?

Zum Verständnis hier noch ein Auszug aus der Konfig:

Code: Alles auswählen

set /Setup/Name "homeoffice-gw"

cd /Setup/WAN/DSL-Broadband-Peers 
add  "INET_VIA_HO-LAN" {SH-Time} 9999  {AC-name} ""  {Servicename} ""  {WAN-layer} "DHCPOE"  {ATM-VPI} 0  {ATM-VCI} 0  {MAC-Type} local  {user-def.-MAC} 000000000000  {DSL-ifc(s)} "DSL1"  {VLAN-ID} 0  {Prio-Mapping} off  {Prio-Value} 0  {S-VLAN-ID} 0  {IPv6} ""  {PPPoE-MTU-1500} No

cd /Setup/TCP-IP/Network-list 
add  "INTRANET"  {IP-Address} 192.168.130.17  {IP-Netmask} 255.255.255.240 {VLAN-ID} 0  {Interface} LAN-1  {Src-check} loose  {Type} Intranet {Rtg-tag} 0  {Comment} "local intranet"

cd /Setup/IP-Router/IP-Routing-Table 
add  192.168.20.0     255.255.255.0  0  0  {Peer-or-IP} "ZENTRALE"         {Distance} 0  {Masquerade} No  {Active} Yes  {Comment} ""
add  192.168.21.0     255.255.255.0  0  0  {Peer-or-IP} "ZENTRALE"         {Distance} 0  {Masquerade} No  {Active} Yes  {Comment} ""
add  192.168.0.0      255.255.0.0    0  0  {Peer-or-IP} "0.0.0.0"          {Distance} 0  {Masquerade} No  {Active} No   {Comment} "template: block private networks: 192.168.x.y"
add  172.16.0.0       255.240.0.0    0  0  {Peer-or-IP} "0.0.0.0"          {Distance} 0  {Masquerade} No  {Active} No   {Comment} "template: block private networks: 172.16-31.x.y"
add  10.0.0.0         255.0.0.0      0  0  {Peer-or-IP} "0.0.0.0"          {Distance} 0  {Masquerade} No  {Active} No   {Comment} "template: block private network: 10.x.y.z"
add  255.255.255.255  0.0.0.0        0  0  {Peer-or-IP} "INET_VIA_HO-LAN"  {Distance} 0  {Masquerade} on  {Active} Yes  {Comment} ""

cd /Setup/IP-Router/Firewall/Rules 
# nur diese zwei Regeln, keine weiteren:
add  "DENY_INTERNET"  {Prot.} "ANY"      {Source} "%LINTRANET"       {Destination} "%HINET_VIA_HO-LAN"  {Action} "INTERNET-FILTER"  {LB-Policy} ""  {LB-Switchover} No  {Linked} No  {Prio} 15  {Firewall-Rule} Yes  {Stateful} Yes  {Src-Tag} 0  {Rtg-tag} 0  {Comment} ""
add  "WINS"           {Prot.} "TCP UDP"  {Source} "NETBIOS ANYHOST"  {Destination} "ANYHOST"            {Action} "INTERNET-FILTER"  {LB-Policy} ""  {LB-Switchover} No  {Linked} No  {Prio} 0   {Firewall-Rule} Yes  {Stateful} Yes  {Src-Tag} 0  {Rtg-tag} 0  {Comment} "block NetBIOS/WINS name resolution via DNS"

cd /Setup/DHCP/Network-list 
add  "INTRANET"  {Start-Address-Pool} 0.0.0.0  {End-Address-Pool} 0.0.0.0  {Netmask} 0.0.0.0  {Broadcast-Address} 0.0.0.0  {Gateway-Address} 0.0.0.0  {DNS-Default} 0.0.0.0  {DNS-Backup} 0.0.0.0  {Operating} Yes  [...]

set /Setup/DNS/Resolve-Domain No
set /Setup/DNS/Domain "my-domain.net"
cd /Setup/DNS/Sub-Domains 
add  "INTRANET"  {Sub-Domain} "ad"
cd /Setup/DNS/DNS-Destinations 
add  "*.168.192.in-addr.arpa"  0  {Destination} "192.168.21.5 192.168.21.2"
add  "*.ad.my-domain.net"      0  {Destination} "192.168.21.5 192.168.21.2"
add  "ad.my-domain.net"        0  {Destination} "192.168.21.5 192.168.21.2"
add  "*.my-domain.net"         0  {Destination} "INET_VIA_HO-LAN"
add  "my-domain.net"           0  {Destination} "INET_VIA_HO-LAN"

cd /Setup/VPN/IKEv2/Peers 
add  "DEFAULT"   {Active} Yes  {SH-Time} 0     {Remote-Gateway} ""                        {Rtg-tag} 0  [...]  {IPv4-Rules} ""               
add  "ZENTRALE"  {Active} Yes  {SH-Time} 9999  {Remote-Gateway} "ZENTRALE.my-domain.net"  {Rtg-tag} 0  [...]  {IPv4-Rules} "HOMEOFFICE-RULE"

cd /Setup/VPN/Networks/IPv4-Rules 
add  "HOMEOFFICE-RULE"             {Local-Networks} "192.168.130.16/28"  {Remote-Networks} "192.168.20.0/24, 192.168.21.0/24"

Gruß, Jens

[Dr.Einstein]

Ist leider seit 10.42 so. Es wird seit grob 10 Jahren versprochen, die v4-Firewall auf v6-Niveau umzubauen, d.h. das die internen Dienste des Lancom ebenfalls via Firewall-Regeln gesteuert werden können. Leider landen aktuell nur Bruchteile in der v4-Firewall, sodass man das aktuelle Verhalten nicht verstehen kann. Im Referenzhandbuch ist davon nichts beschrieben. DNS ist so ein Sonderfall.

Für deinen Fall brauche du eine Regel Quelle LOCALNET auf Ziel 192.168.130.17. Einfach nicht hinterfragen und so hinnehmen.

[sixty]

Kann ich zu 100% bestätigen.
Teile lieber den 192.168.21.2 / 5 per DHCP direkt als DNS an die Clients aus, das wird vermutlich viele Probleme lösen.

[backslash]

Hi JensK,

das Problem ist, daß es im IPv5 keine Inbound-Filter gibt, man aber unbedingt eine Filterung möglich machen wollte, damit Die Anwender dazu gezwungen werden können, das LANCOM als DNS Server zu benutzen...
Zum Verständnis: die Abfrage in der Firewall erfolgt BEVOR das Forwarding gemacht wird, d.h. es spielt keine Rolle, daß das Weiterleitungsziel in der Zentrale steht, denn zum diesem Zeitpunkt hat die DNS-Anfrage als Zieladresse noch die des LANCOMs und matcht daher adreßmässig auf die Regel DENY_INTERNET (0.0.0.0/0)... (es werden nur die Adressen verglichen, die Interface-Info "INET_VIA_HO-LAN" wird hier nicht ausgewertet)

Du kannst z.B. eine Regel anlegen, die DNS von allen Netzen an die IP des LANCOM erlaubt:

Code: Alles auswählen

Name:    ALLOW-DNS:
Quelle:  alle Stationen  (ANYHOST)
Ziel:    alle Stationen im lokalen Netz (LOCALNET)
Dienste: Ziel-Dinst: DNS
Aktion:  ACCEPT

ggf. mußt du noch eine Prio setzen, so daß die Regel vor DENY_INTERNET steht

Gruß
Backslash

[Dr.Einstein]

das Problem ist, daß es im IPv5 keine Inbound-Filter gibt, man aber unbedingt eine Filterung möglich machen wollte, damit Die Anwender dazu gezwungen werden können, das LANCOM als DNS Server zu benutzen...

Ergibt die Aussage wirklich Sinn? Eine DENY-All Regel würde im klassischen v4 Sinne bedeuten, dass alle externen DNS-Server nicht erlaubt wären, der Lancom als Ziel aber schon. Die Anpassung der 10.42 verhindert aber bei einer DENY-All-Regel die Kommunikation zur Lancom IP (DNS Dienst) selbst. Das ist also eigentlich nicht das, was du beschrieben hast. Wenn es darum ging, ab 10.42 den Lancom DNS von bestimmten Netzen zu verhindern, okay. Dann hätte man das neue DNS Feature der 10.94 aber dahingehend anpassen können. Nun hat man noch mehr Chaos im LCOS, dass niemand mehr versteht.

[backslash]

Hi Dr.Einstein,

Ergibt die Aussage wirklich Sinn? Eine DENY-All Regel würde im klassischen v4 Sinne bedeuten, dass alle externen DNS-Server nicht erlaubt wären, der Lancom als Ziel aber schon.

Nein, eine DENY-ALL-Regel verbietet sowohl die Nutzung externer DNS server als auch die Nutzung das DNS-Forwarders im LANCOM. , d.h. wenn du nur eine Deny-All Regel hast, dann ist DNS-Forwarding in jedem Fall verboten - und das ist nicht erst seit der 10.42 so. Die Sonderlocke für DNS wurde schon zu ELSA-zeiten eingebaut. Sobald du eine ALLOW-DNS-Regel hast, die vor der DENY-ALL-Regel steht, dann ist DNS erlaubt - und du kannst in der Zielspalte noch angeben, welche Adresse der DNS-Server haben muß, den der Clinet anspricht - also NICHT wohin das LANCOM vielleicht weiterleitet.

Über die Sinnhaftigkeit, daß lokale DNS-Auflösungen trotz Deny-All-Filter noch funktionieren, kann man nun trefflich streiten - hier kann dann argumentiert werden, daß eine lokale Auflösung kein Forwarding ist und die IPv4-Firewall nur Forwarding-Regeln hat...


Gruß
Backslash

[JensK]

Hallo zusammen,

vielen Dank für die Lösung und die Erklärungen dazu. Mit der zusätzlichen Regel funktioniert es wie gewünscht - allein wäre ich wohl nicht so schnell darauf gekommen.

Viele Grüße
Jens