Jump to content

Recommended Posts

Posted
Just read many items...

1-5-9-13 is most definitely NO. We had a neighbour using Ch8 which killed two of our channel ranges with interference.

 

I guess it depends on how close they are to how many APs, if it's just a few those can use 1 and 13 and 5/9 can be used by the next layer in

  • Thanks 1
Posted
The problem is not other APs using a channel not compatible with 1,5,9,13 ....or rather that is a problem too....but thise channels are just to narrow for the othoganal spectrum used when 'n' technology started using it. Worked fine for 'g'. So ...I guess in high density deployments there might be a solution where limiting the ap to g speeds and using 4xap rather than 3 might give more throughput...but thatwas not suggested by the cisco research paper I read...which looked in detail...too much of it mathematical for me to fully understand. But its conclusion was clear...you would always be worse off using 4 channels because the challen separation was not sufficient to avoid interference between neighbours. A common misunderstanding is the graphs which some wireless analysers draw which show amplitude decreasing towards end of channel...which is not the case for orthaganaol tranmissions for n wireless.
  • 3 weeks later...
Posted

We have over 200 Meraki APs onsite, but integrating them with the firewall has caused such problems that we are now looking to replace them all a great expense.

 

So if you want to use 802.1x authentication on your SSID and use Radius Accounting to integrate with your firewalls DO NOT BUY MERAKI !!!!!!!!!!!

Posted
I think some more specific details out to be presented here to caveat such a strong statement. What firewall? What service was providing RADIUS? What were the APs configured to use for RADIUS accounting?
Posted (edited)

RADIUS provided by Aruba ClearPass 5k Cluster

Firewalls SonicWall SM9200 HA Pair

Aruba ClearPass acting as Radius accounting Proxy

 

Issue: Radius Accounting Start packet does not contain Framed-IP-Address attribute.

 

Logged with Meraki November 2015

 

Meraki Response:

 

What you are seeing is expected behaviour, as I explained to you during our last phone call, and the only way to have this changed is to submit a feature request using the Make a Wish box. The feature request will then be looked into by our development team and they will include it into our feature set if resources permit.

 

This is after buying over 200 APs and buying extended licensing.

 

I stand by my statement and hope that this is specific enough.

Edited by geezersoft
  • Thanks 2
Posted

For a true SSO experience with the lack of review of RADIUS accounting you are better keeping the wifi and firewall/ UTM with the same vendor.

 

I can help anyone with advice looking at the new Fortinet (Meru) solutions.

Posted

I've no wish to defend or condemn Meraki, but I am surprised to say the least. I'm not sure why Meraki is looking for or requires this attribute - but it would seem "intolerant" of it at best. I am sort of surprised that Meraki are not helping you by suggesting another means of supplying Radius - because there are lots of stuff out there that can do radius using AD as a database - which I assume is what is required...and Linux ones for free. Yes it wouold require someone with some enthusiasm and a little know how....but they are not in short supply.

 

I'm not sure why you would want a firewall (assuming the firewall is multihomed and is acting as gateway between a VLAN'd wireless network and other stuff) AND an Aruba ClearPass device - which must duplicate a lot of what meraki is doing in terms of identifying devices and traffic. Are all these access points on one site? or is this a multisite arrangement.

 

I use smoothwall for Radius - but have used Microsoft TMG in the past - and use Aerohive access points. It never occurred to me that there might be incompatibilities with some vendors. These are supposed to be "standards" so I would expect interoperability or at least tolerance when things are not quite as expected.

 

I like the meraki interface a lot - and thinks it sets a high bar for other vendors to match. Really gone off Meraki hearing the tone of their unhelpful response.

Posted

I have RADIUS all wrapped up, ClearPass is an excellent product. ClearPass is a dedicated NAC solution and nothing to do with firewall functionality. Perhaps you are unfamiliar with the product. The link below gives you an overview.

 

ClearPass Network Access Control: NAC Security Solutions | Aruba, a Hewlett Packard Enterprise company

 

I love the Meraki Interface, and generally find their support very good. But this response was really disappointing. 20 months later and still they have not found sufficient reason to resolve it so I am now looking at other vendors that do not suffer this issue. Their loss at the end of the day.

