Business Community > WiFi > Omada controller avoid broadcasting as IPs are fix and known
< WiFi

Omada controller avoid broadcasting as IPs are fix and known

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
12

Omada controller avoid broadcasting as IPs are fix and known

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Omada controller avoid broadcasting as IPs are fix and known
Omada controller avoid broadcasting as IPs are fix and known
2018-06-03 15:12:25
Model : EAP 224 AC1350 + Omada Controller v2.6.0 (windows)

Hardware Version : v3.0

Firmware Version : 2.2.0

ISP :

I have a remote network with several eap225s and everything set up correctly and work perfectly.In addition I have a working vpn connection to this remote network, but vpn cannot transport broadcast messages and there is no option to change the vpn manager or connect a dedicated device to remote network just for eap management. Omade controller does not show any device if I'm connected to this network (same subnet).Is there a way to modify Omada controller not to use broadcast messages, all my eaps using well known and fixed ip addresses. If yes than I can manage eaps remotely over restricted vpn.If not, than do you have any suggestion to manage eaps centralized without broadcast messages?Thanks
  0      
 
  0      
 
#1
Options
12 Reply
Re:Omada controller avoid broadcasting as IPs are fix and known
2018-06-04 00:15:26

benyovszky wrote

Is there a way to modify Omada controller not to use broadcast messages, all my eaps using well known and fixed ip addresses. If yes than I can manage eaps remotely over restricted vpn.If not, than do you have any suggestion to manage eaps centralized without broadcast messages?Thanks


If you use the EAP Discovery utility to manually connect EAPs with the Controller, you can connect EAPs to a Controller running elsewhere.
༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#2
Options
Re:Omada controller avoid broadcasting as IPs are fix and known
2018-06-04 00:21:40
EAP Discovery utility uses broadcast as well, so it does not see the EAPs as well. My Omade Controller has seen the devices once when I was connected directly, so they are on the disconnected list, but still it would like to be broadcasting first.
  0  
  0  
#3
Options
Re:Omada controller avoid broadcasting as IPs are fix and known
2018-06-04 02:19:41

benyovszky wrote

EAP Discovery utility uses broadcast as well, so it does not see the EAPs as well. My Omade Controller has seen the devices once when I was connected directly, so they are on the disconnected list, but still it would like to be broadcasting first.


That's correct, the EAP Discovery Utility uses broadcasts as well and therefore has to run (once! for discovery only!) inside the network where the EAPs are located. But the Controller can run elsewhere, even in another subnet (I do this all the time running the Controller on servers in separate networks).

If you can't run the Discovery Utility locally, you have the choice of using DHCP option 138 (CAPWAP) to let EAPs discover the Controller's IP. Just propagate the IP of the Controller through DHCP. But EAPs need to be set to dynamic addressing mode to ensure they will examine DHCP option 138. If you need static IP assignments for the EAPs, those IPs could then be defined in the DHCP server as well.
༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#4
Options
Re:Omada controller avoid broadcasting as IPs are fix and known
2018-06-04 02:51:13

R1D2 wrote

That's correct, the EAP Discovery Utility uses broadcasts as well and therefore has to run (once! for discovery only!) inside the network where the EAPs are located. But the Controller can run elsewhere, even in another subnet (I do this all the time running the Controller on servers in separate networks).

If you can't run the Discovery Utility locally, you have the choice of using DHCP option 138 (CAPWAP) to let EAPs discover the Controller's IP. Just propagate the IP of the Controller through DHCP. But EAPs need to be set to dynamic addressing mode to ensure they will examine DHCP option 138. If you need static IP assignments for the EAPs, those IPs could then be defined in the DHCP server as well.


That way is really promising, thank you. Currently I'm using the router's dhcp server where I do not have any option to set option 138. BTW if I get to the site and connect directly to the network and restart all devices and they find my laptop as a controller (via broadcast), then I move back to my normal location and connect to the network via VPN and get the same IP address, than Omada should be work remotely until the devices are powered on? Is that a method for bypassing dhcp option 138 advertisement?
  0  
  0  
#5
Options
Re:Omada controller avoid broadcasting as IPs are fix and known
2018-06-04 03:03:47

benyovszky wrote

BTW if I get to the site and connect directly to the network and restart all devices and they find my laptop as a controller (via broadcast), then I move back to my normal location and connect to the network via VPN and get the same IP address, than Omada should be work remotely until the devices are powered on?


