Wireless Access

last person joined: 20 hours ago 

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

Bridging connected LAN on Eth1

This thread has been viewed 7 times
  • 1.  Bridging connected LAN on Eth1

    Posted Jan 19, 2012 05:38 AM

    Hi

     

    i'm testing the AP125. I want to get access on ETH1 to the LAN where the AP is connected.

    e.g.

    My ap got an ip address of segment 10.10.10.0/24. I want to build up a bridge to Eth1 connecting the 10.10.10.0/24 LAN.

    In some offices there are less networkports so i could plug the ap within and would not loose any port.

     

    Is this possible?



  • 2.  RE: Bridging connected LAN on Eth1

    EMPLOYEE
    Posted Jan 19, 2012 05:48 AM

    Yes, it is.

     

    Go to Configuration> Wireless AP Configuration. Edit the AP-group that the AP is in.

    Expand AP, Expand Ethernet Interface 1 port Configuration. The Wired AP profile under that is what you want. Change the forward mode to bridge and make it trusted. Make sure the Access Mode VLAN matches the Vlan in AP System Profile> Native VLAN ID in the same AP group.

     

    One Note: After you make the changes to the Wired AP profile, that you do a "Save as" and make a new profile name before clicking apply, because all ports are tied to the "default" initially and making changes to anything named "default" will change everything tied to that.

     

    The last note on the AP125 is that it requires either high powered poe or a power brick in order to bring up the second port.



  • 3.  RE: Bridging connected LAN on Eth1

    Posted Jan 19, 2012 06:10 AM

    Thanks for the answer, but if i mark "Trusted" i got the following Error Message:

     

    Warning: split-tunnel OR Bridge wired port can only be "Not Trusted". Changing "Trusted" to "Not Trusted".
     



  • 4.  RE: Bridging connected LAN on Eth1

    EMPLOYEE
    Posted Jan 19, 2012 06:20 AM

    Yes, I forgot that part.  Make it untrusted and add a AAA profile who's initial role is authenticated so that all your traffic passes through.  Also, make sure control plane security is on.

     



  • 5.  RE: Bridging connected LAN on Eth1

    Posted Jan 19, 2012 06:30 AM
      |   view attached

    I already tried this config. But my client does not got an ip via dhcp.

    have a look at the attachement for config information



  • 6.  RE: Bridging connected LAN on Eth1

    Posted Jan 19, 2012 06:33 AM

    where can i find the control plane security?



  • 7.  RE: Bridging connected LAN on Eth1

    EMPLOYEE
    Posted Jan 19, 2012 06:41 AM

    @FlorianKueck wrote:

    where can i find the control plane security?


    Control Plane security is under configuration> Control Plane Security Tab.  Make sure you use auto cert provisioning.

     

    WARNING: THIS WILL MAKE ALL YOUR APS REBOOT and they will take about 8 minutes to come back up.



  • 8.  RE: Bridging connected LAN on Eth1

    Posted Jan 19, 2012 08:07 AM

    The Vlan in the wiredAP Profile is VLAN 1. It should be ok?

     

    The Control Plane Security is off. But what is the effect of these function?



  • 9.  RE: Bridging connected LAN on Eth1

    EMPLOYEE
    Posted Jan 19, 2012 08:15 AM

    @FlorianKueck wrote:

    The Vlan in the wiredAP Profile is VLAN 1. It should be ok?

     

    The Control Plane Security is off. But what is the effect of these function?




     

    You need to either have that AP configured as a RAP, or Turn on Control Plane security to activate bridging at the AP.  Does the link come up when you plug in the device?

     



  • 10.  RE: Bridging connected LAN on Eth1

    Posted Jan 19, 2012 08:27 AM

    the interface comes up an it has link.

    But dchp does'nt work. Also a static ip is not able ti ping.

     

    What does te Control Plane Security do? I don't know this featur.



  • 11.  RE: Bridging connected LAN on Eth1

    Posted Jan 23, 2012 08:09 AM

    CPSEC is short for control plane security. It sets up an ipsec tunnel between the AP and the controller.  This tunnel is done via secure certificate. When you turn this on, all of your AP's will have to negotiate this key exchange and then set up an IPSEC tunnel to the controller. 

     

    This tunnel encrypts all traffic, including the command and control traffic, to the AP. This allows the controller to pass the decrypt keys to the AP so the AP can do local decrypt and ACL functions. It opens a few more mode operations (bridge, tunnel decrypt) 

     

    We tested this extensively when it was first rolled out in 5.x. Local bridging is particularly interesting in that you can pass the building VLAN to the client, but maintain your firewall and role status. When you roam your session information  is copied to the AP you moved to. You DO need to make sure you have adjusted port security on your switching platform or it may trigger a shutdown on your port..

     

    It does add processing overhead to the AP and the controllers. This is a system setting not an AP group, so one check box turns on a lot of things...



  • 12.  RE: Bridging connected LAN on Eth1

    EMPLOYEE
    Posted Jan 19, 2012 06:39 AM

    @FlorianKueck wrote:

    I already tried this config. But my client does not got an ip via dhcp.

    have a look at the attachement for config information



    What is the VLAN in the wired AP profile?



  • 13.  RE: Bridging connected LAN on Eth1

    EMPLOYEE
    Posted Jan 19, 2012 08:32 AM
    Control plane allows a regular campus ap to do bridging. The alternative would be to turn that ap into a remote ap.


  • 14.  RE: Bridging connected LAN on Eth1

    Posted Jan 19, 2012 07:44 PM
    Colin, I'm confused. I know for a fact that I have used the eth1 bridging feature on ap70s on 3.x as a standard campus AP (ie, not a RAP), which doesn't have CPSec available. Are you sure this is a new behavior/requirement in 6.x?


  • 15.  RE: Bridging connected LAN on Eth1

    EMPLOYEE
    Posted Jan 19, 2012 09:29 PM

    @Ryan wrote:
    Colin, I'm confused. I know for a fact that I have used the eth1 bridging feature on ap70s on 3.x as a standard campus AP (ie, not a RAP), which doesn't have CPSec available. Are you sure this is a new behavior/requirement in 6.x?

    Control plane security allows secure connectivity between a campus AP and the controller.  When the forwarding mode of a Virtual AP or Wired interface is Tunnel, traffic is tunneled back to the controller,  and it is left encrypted using whatever wifi encryption is in place.  Decryption is done at the controller securely.

     

    Using bridge mode on an AP, traffic has to be decrypted at the access point, so secure information like ACLs for bridged users needs to be tunneled to the AP with a secure mechanism when traffic needs to be enforced at the AP, hence the need for control plane security.  There was no enforcement in ArubaOS 3.x.  In ArubaOS 5.x and 6.x when you bridge, it must be untrusted so that policy is enforced.  When policy is enforced, a secure mechanism is needed to push the client firewall policy information to the AP.

     

    I hope that makes sense.

     



  • 16.  RE: Bridging connected LAN on Eth1

    Posted Jan 22, 2012 02:43 PM
    Understood, Colin. But to be more concise, you're saying that Aruba has changed the behavior in 5.x / 6.x to require CPsec if this feature is to continue to be used. Right?


  • 17.  RE: Bridging connected LAN on Eth1

    EMPLOYEE
    Posted Jan 22, 2012 03:10 PM

    To be clear:

     

    - Bridging in any form required that you configure an AP as a RAP in 3.x period (you could only have that second ethernet port act as either a standby for the first port or be tunneled).

    - Tunneling on a second ethernet port works just fine with an AP as a campus AP (which is probably what you are doing in 3.x).

     

    In 5.x/ 6.x you can do bridging on an ethernet port on a Campus AP, but you need to have CPSEC be on.

     



  • 18.  RE: Bridging connected LAN on Eth1

    Posted Jan 25, 2012 01:13 PM

    Thanks, Colin. We were tunneling. Thank you for clearly noting the difference.