Wireless Access

Hi,

Trying to help a customer allow their guest users to be able to use certain corp printers.

I added the following into the acl for the authenticated guest role at the top.

any printer any route src-nat

 so now the guest user is able to ping the printer, but still not able to print to it.  To test further, an ftp server was put in place of the printer, and then the guest user tried to connect to it.

What we found is that the three way handshake is not completing.  The server receives the request from the client and responds (with the dest being the controller), but this doesn't get back to the client.

Not sure what the datapath session table is showing at the time, but hopefully will know more soon.

Is this the correct way of doing it?

Thanks

Hi Michael,

I would like to know the setup before I can comment on the best approach to achieve this.

Are the guest users connecting to a campus AP or a RAP at remote location and what is the configured Forwarding mode on the Virtual AP?

Generally for the RAP on split-tunnel, we may configure the user-role in the below way.

any any svc-dhcp permit

user alias corp-networks permit

any any any route-srcnat

The Action “permit” in the above ACL will tunnel the user traffic back to controller and the action "route src-nat" will source natt the traffic locally using the AP’s IP address as source.

It would be great if you can post the guest user-role acls and a simple Network sketch.

Also let us know if the Printer is wireless or wired and does this sit in the same subnet as the AP/Client?

If this is a time sensitive issue, please open a TAC case to achieve faster resolution.

Thank you,

Sriram

Hi,

They are campus APs in tunnel mode.  This may be what the problem is as I see the 'route src-nat' rule is mainly meant for RAPs.

The printers are in different subnets to the guest users.

We have some other ideas to test and will post the results later.

Thanks

We use the TCP-Printing firewall policy to allow our users access to our printers (tcp 9100).  Our users are also on a different subnet (and vlan) than the printers.

Computers also use SNMP to get status of the printer queue and to start/stop jobs.  SNMP does not work too well over a NAT boundary.

Thanks much for update. Since user is connected to CAP on tunnel mode, we need to re-write the ACL as "permit" instead of "route src-nat". We could also add the specfic test user to allow-all role and see if that makes any difference. 

Here is the below command.

(Aruba) #aaa user add <ip address of the test user> role authenticated

Please provide "show datapath session table |  include <ip address of the client>" output to check for client traffic against the printer when acl been hit and changed to "permit".

Thank you,

Sriram

We added another vlan with 'ip nat inside' and changed that rule to be permit instead.

They were able to get a telnet session open to the server we used to test, so all good.

My job is done, but I think that is just the first hurdle for them.

Thanks guys

Thanks much and good news Michael.