Yes, that should work, too. Discovery just stores the IP of the Controller into the EAP's flash memory.
༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#6
Options
Re:Omada controller avoid broadcasting as IPs are fix and known
2018-06-04 03:25:41

R1D2 wrote

Yes, that should work, too. Discovery just stores the IP of the Controller into the EAP's flash memory.


So I need a stable power solution... :) Great! Thank you!

Is the MAC address is also important (hint: VPN vs physical adapter) or just IP address? I took a try now and set my VPN IP address to the one what I had when I was on site, but no device showed up yet. I'm not sure if there was a power cut or not. How often do EAPs communicate to the controller?
Thank for your support!
  0  
  0  
#7
Options
Re:Omada controller avoid broadcasting as IPs are fix and known
2018-06-04 05:59:16

benyovszky wrote

Is the MAC address is also important (hint: VPN vs physical adapter) or just IP address?


Just the IP address.

I took a try now and set my VPN IP address to the one what I had when I was on site, but no device showed up yet.


I don't know the type of VPN you use, but if it connects two physical parts of the same network, each device should be reachable by every other device. Maybe some ports need to be opened on your VPN router's firewall (if you have one)?

How often do EAPs communicate to the controller?


Didn't measure it yet, but if I start a Controller, it lasts not long (about 30 secs) until EAPs show up.
༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#8
Options
Re:Omada controller avoid broadcasting as IPs are fix and known
2018-06-04 13:51:49

R1D2 wrote

Just the IP address.


Perfect, thank you!

I don't know the type of VPN you use, but if it connects two physical parts of the same network, each device should be reachable by every other device. Maybe some ports need to be opened on your VPN router's firewall (if you have one)?


I use a router from a different manufacturer. This device supports openvpn in tunnel mode (no tap) or ipsec as client-to-gateway but it does not transfer broadcast messages and I cannot find yet how to apply (or controll) routing between management subnet and vpn subnet. It has ugly and very limited web interface, no dhcp options etc.

Didn't measure it yet, but if I start a Controller, it lasts not long (about 30 secs) until EAPs show up.


Nice to hear, thank you!
  0  
  0  
#9
Options
Re:Omada controller avoid broadcasting as IPs are fix and known
2018-06-04 16:37:46

benyovszky wrote

I use a router from a different manufacturer. This device supports openvpn in tunnel mode (no tap) or ipsec as client-to-gateway but it does not transfer broadcast messages and I cannot find yet how to apply (or controll) routing between management subnet and vpn subnet. It has ugly and very limited web interface, no dhcp options etc.


Ah, I see.

Solution is to run OpenVPN in client-to-client mode and make sure to bridge the interfaces (no routing!). Additionally you might want to use TCP mode rather than UDP for the VPN.

If your router doesn't provide this functionality, get a cheap Linux-based router and use OpenWRT/LEDE. It lets you configure OpenVPN in any way you like.
༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#10
Options
Re:Omada controller avoid broadcasting as IPs are fix and known
2018-06-25 04:23:19

R1D2 wrote

Ah, I see.

Solution is to run OpenVPN in client-to-client mode and make sure to bridge the interfaces (no routing!). Additionally you might want to use TCP mode rather than UDP for the VPN.

If your router doesn't provide this functionality, get a cheap Linux-based router and use OpenWRT/LEDE. It lets you configure OpenVPN in any way you like.


Finally I got the solution. I'm connected via OpenVPN with client-to-network solution. This makes the remote management computer available for the local network, but on a different subnet. On the other hand, I set up the AP-s via EAP Discover the controller ip to the OpenVPN subnet member IP (not the management one). And finally I did some tests if there is a power outage and EAPs did not forget the controller address, so finally achieved my goal. There might be some cases where it will break, but those can be handled via on-site management.

Thank you for your support and ideas!
  0  
  0  
#11
Options
12

Information

Helpful: 0

Views: 3404

Replies: 12

Related Articles
What to do with Omada to avoid ISP bandwidth throttling?
590 0
Omada IDS/IPS
332 1
 Reserving IPs with the OC300 Controller
353 0
 New 5.11.8 Controller WITH IPS!!
775 4
 How to avoid IP conflicts
1729 0
 TP-Link Omada IDS/IPS
7433 0
About Us
Press
Copyright © TP-Link Systems Inc. All rights reserved.