TL;DR: Mein 1781VA hat 2 Netze die per VLAN und Routing-Tag voneinander getrennt sind. Das LANCOM ist sowohl DHCP Server als auch DNS Server für beide Netze. Ich möchte die DHCP-Hostnamen der Netze aus dem jeweils anderen Netz per DNS auflösen können. Dies gelingt mir nicht: "Request filtered".
Jetzt habe ich etwa sechs Stunden investiert und finde alleine keine Lösung. Daher würde ich mich sehr freuen wenn mir jemand Tipps geben kann!
Details:
Dieser Beitrag schildert ein sehr ähnliches Problem, aber leider lassen die Beteiligen die Lösung offen -- falls es eine gibt. Anders als dort verwende ich zusätzlich auch verschiedene VLANs, allerdings behaupte ich dass das keinen Unterschied macht.
Ich beschreibe mein Setup am Besten durch Auszüge aus der Konfiguration:
Code: Alles auswählen
#
| LANCOM 1781VA (over ISDN)
| Ver. 10.50.0608 / 18.01.2022
> l /Setup/TCP-IP/Network-list/
Network-name IP-Address IP-Netmask VLAN-ID Interface Src-check Type Rtg-tag Comment
==================--------------------------------------------------------------------------------------------------------
FRUITS 192.168.16.11 255.255.255.0 16 LAN-1 loose Intranet 16
CLABEKI 192.168.22.11 255.255.255.0 22 LAN-1 loose Intranet 22
> l /Setup/IPv6/LAN-Interfaces/
Interface-Name Interface-ID VLAN-ID Rtg-tag Autoconf Accept-RA Interface-Status Forwarding MTU Firewall DaD-Attempts RS-Count Comment
==================---------------------------------------------------------------------------------------------------------------------------------------------------
CLABEKI LAN-1 22 22 Yes Yes Up Yes 1500 No 1 3
> l /Setup/DHCP/Network-list/
Network-name Start-Address-Pool End-Address-Pool Netmask Broadcast-Address Gateway-Address DNS-Default DNS-Backup NBNS-Default NBNS-Backup Operating Broadcast-Bit Master-Server 2nd-Master-Server 3rd-Master-Server 4th-Master-Server Loopback-Address Cache Adaption Cluster Max.-Lease Def.-Lease Suppress-ARP-check
==================-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
FRUITS 192.168.16.100 192.168.16.199 255.255.255.0 192.168.16.255 192.168.16.11 192.168.16.11 0.0.0.0 0.0.0.0 0.0.0.0 Yes No 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 No No No 0 0 No
CLABEKI 192.168.22.150 192.168.22.199 255.255.255.0 192.168.22.255 192.168.22.11 192.168.22.11 192.168.15.3 0.0.0.0 0.0.0.0 Yes No 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 No No No 0 0 No
> l /Setup/DHCP/DHCP-Table/
IP-Address MAC-Address Timeout Hostname Type LAN-Ifc Ethernet-Port VLAN-ID Network-name Assignment
=================-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
192.168.16.110 d8f15b845582 484 apple dyn. LAN-1 ETH-1 16 FRUITS 01/30/2022 10:40:51
192.168.22.177 20c6eb4ff20d 457 DIGA dyn. LAN-1 ETH-1 22 CLABEKI 01/30/2022 10:19:56
[...]
> l /Setup/DNS/Sub-Domains/
Network-name Sub-Domain
==================----------
FRUITS fruits
> l /Setup/DNS/Tag-Configuration/
Rtg-tag Operating Forwarder DHCP-Usage NetBIOS-Usage Resolve-Domain
=========----------------------------------------------------------------------
22 Yes Yes Yes No No
16 Yes No Yes No No
> l /Setup/DNS/
Operating VALUE: Yes
Forwarder VALUE: Yes
DHCP-Usage VALUE: Yes
NetBIOS-Usage VALUE: No
Resolve-Domain VALUE: No
Domain VALUE: bkirchen.de
[...]
Code: Alles auswählen
# von 192.168.22.10
$ dig diga.bkirchen.de A @192.168.22.11
; <<>> DiG 9.16.22-Debian <<>> diga.bkirchen.de A @192.168.22.11
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22069
;; flags: qr aa rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;diga.bkirchen.de. IN A
;; ANSWER SECTION:
diga.bkirchen.de. 60 IN A 192.168.22.177
;; Query time: 0 msec
;; SERVER: 192.168.22.11#53(192.168.22.11)
;; WHEN: Sun Jan 30 11:02:56 CET 2022
;; MSG SIZE rcvd: 50
[DNS] 2022/01/30 11:04:18,110
DNS Rx (CLABEKI): Src-IP 192.168.22.10, RtgTag 22
Transaction ID: 0xd0b5
Flags: 0x0120 (Standard query, No error)
Queries
diga.bkirchen.de: type A, class IN
Additional records
<Root>: type OPT
STD A for diga.bkirchen.de
Address resolved to 192.168.22.177
Code: Alles auswählen
# von 192.168.16.140
$ dig apple.fruits.bkirchen.de A @192.168.16.11
; <<>> DiG 9.16.22-Debian <<>> apple.fruits.bkirchen.de A @192.168.16.11
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32412
;; flags: qr aa rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;apple.fruits.bkirchen.de. IN A
;; ANSWER SECTION:
apple.fruits.bkirchen.de. 60 IN A 192.168.16.110
;; Query time: 3 msec
;; SERVER: 192.168.16.11#53(192.168.16.11)
;; WHEN: Sun Jan 30 11:08:27 CET 2022
;; MSG SIZE rcvd: 58
[DNS] 2022/01/30 11:13:18,422
DNS Rx (FRUITS): Src-IP 192.168.16.140, RtgTag 16
Transaction ID: 0x05a2
Flags: 0x0120 (Standard query, No error)
Queries
apple.fruits.bkirchen.de: type A, class IN
Additional records
<Root>: type OPT
STD A for apple.fruits.bkirchen.de
Address resolved to 192.168.16.110
Code: Alles auswählen
# von 192.168.22.10
$ dig apple.fruits.bkirchen.de A @192.168.22.11
; <<>> DiG 9.16.22-Debian <<>> apple.fruits.bkirchen.de A @192.168.22.11
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 2456
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: addef0b9390e9a51 (echoed)
;; QUESTION SECTION:
;apple.fruits.bkirchen.de. IN A
;; Query time: 0 msec
;; SERVER: 192.168.22.11#53(192.168.22.11)
;; WHEN: Sun Jan 30 11:14:37 CET 2022
;; MSG SIZE rcvd: 65
[DNS] 2022/01/30 11:14:37,493
DNS Rx (CLABEKI): Src-IP 192.168.22.10, RtgTag 22
Transaction ID: 0x0998
Flags: 0x0120 (Standard query, No error)
Queries
apple.fruits.bkirchen.de: type A, class IN
Additional records
<Root>: type OPT
STD A for apple.fruits.bkirchen.de
Request filtered
Code: Alles auswählen
# von 192.168.16.140
$ dig diga.bkirchen.de A @192.168.16.11
; <<>> DiG 9.16.22-Debian <<>> diga.bkirchen.de A @192.168.16.11
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 3021
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: e09ee8b3d6009914 (echoed)
;; QUESTION SECTION:
;diga.bkirchen.de. IN A
;; Query time: 3 msec
;; SERVER: 192.168.16.11#53(192.168.16.11)
;; WHEN: Sun Jan 30 11:11:56 CET 2022
;; MSG SIZE rcvd: 57
[DNS] 2022/01/30 11:44:08,726
DNS Rx (FRUITS): Src-IP 192.168.16.140, RtgTag 16
Transaction ID: 0xfa1d
Flags: 0x0120 (Standard query, No error)
Queries
diga.bkirchen.de: type A, class IN
Additional records
<Root>: type OPT
STD A for diga.bkirchen.de
Request filtered
- DNS-Weiterleitung: Das ist hier keine Lösung, selbst mit "@"-Magie nicht, weil eine Weiterleitung an eine Loopback-Adresse grundsätzlich unterbunden wird: "send to transport failed: invalid interface #Loopback". Das LANCOM selbst muss aber die DNS-Anfrage beantworten und jede seine Adressen wird als loopback entlarvt.
- Pakete per Firewall umtaggen: Obwohl ich mir praktisch sicher bin, dass die Regel greift, reicht ein umtaggen von Paketen nicht aus. Meine Regel sollte funktionieren weil ich das Netz 192.168.16.0/24 mit der Regel aktiviert erreichen kann von 192.168.22.10, aber ohne die Regel nicht. Trotzdem sehe ich im DNS-Trace dass die Anfrage an den DNS-Server das Tag 22 hat, wie oben. Firewall-Regel: Hat das vielleicht damit zu tun, das kein Routing stattfindet und deshalb die Firewall hier keine Rolle spielt? Ändere ich die Action in "DROP" kommt meine Anfrage nämlich trotzdem beim LANCOM an und auch der Firewall-Trace bleibt stumm. Meine Vermutung scheint korrekt zu sein: https://www.lancom-systems.de/docs/LCOS ... 64962.html. Ich wusste nicht dass man interne Dienste nicht per IPv4-Firewall schützen kan...
Code: Alles auswählen
> l /Setup/IP-Router/Firewall/Rules/FRUITS-DNS Name Prot. Source Destination Action LB-Policy LB-Switchover Linked Prio Firewall-Rule VPN-Rule Stateful Src-Tag Rtg-tag Comment ==================================-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- FRUITS-DNS ANY %A192.168.22.10 ANYHOST ACCEPT No No 10 Yes No Yes 22 16 - DNS-Abfrage des LANCOMS an seiner Adresse 192.168.16.11: Das funktioniert nur mit entsprechender Firewall-Regel, andernfalls gibts ein Timeout. Gibt es aber die passende Firewall-Regel, reagiert das LANCOM wieder mit "Request filtered". Das muss damit zu tun haben dass die Anfrage trotzdem von 192.168.22.10 Tag 22 kommt, also nicht auf dem 16er Netz.
- Zusätzlich umtaggen in der IPv6 Firewall: Keine Veränderung.
- Eine Route vom 22er Netz ins 16er Netz eingetragen in der IPv4 Routing-Tabelle fürs Tag 22: Keine Veränderung.
- Ich kann das 22er Netz testweise mit dem Rtg-Tag 0 versehen, dann kommt es auch mit diesem Tag am DNS-Server an wie ich im Trace erkenne und die Anfrage wird beantwortet. Leider ist das aber keine Lösung, das 22er Netz soll weiterhin mit 22 getaggt sein.
Gruß,
Bernhard
Du hast den Nagel jedenfalls auf den Kopf getroffen und meine erste Nachbesserung in der Firewallregel hat sofort das gewünschte Ergebnis erziehlt.