Wireless Access

last person joined: yesterday 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Expand all | Collapse all

Remote AP local net access - printing locally

This thread has been viewed 0 times
  • 1.  Remote AP local net access - printing locally

    Posted Jan 10, 2013 02:49 PM

    I'm discouraged by the trouble I'm having with split-tunnel (wired/wireless) printing to a printer on a bridged port, so I'm going to put the printer in split-tunnel mode ( different VLAN than corp users ), create a policy denying corporate access from the printer, and enable Remote AP Local net access to enable local printing.

     

    I'm not understanding how the RAP will be able to route between the two VLANs once Remote AP Local net access is enabled.

    Is src NAT also needed for this option to work?

    If so, how does the RAP determine which IP to use for src NATing?

    For bridged mode, my understanding is that the VLAN of the bridged port should match the Remote-AP DHCP Server VLAN in the AP System Profile so that the RAP knows from which subnet to src NAT with.  I just don't see how the same rule would apply for a split-tunnel user.



  • 2.  RE: Remote AP local net access - printing locally

    Posted Jan 10, 2013 03:33 PM

    Alternatively, if I wanted the printer to have limited corporate access for reporting (toner levels, paper low, etc) it would be easier to put the printer in the same VLAN as the users and create a role with limited access for the printer.  In that case, the tunnel mode would still need to be split tunnel and remote AP local net access would need to be enabled to print locally, right?



  • 3.  RE: Remote AP local net access - printing locally

    Posted Jan 11, 2013 04:22 PM

    What I'm thinking is that src-nat will be required for the RAP to be able to route the traffic locally between VLANs.

    To answer the second part of my question, I think a NAT pool needs to be created (destination NAT IP = IP in other VLAN) and added to the src-nat rule.  I don't see how the RAP would otherwise derive an IP address to src-nat to.

     

    Is that all correct?



  • 4.  RE: Remote AP local net access - printing locally

    Posted Jan 12, 2013 04:28 AM

    This is what I do for allowing printing on RAP-Split tunnel forward mode :

    - Set Printer on the same vlan / IP of the access point

    - Define Alias for internal IP of the remote site

    - Set policy : any - alias(internal-of-remote)  - any (or printing port service) - route src nat 

     

    check if client can ping to internal network on remote site and check if you can print too.

     

     

    Goodluck!

     



  • 5.  RE: Remote AP local net access - printing locally

    Posted Jan 12, 2013 04:31 AM

    oh yeah, if you put printer on different vlan/subnet, just make sure your AP can ping to that and add the printer subnet to the internal alias.

     

    That sould do the trick.

     

     

    Goodluck!



  • 6.  RE: Remote AP local net access - printing locally

    Posted Jan 21, 2013 01:36 PM

    My idea didn't pan out.  I had a misunderstanding of when you can use the nat pool command.

     

    Slickers, I've gone ahead with your recommendation and changed the ip pool so that RAPs are now in the same VLAN as the printer port.  I have yet to setup a printer and verify connectivity to it from another wired or wireless client.  I did try pinging the IP of the RAP from a wireless client and it failed.  Based on what you're saying, a split-tunnel client should be able to ping the RAP right?



  • 7.  RE: Remote AP local net access - printing locally

    EMPLOYEE
    Posted Jan 21, 2013 02:19 PM

    Okay.

     

    Let's get your topology straight:

     

    - You have Enterprise Clients in Split-tunnel mode so that their traffic can go to corporate, print locally, or be source-natted out to the internet

    - You have a printer in bridged mode so that it can be on the local subnet, but reachable by split-tunneled clients.  

     

    What you need to do is:

     

    - Turn on RAP-Local Bridging

    - Use the "localip" alias to permit traffic, instead of source-natting it

     

    You need to insert this rule BOTH the split-tunneled enterprise role, as well as the printer wired role.

     

    user alias localip any permit.

     

     

    The localip alias pertains to any ip address that is in the route-cache of the RAP.  A RAP has IP visibility of any device that is either split-tunneled or bridged because the traffic is decrypted and can be handled by the RAP.  The localip alias, in combination with RAP local bridging will allow traffic between clients on the same RAP without source natting, which might solve your printer issue.

     

    Please try this and see if it works.



  • 8.  RE: Remote AP local net access - printing locally

    Posted Jan 23, 2013 09:27 AM

    @cjoseph wrote:

    Okay.

     

    Let's get your topology straight:

     

    - You have Enterprise Clients in Split-tunnel mode so that their traffic can go to corporate, print locally, or be source-natted out to the internet

    - You have a printer in bridged mode so that it can be on the local subnet, but reachable by split-tunneled clients.  

     

    What you need to do is:

     

    - Turn on RAP-Local Bridging

    - Use the "localip" alias to permit traffic, instead of source-natting it

     

    You need to insert this rule BOTH the split-tunneled enterprise role, as well as the printer wired role.

     

    user alias localip any permit.

     

     

    The localip alias pertains to any ip address that is in the route-cache of the RAP.  A RAP has IP visibility of any device that is either split-tunneled or bridged because the traffic is decrypted and can be handled by the RAP.  The localip alias, in combination with RAP local bridging will allow traffic between clients on the same RAP without source natting, which might solve your printer issue.

     

    Please try this and see if it works.


    Yes, that is our current topology.

     

    I've been told by TAC that the reason why we're having print issues is the printer ages out of the user table due to inactivity.  When it ages out, split-tunnel clients can no longer connect to it.  That's why I decided to put the printer in split-tunnel mode.  According to the user guide, the controller can probe network devices before they age out to keep them in the user table.  My understanding of bridge mode is that the controller has no visibility of bridged devices, so I chose split tunnel mode, assuming the controller probe could reach the printer to keep it in the user table.

     

    I will try your suggestion as it's easy enough to implement.