Aruba OS 6.1 and Split Tunnel on RAP 5
Good day. You may have heard about Aruba Networks. I want to share with you a little experience in setting up. The most interesting for me was setting up a profile for RAP 5 (Remote Access Point).
The piece of iron itself is interesting. It is designed for small branches. In addition to the address of the central controller and the local connection settings, nothing else can be configured on it. All the rest it pulls up from the controller as soon as it joins it. RAP 5 can be sent to remote offices by mail with instructions on how to drive the controller's address into it, the rest of the access point will do it itself.
')
It was necessary to provide fast connection to a remote office, ensuring the work of H.323 phones, SIP phones on iPhone and Android devices, mail, 1C, printer and the Internet. At the same timeVKontakte Internet should not work through the central office.
The H.323 phone has a full vlan with the central office phones, and a separate split-tunnel vlan is configured for the wireless network and office computers so that traffic to the office and voice network goes through the IPsec tunnel and the Internet works along a short route through a local provider.
I’ll just make a reservation that I don’t 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 finishing of the security policy.
Aruba OS has a so-called role-based architecture. That is, any connected device, both wired and wireless, necessarily receives a role for which a bunch of different profiles are tied. The condition for obtaining a role is also configured by a separate profile. Despite the fact that the OS has a friendly web interface, initially the head is spinning when you try to remember in which tab which profile is attached to which profile. Therefore, involuntarily switch to cli.
Initially, we create acces list, which will provide split tunneling to us.
We denote the office grid, and also indicate that in the presence of a vpn connection, dhcp will be distributed from the central controller.
Now we create the role to which we bind acces list. First, allow all traffic.
Create an AAA profile and assign a role to it.
We create a wired profile and bind to it a vlan, created specifically for our branch.
Profile for the port. Specify which AAA profile will be assigned to the device connected to the port.
We hang all the profiles on the first port of our RAP 5.
The work of the office computer provided.
Now it's up to telephony, creating a universal acces list with priority to voice.
Next, a similar profile chain is created, only vlan with H.323 phones is prokibyvaetsya in access mode.
By analogy with the wired, a wireless profile is created with the entire chain, but we also add our avaya-voice access-list to the wireless role. This is how the RAP configuration 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 broken. They must coincide with the settings on the controller, created under this branch.
The piece of iron itself is interesting. It is designed for small branches. In addition to the address of the central controller and the local connection settings, nothing else can be configured on it. All the rest it pulls up from the controller as soon as it joins it. RAP 5 can be sent to remote offices by mail with instructions on how to drive the controller's address into it, the rest of the access point will do it itself.
')
It was necessary to provide fast connection to a remote office, ensuring the work of H.323 phones, SIP phones on iPhone and Android devices, mail, 1C, printer and the Internet. At the same time
The H.323 phone has a full vlan with the central office phones, and a separate split-tunnel vlan is configured for the wireless network and office computers so that traffic to the office and voice network goes through the IPsec tunnel and the Internet works along a short route through a local provider.
I’ll just make a reservation that I don’t 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 finishing of the security policy.
Aruba OS has a so-called role-based architecture. That is, any connected device, both wired and wireless, necessarily receives a role for which a bunch of different profiles are tied. The condition for obtaining a role is also configured by a separate profile. Despite the fact that the OS has a friendly web interface, initially the head is spinning when you try to remember in which tab which profile is attached to which profile. Therefore, involuntarily switch to cli.
Initially, we create acces list, which will provide split tunneling to us.
We denote the office grid, and also indicate that in the presence of 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 we create the role to which we bind acces list. First, 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 assign 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. Specify which AAA profile will be 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 ! The work of the office computer provided.
Now it's up to telephony, creating a universal acces list with priority to 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 profile chain is created, only vlan with H.323 phones is prokibyvaetsya in access mode.
By analogy with the wired, a wireless profile is created with the entire chain, but we also add our avaya-voice access-list to the wireless role. This is how the RAP configuration 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 broken. They must coincide with the settings on the controller, created under this branch.
Source: https://habr.com/ru/post/166037/
All Articles