2
Access point kann DNS nicht auflösen (monowall)
Hallo zusammen
folgendes Szenario:
Ich arbeite auf einem physikalischen Server virtuell. Dies bedeutet folgendes: Am physikalischen Server sind physikalisch vier Netzwerkkarten angeschlossen, aber nur zwei im Betrieb, ich brauche auch nicht mehr. An einer Schnittstelle (vm01) hängt mein Access Point. An der Anderen Schnittstelle gehts zu einem Router (physikalisch), der mich ins WAN routet.
Folgende virtuelle Maschinen und Netze sind vorhanden:
Einen Windows Server 2008 R2 am "LAN" angeschlossen. Das"LAN" ist virtuell. Der Server funktioniert als ADDC mit DHCP und an ihm ist ein windows XP-CLient angeschlossen. Dieses "LAN" hat den Adressbereich: 172.16.2.0 /24. Der Server hat die Adresse: 172.16.2.3, der XP-Client bekommt per DHCP eine Adresse.
Nun habe ich auch eine M0n0wall virtuell. Die einzigen beiden Anschlüsse, die da nicht virtuell sind, sind WAN und DMZ. Das WAN ist an 10.44.9.0 angeschlossen (GW: 10.44.9.1). Die DMZ hat zwei IP-Adressen. Einmal 172.16.3.0/24 und 172.16.4.0/24. Nun habe ich an der physikalischen Schnittstelle, wie bereits beschrieben, meinen Accesspoint angeschlossen. Nun bekomme ich jedes Mal auf dem Access Point die Fehlermeldung: "CAPWAP-3-ERRORLOG: Could not resolve CISCO-LWAPP-CONTROLLER.evelyn.local"
(evelyn.local ist der DNS-Suffix meines ADDC!)
Ausserdem erhalte ich zusätzlich eine Fehlermeldung:
"CAPWAP-5-DHCP_RENEW: Could not discover WLC using DHCP IP. Renewing DHCP IP"
Allerdings bezieht er sich vom DHCP-Server eine Adresse:
"DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0 assign DHCP address 172.16.3.19 mask 255.255.255.0, hostname AP000c.3062.21f6"
In der m0n0wall habe ich ein DHCP Relay eingerichtet und ich habe im ADDC einen scope mit 172.16.3.0/24 und einen mit 172.16.4.0/24 eingerichtet, da das die zweite Adresse des DMZ ist. Ich habe auch eine reverse lookupzone für beide Sopes eingerichtet.
Falls ich irgendetwas vergessen habe zu erwähnen, oder ihr einen Fehler seht, sdagt es mir bitte. Ich wäre um LÖSUNGSVORSCHLÄGE sehr froh, vielen Dank.
folgendes Szenario:
Ich arbeite auf einem physikalischen Server virtuell. Dies bedeutet folgendes: Am physikalischen Server sind physikalisch vier Netzwerkkarten angeschlossen, aber nur zwei im Betrieb, ich brauche auch nicht mehr. An einer Schnittstelle (vm01) hängt mein Access Point. An der Anderen Schnittstelle gehts zu einem Router (physikalisch), der mich ins WAN routet.
Folgende virtuelle Maschinen und Netze sind vorhanden:
Einen Windows Server 2008 R2 am "LAN" angeschlossen. Das"LAN" ist virtuell. Der Server funktioniert als ADDC mit DHCP und an ihm ist ein windows XP-CLient angeschlossen. Dieses "LAN" hat den Adressbereich: 172.16.2.0 /24. Der Server hat die Adresse: 172.16.2.3, der XP-Client bekommt per DHCP eine Adresse.
Nun habe ich auch eine M0n0wall virtuell. Die einzigen beiden Anschlüsse, die da nicht virtuell sind, sind WAN und DMZ. Das WAN ist an 10.44.9.0 angeschlossen (GW: 10.44.9.1). Die DMZ hat zwei IP-Adressen. Einmal 172.16.3.0/24 und 172.16.4.0/24. Nun habe ich an der physikalischen Schnittstelle, wie bereits beschrieben, meinen Accesspoint angeschlossen. Nun bekomme ich jedes Mal auf dem Access Point die Fehlermeldung: "CAPWAP-3-ERRORLOG: Could not resolve CISCO-LWAPP-CONTROLLER.evelyn.local"
(evelyn.local ist der DNS-Suffix meines ADDC!)
Ausserdem erhalte ich zusätzlich eine Fehlermeldung:
"CAPWAP-5-DHCP_RENEW: Could not discover WLC using DHCP IP. Renewing DHCP IP"
Allerdings bezieht er sich vom DHCP-Server eine Adresse:
"DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0 assign DHCP address 172.16.3.19 mask 255.255.255.0, hostname AP000c.3062.21f6"
In der m0n0wall habe ich ein DHCP Relay eingerichtet und ich habe im ADDC einen scope mit 172.16.3.0/24 und einen mit 172.16.4.0/24 eingerichtet, da das die zweite Adresse des DMZ ist. Ich habe auch eine reverse lookupzone für beide Sopes eingerichtet.
Falls ich irgendetwas vergessen habe zu erwähnen, oder ihr einen Fehler seht, sdagt es mir bitte. Ich wäre um LÖSUNGSVORSCHLÄGE sehr froh, vielen Dank.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 186462
Url: https://administrator.de/contentid/186462
Printed on: April 23, 2024 at 23:04 o'clock
2 Comments
Latest comment
Capwap ist ein Protocol für die Verwaltung von Controller basierten WLANs.
http://en.wikipedia.org/wiki/CAPWAP
APs "sprechen" also mit dem Controller über CapWAP, deshalb kannst du sofern du einen stand alone AP benutzt diese Meldungen völlig ignorieren. Sie haben rein gar nichts mit deinem Szenario zu tun. Der AP "sucht" lediglich den Controller mehr nicht.
Du solltest in jedem Falle den Controller Betrieb ausschalten wenn du den AP im Standalone Modus nutzt.
Nebenbei: Ein WLAN Accesspoint arbeitet immer als reine Layer 2 Bridge, folglich ist ein DNS Server für den AP in Bezug auf die WLAN Client Kommunikation vollkommen irrelevant, denn als Bridge ist er daher nie in die Kommunikation seiner WLAN Clients involviert. Er bridged deren Pakete nur rein auf Layer 2 Basis mit deren Mac Adressen.
Dein AP ist isoliert vom Controller und deshalb "schreit" der verzeifelt via Capwap Protokoll bzw. DNS nach einem Controller der CISCO-LWAPP-CONTROLLER.evelyn.local heisst um dessen IP Adresse via DNS zu erfahren. (Nebenbei: .local sollte man niemals im lokalen DNS verwenden denn das ist reserviert für mDNS ! Besser also immer .test oder .intern als Rott Domains intern verwenden um einen mDNS Konflikt zu vermeiden !!
DNS benötigt er also nur um seinen Controller zu finden sonst für nix. Das ist auch normal für Controller basierte APs wenn die keinen lokalen Controller im LAN Segment finden. Dann gehen sie davon aus das sie hinter einem Router hängen und versuchen die Controller IP dann mit einem DNS request aufzulösen...genau das also was baie dir passiert !
Das kannst du aber wie gesagt alles vergessen für deinen Betrieb und diese Fehlermeldungen ignorieren ! Bzw. sie verschwinden auch wenn der AP Standalone macht !
Sofern du natürlich zwingend den Controller brauchst musst du dafür soregn das der AP per DHCP einen DNS Server bekommt und die DNS Adresse CISCO-LWAPP-CONTROLLER.evelyn.local aufgelöst werden kann....klar !
(P.S.: Hinter Kathy verbirgt sich also Evelyn
Wenigstens kein "Evelyno"... )
http://en.wikipedia.org/wiki/CAPWAP
APs "sprechen" also mit dem Controller über CapWAP, deshalb kannst du sofern du einen stand alone AP benutzt diese Meldungen völlig ignorieren. Sie haben rein gar nichts mit deinem Szenario zu tun. Der AP "sucht" lediglich den Controller mehr nicht.
Du solltest in jedem Falle den Controller Betrieb ausschalten wenn du den AP im Standalone Modus nutzt.
Nebenbei: Ein WLAN Accesspoint arbeitet immer als reine Layer 2 Bridge, folglich ist ein DNS Server für den AP in Bezug auf die WLAN Client Kommunikation vollkommen irrelevant, denn als Bridge ist er daher nie in die Kommunikation seiner WLAN Clients involviert. Er bridged deren Pakete nur rein auf Layer 2 Basis mit deren Mac Adressen.
Dein AP ist isoliert vom Controller und deshalb "schreit" der verzeifelt via Capwap Protokoll bzw. DNS nach einem Controller der CISCO-LWAPP-CONTROLLER.evelyn.local heisst um dessen IP Adresse via DNS zu erfahren. (Nebenbei: .local sollte man niemals im lokalen DNS verwenden denn das ist reserviert für mDNS ! Besser also immer .test oder .intern als Rott Domains intern verwenden um einen mDNS Konflikt zu vermeiden !!
DNS benötigt er also nur um seinen Controller zu finden sonst für nix. Das ist auch normal für Controller basierte APs wenn die keinen lokalen Controller im LAN Segment finden. Dann gehen sie davon aus das sie hinter einem Router hängen und versuchen die Controller IP dann mit einem DNS request aufzulösen...genau das also was baie dir passiert !
Das kannst du aber wie gesagt alles vergessen für deinen Betrieb und diese Fehlermeldungen ignorieren ! Bzw. sie verschwinden auch wenn der AP Standalone macht !
Sofern du natürlich zwingend den Controller brauchst musst du dafür soregn das der AP per DHCP einen DNS Server bekommt und die DNS Adresse CISCO-LWAPP-CONTROLLER.evelyn.local aufgelöst werden kann....klar !
(P.S.: Hinter Kathy verbirgt sich also Evelyn
Wenigstens kein "Evelyno"... )
Hoppla, ja, das ist mein Name^^
Danke, für deine Antwort. Die Kommunikation zwischen den Netzen funktioniert zwar immer noch nicht ganz einwandfrei, aber das krieg ich schon hin, sonst melde ich mich wieder.
Danke.
Danke, für deine Antwort. Die Kommunikation zwischen den Netzen funktioniert zwar immer noch nicht ganz einwandfrei, aber das krieg ich schon hin, sonst melde ich mich wieder.
Danke.
