Integration between Meraki dashboard and Aruba ClearPass.

[Mahjouboi]

Hi,

Currently we're implementing Aruba ClearPass as NAC solution in my company, the servers hosted in Azure cloud, so in order to integrate with our Meraki dashboard, I want to understand the required ports to be open between ClearPass servers in Azure cloud and Meraki cloud.

please your assistance if anyone did the same.

BR,

Osama

[alemabrahao]

I understand that Aruba ClearPass is a NAC like any other so it should probably work on port 1812 and 1813.

Is the integration you talk about 802.1x authentication? If so, all you need to do is communicate with the server in Azure (I really hope you do this via S2S VPN) and configure 802.1x using an external radius.

https://documentation.meraki.com/MR/Encryption_and_Authentication/Configuring_RADIUS_Authentication_...

[Mahjouboi]

Hi @alemabrahao 

thanks a lot for your reply, 802.1x integration is clear, what I want to know is the communication between ClearPass servers which in Azure and Meraki dashboard, what is the source and destination in order to open the rules in FW, if we say the source is ClearPass servers, then what is the destination for Meraki dashboard.

I hope you get what am looking for.

[alemabrahao]

Sorry, but you're actually the one who should know.

If the MX has an S2S VPN directly with your Azure cloud, you must allow communication with the Lan IP of your server.

If your server is open to the internet (which is not ideal) you have to release it to the public IP defined when deploying the machine to Azure.

Without knowing what your communication with Azure is like today, there isn't much that can help you.

[alemabrahao]

I really recommend you read the Aruba documentation.

Firewall Ports Recommended and Required to Be Open (arubanetworks.com)

https://community.arubanetworks.com/discussion/clearpass-wireless-using-meraki

[GIdenJoe]

In the situation where you use 802.1X for switches and AP's they will just use their management IP (or the optional secondary management IP) as source for the radius requests.

However with a physicial MX for Client VPN where the Radius server is over a site to site VPN it will use an internal VLAN IP address.  We had tested this once a few years back where I doubted that this setup would work since the MX normally uses the interface closest to the radius server as source.  But it actually did work.

So you would be looking at any VLAN interface on the MX of a subnet that is allowed over the VPN that is the possible source.  The best thing you could do is just to see the logs in your radius solutions just to see where the actual request is coming from.  In case of AutoVPN you can just use the dashboard capture to see what's happening.