DNS Proxy listen to broadcast?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

DNS Proxy listen to broadcast?

L2 Linker

Hello!
I have a cisco wlan accesspoint (at remote site), which lost connection to central wlan-controller. Due to a mistake this ap still has static ip-address, so it does not send DHCP-discover/requests when it is started. But it sends DNS-requests searching for "cisco-capwap-controller". So I thought it might help to configure a DNS-proxy on the Palo Alto with static DNS entry "cisco-capwap-controller". Unfortunately the cisco ap sends its DNS-requests to broadcast-address 255.255.255.255. And this is dropped, even when firewall-rule with destination any (allowed) is used.
Is there a change to force Palo Alto to reply to the DNS-requests?
Thanks.

1 accepted solution

Accepted Solutions

Another problem was, that the AP could not be located at the remote site.
But I could solve it with a nice little tool "AbateDNS". This replies to DNS-requests with a configured ip address. It even replies to broadcast-DNS. I only had to move a pc into the AP-VLAN. Then started the tool. The DNS-request-broadcast from Cisco-AP asking for "CISCO-CAPWAP-CONTROLLER" was seen and it replied with the configured ip address (WLC ip address).
Then AP knew the WLC and joined it. 20210401_abatedns_capwap1.jpg

View solution in original post

7 REPLIES 7

L6 Presenter

You may test with static arp entries like the examples below but they use network directed broadcast and not 255.255.255.255 so just test if it will work as I haven't done this myself with 255.255.255.255:

 

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000boLYCAY&lang=en_US%E2%80%A...

 

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Clq3CAC

 

 

The Cisco Access points also use DHCP and the option 43 for controller discovery, so maybe it is better to set the Palo Alto as the DHCP server or DHCP Relay (it is supported) than using DNS.

 

 

https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/networking/dhcp/dhcp-options/dhcp-options-...

Cyber Elite
Cyber Elite

@ChrisCon,

I would recommend just setting up DHCP option 43 for the access points on these remote offices like @nikoolayy1 already mentioned. That's the actual process Cisco is expecting you to use in these type of scenarios. 

L6 Presenter

Please test and tell us the results and mark the Discussion as closed if you managed to resolve it.

Thanks for reply, but it did not help in my case.
But static arp was a good hint for future.

Yes of course option 43  is the best way.

But unfortunately the accesspoint was reset with "clear config except static ip". So it kept static ip address and does not send DHCP-discover/request now.

 

Except if the static arp does not help to use a vWire if possible I think maybe somone must go and again clear the config but this time without "except static ip". Share how you solved this problem after this, if possible.

Another problem was, that the AP could not be located at the remote site.
But I could solve it with a nice little tool "AbateDNS". This replies to DNS-requests with a configured ip address. It even replies to broadcast-DNS. I only had to move a pc into the AP-VLAN. Then started the tool. The DNS-request-broadcast from Cisco-AP asking for "CISCO-CAPWAP-CONTROLLER" was seen and it replied with the configured ip address (WLC ip address).
Then AP knew the WLC and joined it. 20210401_abatedns_capwap1.jpg

  • 1 accepted solution
  • 4244 Views
  • 7 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!