Security

Hi community,

 

I have some questions regarding Aruba tunneled node feature, which is still not very clear to me even after reading some documents about it:

 

1) In per-port tunneled node (PPTN), why do we need to configure an end-user port to access a transport vlan? The document said that the vlan is used locally inside GRE tunnel, but for what purpose? Is there any advantage/disadvantage when we configure these ports to access the same/different vlans?

 

2) In per-user tunneled node (PUTN), the following sample configuration on the switch was given in Wired Policy Enforcement Solution Guide:

As far as I understand, the vlan which will be assigned to user is 604, and their traffic will be tunneled to the controller for processing (in role "quarantine"). The part that I'm not clear is that what if there's a vlan definition in "quarantine" role, say vlan 605? Then user will be assigned vlan 604 or 605?

 

Any help would be appreciated.

 

Thank you,

In a PPTN scenario, the ports themselves should be set to the “transit” VLAN as part of the tunneling.

For PUTN, the VLAN ID defined in the user role is the VLAN the user traffic will be assigned on the controller.

Hi Tim,

 

So, in PUTN, in case I made a mistake and assign a vlan in the role defined on the controller, the vlan configured in "primary" role on the switch will still be applied. Correct?

Correct

Hi Tim,

 

About the transport vlan in PPTN, is there any specific requirement for it? I think as long as we have connectivity between the switch and controller, this vlan is not important. I'm still not sure why we need to assign switch interfaces to this vlan?

It should be a dead end VLAN that only exists on both sides but is not tagged through the network.

PUTN is recommended over PPTN.

Hi Tim,

 

I have some more questions regarding PUTN scenario:

 

1) The switch will always do AAA functions. Correct?

2) Is there an option to deny peer-to-peer traffic between clients in both scenarios: traffic being tunneled to the controller and being locally processed by the switch?

1) No, with PUTN, the switch handles all AAA.

2) Not today.

So, there's currently no support to deny P2P traffic in both PPTN and PUTN? Because the reason I'd like to deploy tunneled node is to let the controller deny P2P traffic between wired clients just like with the wireless ones.

Globally enabling it in the firewall may work, but not something I’ve tested.

Hi Tim,

 

If I'm not using tunneled node, does Aruba switch support an option to deny P2P traffic between wired clients - something similar to protected port on Cisco switch?

Private VLAN would be the closest thing.

Hi,

 

I'm testing PUTN on ArubaOS switch, including DUR from CPPM and it has worked well so far. I have one question though. Does the controller also support DUR in PUTN? I mean, can we have a scenario where the switch downloads "primary" role from CPPM, then tunnel user traffic in secondary role to the controller, which in turn downloads the content of this role from CPPM?

 

Regards,

Coming soon.

Hi,

 

In terms of Layer 2 security, when using PPTN, does the controller support common security features (DHCP snooping, Dynamic ARP Inspection, etc.)?

 

Regards,

Does anyone have information about L2 security features on the controller when using PPTN? I tried to search this but found nothing.

Hello!

 

I tested this in my lab and it works for me just fine in the following way:

 

I have an Aruba switch with PPTN to Aruba controller, where I have a captive portal profile set to authentication. The authentication is sent to Clearpass, which then reads Active Directory, and based on group membership, it sends back Aruba VSA role to controller. I have a separate service for wired authentication on CPPM and I have a separate wired roles and wireless roles (example: aruba_wifi/aruba_wired) on controller. I have a policy in the wired roles that denies user to all private ip. This way they can surf the net, but the two client can't communicate with each other even if they are in the same role.

 

Hope this helps.

 

Daniel