05-07-2012 09:31 PM
I spent several hours on the phone with Aruba tech support scratching their heads and really need some help. I have a RAP5 configured with a split-tunnel SSID and one wired port in bridge mode. The wired port requires MAC authentication, either through user derivation or MAC auth. The wired port connects to a network printer and is to be accessible from the corporate SSID. The RAP is providing DHCP to the bridge port without any issue and I am source NATing traffic from the wireless side to the wired side.
The issue I have is that the in all my tests I can not get an authenticated wireless device to be able to talk to the printer on the wired port. A basic ping is about all that works. If I look at the user-table and filter by the printers MAC, the printer shows that it's role is "logon" even though I have MAC auth enabled. I checked the usual suspects, making sure the MAC was in the internal DB (user/pass). I also disabled MAC auth and instead tried setting up user derivation, and assigned the authenticated role if there's a MAC match. This doesn't work either. The user-table output doesn't even show that MAC auth or user-derivation rules are being considered. The only way I can get the wireless devices to talk to the wired printer is to set the wired default role to authenticated.
Anyone have any thoughts? This is 5.0 code.
If a reply adequately addresses your issue, please click on the "Accept as Solution" and "Give Kudos" button so this information can benefit other users.
05-08-2012 01:11 AM
So, it works if you set the printer port on the rap to authenticated by default yes? So it's an auth problem?
Can you please post the aaa profile config for the wired port you're using?
Also, what server are you using to auth on the port (i.e. OS and version etc)? Do you see any auth entry attempts in it's log when the printer gets plugged in? What's the content of them?
What version of code are you running?
05-08-2012 03:41 PM
If I understood correctly, then issue is happening because the printer is in the logon role, which is not correct.
If that is true, then enable user-debug. It will give you idea from where that role is getting derived.
What is the TAC case #? I can try to look into it...