Wireless Access

On our RAPs, we have split-tunnel wireless users that print to a network printer on a bridged port.  This has worked flawlessly for several branch offices using a particular make/model of printer.  However, one branch has two printers: one being the standard branch printer and the other is different.  This branch is having issues printing to the oddball printer after the printer goes idle.  When I check the user table, the MAC/IP for the printer isn't there.  I'm wondering if when the printer goes to sleep, if that's causing its entry in the user table to be removed, which is keeping split-tunnel users from being able to print to it.  This may very well be a printer issue, but I want to make sure it's not somehow related to the printer being aged out of the user-table as it becomes idle.  Any thoughts?

Get rid of that printer ;)

 

Just kidding.  Do you have an idea what protocols are necessary to print or obtain status for that printer by clients?  That is a good starting point...

 

Trust me, I'd like to :)

 

As far as I know, it's a standard setup.  TCP 9100.

 

My line of thinking here is that if the printer goes idle and is removed from the user table than a split tunnel user won't be able to wake it up by sending a print job to it.

Some printers require SNMP (UDP 161) to be able to query if it has anything in the queue....

 

True, but I'm allowing all traffic from split tunnel users to the subnet bridge devices are on.  So it shouldn't be a rights issue.

If you "permit" from a split tunneled SSID, that means "tunnel back to the headend", which should not reach bridged devices.  What ACL are you using to permit local traffic and are you using the "Remote-AP Local Network Access" checkbox in the AP system profile to route traffic from split to bridged users on the RAP?

I do not have Remote-AP Local Network Access checked in the AP system profile.  I assume this may not fix the issue since split tunnel users do have access to at least one printer on a bridged port.

 

The ACL to allow split-tunnel users to the bridged port is as follows: user alias printers any route src-nat

 

I did some research on the printer and found a firmware upgrade that resolves the following issue:

 

Network communication may not wake device when in sleep mode.

 

That sounds like the issue we're having.  I'm waiting to find out what firmware version the printer is running.  Hopefully, an upgrade is all that it needs and it's not a RAP issue.

---

@thecompnerd wrote:

I do not have Remote-AP Local Network Access checked in the AP system profile.  I assume this may not fix the issue since split tunnel users do have access to at least one printer on a bridged port.

 

The ACL to allow split-tunnel users to the bridged port is as follows: user alias printers any route src-nat

 

I did some research on the printer and found a firmware upgrade that resolves the following issue:

 

Network communication may not wake device when in sleep mode.

 

That sounds like the issue we're having.  I'm waiting to find out what firmware version the printer is running.  Hopefully, an upgrade is all that it needs and it's not a RAP issue.

---

The Remote-AP Local Network Access option would allow devices that are split tunneled and/or bridged to communicate on the same RAP without NAT.  Enabling that would be able to rule out if there is an issue with the printer protocol being source-natted, is why the option was suggested.  If the firmware update indeed provides the fix needed, please publish the name and model of the printer so that others can benefit.

 

 

It turns out that the printer is already running the latest firmware version that corrected the network issues.  I also verified that the printer's sleep mode has been disabled so it's not a sleep issue.

 

I will enable the Remote-AP Local Network Access option to eliminate this as a possible issue.

Enabling Remote-AP Local Network did not help.  Curios to know, do I need to save the config for the changes to be pushed to the RAPs if I made the changes on the controller that the RAPs terminate on?

 

I've talked with several other branches and they've indicated that they have issues with the printer I assumed was working just fine.  They're saying that there is a large delay when printing; sometimes 1 - 5 minutes.  Sometimes the printer won't print at all.  It's not consistent one bit.  I really think the RAP is the problem as these print issues were never a problem before when the branch users and printers were connected to a simple flat network (pre-RAP installation).

 

I hate to abandon the configuration I have, but I'm not confident that printing to a bridged device via split-tunnel connection is the best way to get this to work.  I went with bridged mode so I wouldn't have to extend corporate connectivity to the printer and authenticate it via MAC.

You might want to open a case with support.  There definitely may be some additional traffic requirements that this printer has that other printers do not.

 

I have a case open with Aruba.  They're trying to recreate the issue.

 

I'll update this post if they figure out what's going.

I have an answer back from TAC.  They believe it's either due to the user idle timeout or the need for 2-way communication between the client and printer. The following workarounds were suggested:

 

1. Increase the user idle time out to 1 hour.
2. Set the port/vlan to trusted.

Increasing the user idle time out is the easiest solution, but I was concerned how this may affect the controller.  The only thing I can think of is that it will increase memory utilization.  Still, this would only improve the situation, not resolve it because I can't count on users printing every hour to keep the entry fresh in the  user table.

 

Setting the port to trusted is not possible with the current configuration because the port is in bridged mode.  So I would need to change the printer port to tunnel mode.  However, that becomes a problem because than anyone can connect to the port and gain access to the corporate network.  I suppose the solution to this would be to create an ACL where this traffic comes in at the corporate network.

 

A thought that I had was to tunnel the users' and printer traffic and let the printer authenticate via MAB.  According to the user guide, the controller will probe the device after its idle period expires.  If that's the case, the printer should respond to the probe and stay in the user table and solve my problem.  Since the controller can't reach a bridged port, it has no way of keeping the printers in the user table given my current configuration.

 

Sorry, I meant that I have an acl that source NATs split tunnel users to the bridged network.

I'm not sure about the checkbox you're referring to. Will check that in the morning.

Also,I accidentally selected my post as the solution. Didn't mean to do that! Can I take that back? :)

Same problem with HP m3027.