Posted

Ok, NAC.... so you check machines connecting have MS updates, AV, etc? Before you allow them to connect..so you are using it between the firewall and your internal network? Does it do reverse proxy? ...single sign on ? Just wondering what it's doing and how important those functions are. Presumably..and it would be annoying...but perhaps pragmatic...if you used another radius server..or indeed a secondary one working off clearpass...could wireless still pass through clearpass as well or would that force another authentication? And...are you using a captive portal or just the 802.11 authentication?

 

I know I was gutted when TMG was end of life because nothing provided reverse proxy, SSO, NAC, radius ...as well as dNS and DHCP in a single package...nor indeed as tightly integrated...but apart from SSO for incoming connections we have managed to cover most things with different products...and maybe getting something else to radius for wireless might work..and cheaper than replacing wireless kit.

Posted
Using ClearPass for certificate on boarding and 802.1x authentication initially but plans to test onconnect non aaa network security on the wired network in the future. Possible mdm integration too.
Posted
"Certificate on boarding".....exactly what is meant by that? I'm still thinking that Clearpass is something I would not be using for the Meraki kit if its not providing what Meraki requires from a radius server. Not sure what it actually offers you as far as MDM is concerned. Does it provide MDM functionality? Again there are plenty of alternatives. I can see that Network Access Control - such as testing that remote clients have Windows updates and current antivirus might be useful - but to be honest - I wouldn't be allowing anything to directly connect to my internal network apart from via published webservices in my DMZ. , sorry - don't understand why you are wedded to ClearPass.
Posted

Hi Alan,

 

I think you have misunderstood what I an talking about. Onboarding is where ClearPass issues and installs individual unique certificates from it's own CA to devices for the purposes of 802.1x authentication (and SonicWall DPISSL de-cryption) in a user friendly way. ClearPass policy manager provides flexible policy driven Authentication services (including Radius). It is Meraki that are not providing the IP address of the client when it connects to the AP. This is a Meraki Problem, not a ClearPass problem, not a SonicWall problem. I hope that helps clarify my position.

 

Thanks for your input though.

Posted
OK...but you don't actually need certificates for 802.1x authentication...are you trying to ensure that the WPA2/PEAP process is secure during the client logon? Is this process not handled by Meraki access point...which then in turn...passes the details (again encrypted...but over your cables) to ClearPass. I'm not disputing that fact that Meraki are at fault....indeed they seem to be admitting to that....only they are asking YOU to raise it with developers....it would seem sensible if they were raising it with their own developers. Still can't get my head around what ClearPass is providing you with that is so key to your requirements. I'm sure lots of schools use Enterprise WPA without individual user certificates.
Posted
HIt is Meraki that are not providing the IP address of the client when it connects to the AP. This is a Meraki Problem, not a ClearPass problem, not a SonicWall problem. I hope that helps clarify my position.

 

Have a think about how 802.1x actually works with RADIUS. The wireless controller probably won't know what it's IP address is when it asks the RADIUS server for authentication/authorization.

How is going to tell anything else about the IP address if it doesn't know itself ?

Posted (edited)

The real crux of the matter is how the initial device connection is handled. I will try not to get too bogged down in terminology here so apologies in advance for any hard-core RADIUS gurus looking for phrases like supplicant. The following is a plain English overview.

 

In 802.1x, when a device is authenticated by an Authentication Server (RADIUS Server), that information is passed to the NAS or Network Access Server. The NAS allows the authenticated device to connect to the network and if configured for RADIUS Accounting, sends a RADIUS Accounting start packet to a RADIUS Accounting Server so that the session details can be logged.

 

In the wireless world the NAS is either the AP (Access Point) itself or the AP controller that sends this packet (depending on your Wi-Fi hardware). So for Meraki (that has a cloud based controller), the AP itself sends the RADIUS Accounting packets.

 

There are basically 3 types of packet, a start packet (sent on initial connection), an interim update packet (sent periodically if a device is still connected) and a stop packet (when the device disconnects).

 

Now the RADIUS Accounting start packet contains the user name of the person logging on - this is mandatory. It is only optional for the packet to also include the IP Address of the device that connected – here is the rub.

 

