Aruba OS 6.1 and Split Tunnel on RAP 5
Good day. You may already have heard of Aruba Networks. I want to share with you a little setup experience. The most interesting for me was setting up a profile for RAP 5 (Remote Access Point).
The piece of iron is interesting in itself. It is intended for small branches. In addition to the address of the central controller and the local connection settings, nothing else can be configured on it. She pulls up everything else from the controller as soon as she joins it. RAP 5 can be sent to remote offices by mail with instructions on how to drive the controller address into it, the rest will be done by the remote access point itself.
It was necessary to provide a quick connection to a remote office, ensuring the work of H.323 phones, SIP phones on iPhone and Android devices, mail, 1C, a printer and the Internet. In this case,contact Internet should not work through a central office.
With a H.323 telephone, the vlan with the central office phones is completely forwarded, and a separate vlan with split-tunnel is configured on the wireless network and office computers so that traffic to the office and voice networks goes through the IPsec tunnel and the Internet works via a short route through the local provider.
I’ll immediately make a reservation that I do not consider here the initial configuration of the controller as a central router, the binding of points, the fine tuning of the wireless part and the completion of the security policy.
Aruba OS has a so-called role-based architecture. That is, any connected device, both wired and wireless, necessarily gets the role that a bunch of different profiles are tied to. The condition for obtaining the role is also configured by a separate profile. Despite the fact that the OS has a friendly web interface, initially the head goes around when you try to remember in which tab which profile is tied to which one. Therefore involuntarily you pass to cli.
Initially, we create an acces list, which will provide us with split tunneling.
We denote the office grid, and also indicate that if there is a vpn connection, dhcp will be distributed from the central controller.
Now create the role to which we bind the acces list. First we allow all traffic.
Create an AAA profile and bind a role to it.
We create a wired profile and bind to it a vlan created specifically for our branch.
Profile for the port. We indicate which AAA profile is assigned to the device connected to the port.
We hang all the profiles on the first port of our RAP 5.
An office computer was provided.
Now it's up to telephony, create a universal acces list with priority on voice.
Next, a similar chain of profiles is created, only vlan with H.323 phones scrambles in access mode.
By analogy with the wired, a wireless profile is created with the entire chain, but we are also adding our avaya-voice access-list to the wireless role. This is how RAP setup from the web interface looks.
I also add that on RAP 5 there is a profile that assigns local settings when the connection to the central controller is disconnected. They must coincide with the settings on the controller created for this branch.
The piece of iron is interesting in itself. It is intended for small branches. In addition to the address of the central controller and the local connection settings, nothing else can be configured on it. She pulls up everything else from the controller as soon as she joins it. RAP 5 can be sent to remote offices by mail with instructions on how to drive the controller address into it, the rest will be done by the remote access point itself.
It was necessary to provide a quick connection to a remote office, ensuring the work of H.323 phones, SIP phones on iPhone and Android devices, mail, 1C, a printer and the Internet. In this case,
With a H.323 telephone, the vlan with the central office phones is completely forwarded, and a separate vlan with split-tunnel is configured on the wireless network and office computers so that traffic to the office and voice networks goes through the IPsec tunnel and the Internet works via a short route through the local provider.
I’ll immediately make a reservation that I do not consider here the initial configuration of the controller as a central router, the binding of points, the fine tuning of the wireless part and the completion of the security policy.
Aruba OS has a so-called role-based architecture. That is, any connected device, both wired and wireless, necessarily gets the role that a bunch of different profiles are tied to. The condition for obtaining the role is also configured by a separate profile. Despite the fact that the OS has a friendly web interface, initially the head goes around when you try to remember in which tab which profile is tied to which one. Therefore involuntarily you pass to cli.
Initially, we create an acces list, which will provide us with split tunneling.
We denote the office grid, and also indicate that if there is a vpn connection, dhcp will be distributed from the central controller.
ip access-list session rap-split-tunnel-policy-krasnodar
any network 192.168.10.0 255.255.255.0 any permit
any any svc-dhcp permit
any any any route src-nat
!
Now create the role to which we bind the acces list. First we allow all traffic.
user-role rap-split-tunnel-port-role-krasnodar
access-list session rap-split-tunnel-policy-krasnodar
access-list session allowall
!
Create an AAA profile and bind a role to it.
aaa profile rap-split-tunnel-aaa_prof-krasnodar
initial-role rap-split-tunnel-port-role-krasnodar
!
We create a wired profile and bind to it a vlan created specifically for our branch.
ap wired-ap-profile rap-split-tunnel-wired-ap_prof-krasnodar
wired-ap-enable
forward-mode split-tunnel
switchport access vlan 5
!
Profile for the port. We indicate which AAA profile is assigned to the device connected to the port.
ap wired-port-profile rap-split-tunnel-wired-port_prof-krasnodar
wired-ap-profile rap-split-tunnel-wired-ap_prof-krasnodar
no rap-backup
aaa-profile rap-split-tunnel-aaa_prof-krasnodar
!
We hang all the profiles on the first port of our RAP 5.
ap-group Krasnodar
enet1-port-profile rap-split-tunnel-wired-port_prof-krasnodar
!
An office computer was provided.
Now it's up to telephony, create a universal acces list with priority on voice.
ip access-list session avaya-voice
any any svc-sip-udp permit queue high tos 46 dot1p-priority 6
any any svc-sip-tcp permit queue high tos 46 dot1p-priority 6
any any svc-sips permit queue high tos 46 dot1ppriority 6
any any svc-h323-udp permit queue high tos 46 dot1p-priority 6
any any svc-h323-tcp permit queue high tos 46 dot1p-priority 6
any network 10.11.5.0 255.255.255.0 any permit queue high tos 46 dot1p-priority 6
network 10.11.5.0 255.255.255.0 any any permit queue high tos 46 dot1p-priority 6
any any svc-http permit queue high tos 46 dot1ppriority 6
any any svc-icmp permit
any any svc-dhcp permit queue high tos 46 dot1ppriority 6
any any svc-dns permit queue high tos 46 dot1ppriority 6
!
Next, a similar chain of profiles is created, only vlan with H.323 phones scrambles in access mode.
By analogy with the wired, a wireless profile is created with the entire chain, but we are also adding our avaya-voice access-list to the wireless role. This is how RAP setup from the web interface looks.
I also add that on RAP 5 there is a profile that assigns local settings when the connection to the central controller is disconnected. They must coincide with the settings on the controller created for this branch.