Here we go:

 

1) Because 802.1x is a layer 2 protocol, it does not need the device to have an IP Address to work. So quite often, even if you have support for sending the IP address in the RADIUS Accounting packet (known as Framed-IP-Address attribute value pair), the DHCP Server may not have given the connecting device an IP Address by the time the NAS sends the RADIUS Accounting start packet. This behaviour is compliant with RFC 2866 and RFC 2869. However it is also completely useless if you want a third party device such as a firewall to associate a user name with an IP Address so that it can log activity and apply user specific policies.

 

2) So to overcome the above mentioned technically compliant but fairly unhelpful RFC compliant solution previously described, forward looking wireless vendors (i.e. not Meraki) have come up with modifications or work arounds to either:

 

a. Delay the sending of the RADIUS Accounting start packet until the IP Address can be included.

b. Immediately send an early RADIUS Accounting interim update packet as soon as the IP Address of the device is known (possibly through DHCP snooping and generally less than a second after the initial connection).

 

If neither of the above occur, then the first packet that would contain the device IP Address would be the standard RADIUS Accounting interim update packet if that has been configured (and that is generally at least 5 minutes). This in turn means that any device waiting for the IP Address information (such as a firewall) cannot correctly apply policies until it receives this information (i.e. no traffic will flow through the firewall). This is what I currently have with Meraki and it is of no use to me.

Edited by geezersoft
  • Thanks 1
Posted (edited)

Rather than chucking out the 200 AP's is it possible to put in a workaround ?

If you put in a freeradius box between the Merakai and the content filter perhaps you could use it to perform an ARP lookup and insert the ip address into accounting packet before passing it on to the sonicwall?

I'm pretty sure you can add preaccounting scripts to freeradius but not sure exactly how to do it; for the cost of replacing it it's certainly worth asking on the mailing lists.

 

Why is the IP address so important anyway? surely content filters are better working on usernames/authentication!

Edited by mjk
Posted
Have a think about how 802.1x actually works with RADIUS. The wireless controller probably won't know what it's IP address is when it asks the RADIUS server for authentication/authorization.

How is going to tell anything else about the IP address if it doesn't know itself ?

 

Our UniFi system certainly knows the IP address of the connecting client and passes it on through RADIUS Accounting just fine... I'm assuming it passes it along after all the authentication is done and a connection is established, but it's there.

Posted
Our UniFi system certainly knows the IP address of the connecting client and passes it on through RADIUS Accounting just fine... I'm assuming it passes it along after all the authentication is done and a connection is established, but it's there.

yes it must send an interim update as described above; it can't send an IP address before the DHCP server has issued one, and that can't happen until the RADIUS has authorised it.

Posted
Which begs the question if the likes of Ubiquiti can do it, why can't/aren't Meraki, who are considerably more 'enterprise-y' and expensive.

 

I'm still not quite understanding *why* it is necessary: surely it's the authorized username that we care about, not the IP address which is easily spoofed.

Posted

I am now wondering how my smoothwall and Aerohive combination work. I use smoothwall as a radius server for wireless - and for DHCP (For wireless only).

From what you are saying - Aerohive passes on authentication to Radius...the client connects....the client picks up a DHCP address.... Nothing has "told" the AP what DHCP address has been allocated...if it needs to know (and it normally displays an IP address) I presume it does some kind of look up.

 

Does the Meraki web interface show IP addresses of clients (I assume it does).

 

I'm guessing that smoothwall associated the Radius/username/device/DCHP with the client and maybe doesn't have to worry about an accounting packet from the access point.....or maybe it does get an accounting packet with the IP address.....I just don't know.....but it does work.

 

...I'd be very surprised if Meraki schools are not able to do SSO with wireless ...perhaps they are using AD authentication directly. Would this be an option for meraki? And would that pass on IP address as required?

Posted (edited)
I assume that because the smoothwall is acting as the DHCP server, it will have the DHCP lease database that maps a mac address to an IP address. Then the mac address in a radius accounting packet can be mapped directly to the IP address. ( I would check with a smoothwall tech) Edited by geezersoft

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...