WiNG 5.3

© 2012 Motorola Solutions Proprietary & Confidential WiNG 5.3 Training Agenda Layer 2 Enhancements: Tunnel-Controller Load Balancing L2TPv3 Layer 2 NAT IGMP Snooping Layer 3 Enhancements: Policy Based Routing NAT Load Balancing / Failover OSPF VRRP Critical Resource Monitoring Default Gateway Prioritization PPPoE Client Security Enhancements Security Enhancements: IPsec VPN Auto IPsec Secure © 2012 Motorola Solutions Proprietary & Confidential 2

Layer 2 Enhancements

Tunnel-Controller Load Balancing Overview Introduces support for load-balancing Extended VLANs between a cluster of Controllers Must be enabled on both the Controllers and Access Points (Profile or Override) Intended for Layer 2 or Layer 3 Adopted 802.11n Access Points Disabled by default Allows 802.11n Access Points to operate in a similar manner to AP300 / AP650 Access Points in WiNG 4.x Controller Controller Controller Controller AP AP AP AP Switch Switch AP AP AP AP No Tunnel Load Balancing With Tunnel Load Balancing © 2012 Motorola Solutions Proprietary & Confidential 4

Layer 2 Tunneling Protocol v3 Overview L2TPv3 is an IETF standard used for transporting different types of layer2 frames over an IPv4 network Supports two peers per tunnel Primary peer preferred over secondary peer L2TPv3 can be deployed to transport Ethernet frames between supported Access Points devices to third-party Router or Concentrator Tunnel wireless user traffic to a third-party Router in the DMZ Tunnel wireless user traffic from Access Points to different service provider Routers In WiNG 5.3 L2TPv3 support is only provided for certain Access Points L2TPv3 Tunnel Termination on Integrated Services Controllers will be introduced in WiNG 5.4. © 2012 Motorola Solutions Proprietary & Confidential 5

Layer 2 Tunneling Protocol v3 Configuration Example – Topology Configuration Example Notes: In this example VLAN 30 is being tunneled using L2TPv3 from AP7131 Access Points to a third-party Router over an intermediate IP network. Users traffic connected to a WLAN mapped to VLAN 30 is tunneled to the third-party router. L2TPv3 Tunnels from AP7131N Access Points to a Third-Party Router © 2012 Motorola Solutions Proprietary & Confidential 6

© 2012 Motorola Solutions Proprietary & Confidential Layer 2 NAT Overview In branch Extended VLAN environments, if an MU wants to browse Internet or communicate with a local service at the branch site (i.e. Printer, File Server etc), the MUs packets travel all the way to the Data Center where the Wireless Controllers and default router resides: All traffic traverses the WAN or VPN connection A work around is for the MU to connect to a separate VLAN with Local Bridging but requires the user to switch Wireless LANs Layer 2 NAT and Policy Based Routing features in WiNG 5.3 address this limitation: Allows Internet traffic to be forwarded locally at the Branch while corporate traffic is forwarded to the Data Center over the Extended VLAN Allows users to access Printers and Servers deployed at the Branch without traversing the WAN Similar concept to Split Tunneling with IPsec VPN © 2012 Motorola Solutions Proprietary & Confidential 7

© 2012 Motorola Solutions Proprietary & Confidential Layer 2 NAT Configuration Example – Topology Configuration Example Notes: In this configuration example the AP7131 is adopted over VLAN 21 and its users connected to the WLAN are tunneled to the NOC on VLAN 23. The Access Point has a local VLAN 30 which local to the branch. An ACL has been defined for L2NAT which: Ignores traffic destined to Application servers on the 192.168.10.0/24 subnet in the Data Center Ignores traffic destined to other hosts on the 192.168.23.0/24 subnet (Extended VLAN) NATs traffic destined to Printers etc on the local subnet 192.168.30.0/24 NATs traffic destined to the Internet IP Routes have been defined on the AP7131 which: Points to the local branch routers IP interface on VLAN 30 as the default gateway Points to the corporate routers IP interface on VLAN 23 to reach the Controller and Applications © 2012 Motorola Solutions Proprietary & Confidential 8

© 2012 Motorola Solutions Proprietary & Confidential IGMP Snooping Overview IGMP snooping provides efficient multicast delivery and bandwidth conservation mechanism for layer 2 devices The layer 2 device only forwards Multicast groups out of ports / radios where group members are present and not to non member ports / radios The Layer 2 device monitor IGMP membership reports (joins / leaves) and builds a IGMP table mapping groups to host ports / radios When disabled multicast forwarding behavior varies by vendor Layer 2 devices may flood known and unknown IP Multicast groups to all ports in the broadcast domain Layer 2 devices may suppress known Multicast groups until a single receiver joins a specific Multicast group © 2012 Motorola Solutions Proprietary & Confidential 9

© 2012 Motorola Solutions Proprietary & Confidential IGMP Snooping Configuration Example – Topology Configuration Example Notes: In this configuration example the AP6532s are adopted over VLAN 21 and its users connected using 2.4Ghz to the WLAN with the locally bridged VLAN 22. A Multicast source is present on the network serving groups 239.0.0.1 and 239.0.0.2. When no multicast receivers are active, no Multicast groups are forwarded to the Access Points. When one multicast receiver is present on a Access Point on VLAN 22, the multicast group is forwarded to all associated users assigned to VLAN 22. When all multicast receivers leave, the multicast group is pruned. © 2012 Motorola Solutions Proprietary & Confidential 10

© 2012 Motorola Solutions Proprietary & Confidential WiNG 5.3 Training Agenda Layer 2 Enhancements: Tunnel-Controller Load Balancing L2TPv3 Layer 2 NAT IGMP Snooping Layer 3 Enhancements: Policy Based Routing NAT Load Balancing / Failover OSPF VRRP Critical Resource Monitoring Default Gateway Prioritization PPPoE Client Security Enhancements Security Enhancements: IPsec VPN Auto IPsec Secure © 2012 Motorola Solutions Proprietary & Confidential 11

Layer 3 Enhancements

© 2012 Motorola Solutions Proprietary & Confidential Policy Based Routing Overview The current routing infrastructure in WiNG utilizes destination based routing Traffic is forwarded to the next hop based on best match in the routing table Policy Based Routing allows administrators to route traffic in ways that go beyond the traditional destination based routing: Allows select traffic to be routed using criteria such as source / destination address, protocol, application and traffic class (DSCP) Allows traffic to be load-balanced across multiple WAN links Allows traffic to be selectively marked for QoS purposes © 2012 Motorola Solutions Proprietary & Confidential 13

© 2012 Motorola Solutions Proprietary & Confidential Policy Based Routing Route-Maps Match Clauses Match clauses are used to select traffic: IP Access List – Traffic matching permit rules will be subjected to PBR; those matching deny rules will be subjected to destination based routing IP DSCP – DSCP value in the IP header of packets Incoming WLAN – Applicable only on platforms with on-board radio (RFS4000 and AP71xx) Wireless Client ROLE – Applicable only on platforms with on-board radio (RFS4000, AP71xx) Incoming Interface – Ingress layer 3 interface (VLAN, PPPoE, WWAN) If a route-map has no match clauses, then it shall match all traffic © 2012 Motorola Solutions Proprietary & Confidential 14

© 2012 Motorola Solutions Proprietary & Confidential Policy Based Routing Configuration Example – Topology Configuration Example Notes: In this example a Integrated Services Controller is connected to VLAN 30 (192.168.30.1/24) and the wireless users are mapped to Extended VLAN 31 (192.168.31.0/24). The branch has a corporate branch router (192.168.30.2/24) which connects the branch to the corporate network in addition to a direct DSL internet connection (VLAN 4094). The Integrated Services Controller has a default route defined which points to the branch router and by default all traffic is forwarded over the private WAN. The customer wishes to have corporate traffic forwarded over the private WAN and Internet traffic forwarded through the local Internet router. A routing policy will be defined that will: Forward traffic from the 192.168.31.0/24 network destined to the corporate network (192.168.10.0/24) through the local branch router. Forward traffic from the 192.168.31.0/24 destined to the DSL Internet connection. © 2012 Motorola Solutions Proprietary & Confidential 15

NAT Load-Balancing / Failover Overview NAT has been enhanced to support multiple overloaded interfaces which can be used for Load-Balancing and Failover Failover – High-availability based on Default Gateway Prioritization & Critical Resource Monitoring Load-Balancing – Leverages Policy Based Routing to forward traffic across over Internet connections Each NAT rule can contain multiple interfaces (in any order): Virtual IP Interfaces PPPoE Interface WWAN Interface Enables high-available remote branch deployments as well as flexible traffic forwarding © 2012 Motorola Solutions Proprietary & Confidential 16

Open Shortest Path First (OSPFv2) Overview Dynamic routing protocol OSPFv2 is supported in WiNG 5.3 release OSPF implementation compliant with RFC 2328 OSPF supported on broadcast (VLAN) interfaces Maximum number of dynamic routes supported is limited by the routing table size supported on individual platform Supports ABR, ASBR, Stub, Totally Stub, NSSA, Totally NSSA Supports route redistribution and route summarization Only static and connected routes can be re-distributed into OSPF Interacts with VRRP by only advertising via VRRP master Interacts with Policy Based Routing © 2012 Motorola Solutions Proprietary & Confidential 17

Open Shortest Path First (OSPFv2) Standard Area Types © 2012 Motorola Solutions Proprietary & Confidential 18

Open Shortest Path First (OSPFv2) Configuration Example – Topology Configuration Example Notes: In this example an RFSX000 is connected to VLAN 20 and has three IP interfaces defined. VLAN 20 has a core router (192.168.20.1) in OSPF Area 0.0.0.0 which allows the RFSX000 to receive routing information from the core (including its default gateway). The Virtual IP Interfaces VLAN 30 (192.168.30.1/24) and VLAN 31 (192.168.31.1/24) are connected to Area 0.0.0.1 which aggregates back to the core. © 2012 Motorola Solutions Proprietary & Confidential 19

Virtual Router Redundancy Protocol (VRRP) Overview Provides default gateway redundancy for branch office deployments Allows our Wireless Controllers / Access Points to provide default gateway services to users in the event of a primary Router failure (i.e. failover to 3G) VRRP version 2.0 (RFC 3768) and version 3.0 (RFC 5798) are supported Default is version 2.0 Version 3.0 supports sub-second failover but very few vendors support it for IPv4 (i.e. primarily implemented for IPv6) Proprietary implementation in Version 2.0 to support sub-second failover (i.e. advertisement interval can be specified in msec) This feature was added, since most vendors support this for providing sub-second failover By default advertisement interval is set to 1 second © 2012 Motorola Solutions Proprietary & Confidential 20

Virtual Router Redundancy Protocol (VRRP) Overview Cont. Supports failover in case of WAN link failover on WING or third-party Router If the backup router detects that the WAN link in master is down, then it will become a new VRRP master When the link comes get restored, the VRRP master will transition back to a backup state All services (DHCP, RADIUS, NAT, and VPN) running over virtual IP are supported For DHCP relay, one can point to the DHCP server as virtual IP For VPN, on the initiator side, remote peer can be configured as virtual IP © 2012 Motorola Solutions Proprietary & Confidential 21

Virtual Router Redundancy Protocol (VRRP) Configuration Example – Topology Configuration Example Notes: In this configuration example VRRP is enabled on VLANs 20 and 30 on both RFX6000-1 and RFSX000-2 using the virtual IP addresses 192.168.20.254 and 192.168.30.254. RFSX000-1 is configured to be the VRRP master (priority 254) while RFSX000-2 is configured with a default priority (128) which becomes the VRRP backup. In addition Critical Resource Monitoring is enabled on RFSX000-1 which checks the next-hop gateway on VLAN 20 (192.168.20.1). If the next-hop gateway fails, the VRRP priority on RFSX000-1 for both VLANs in reduced by 128 allowing RFSX000-2 to become the VRRP master for both VLANs. © 2012 Motorola Solutions Proprietary & Confidential 22

Critical Resource Monitoring Overview Used to monitor user defined IP addresses / links for liveliness Monitoring is done by ARP and ICMP ping requests Resources can be monitored via: IP Address – If the gateway address is statically configured Interface – If the gateway address is dynamically learned from DHCP or PPPoE Up to four sets of critical resources can be defined: Under each resource, up to four IP addresses can be configured for monitoring User can choose to take action when all resources in a set are down or when any of the resources is down VRRP, Policy Based Routing and Default Route Prioritization can all leverage the results of CRM User can configure critical resources to be: Monitored via an IP address (if the gateway address is statically configured) VIA an interface (if the gateway address is dynamically learnt via DHCP or PPP) © 2012 Motorola Solutions Proprietary & Confidential 23

Default Gateway Prioritization Overview WiNG 5.3 devices can learn a default gateway via: Static Route DHCP Client (Virtual IP Interface) PPPoE / WWAN OSPF Feature allows administrators to prioritize the Default Gateways learnt via the above means The default gateway with lowest priority shall be installed on the system All learned default gateways are monitored for liveliness In case a default gateway becomes unreachable, the next preferred gateway is installed on the system. Whenever the old gateway becomes online, it is restored The default order of preferred gateways is Static Route, DHCP Client, PPPoE, WWAN and OSPF This feature is available on all WiNG 5.X platforms © 2012 Motorola Solutions Proprietary & Confidential 24

Default Gateway Prioritization Default Priorities Each Interface can be assigned a priority from 1 – 8,000: The default gateway with the lowest priority is installed! Default Gateway Learned By Default Priority Static Route 100 DHCP Client 1,000 PPPoE 2,000 3G WAN 3,000 OSPF 7,000 © 2012 Motorola Solutions Proprietary & Confidential 25

© 2012 Motorola Solutions Proprietary & Confidential PPPoE Client Overview Many Internet service providers (ISPs) are using the Point-to-Point Protocol over Ethernet (PPPoE) to provide Digital Subscriber Link (DSL) broadband Internet access PPPoE uses a standard methods of encryption, authentication, and compression specified by the Point-to-Point Protocol (PPP) Implementing a PPPoE client allows a WiNG 5.X device to connect to the ISP over an Ethernet interface Uses the interface name pppoe1 Interface supports Firewall and Crypto policies as well as NAT A PPPoE client interface can be defined within a Device Profile or directly to a device as a Device Override Interface configuration MUST include the VLAN ID the DSL modem is connected to! © 2012 Motorola Solutions Proprietary & Confidential 26

© 2012 Motorola Solutions Proprietary & Confidential WiNG 5.3 Training Agenda Layer 2 Enhancements: Tunnel-Controller Load Balancing L2TPv3 Layer 2 NAT IGMP Snooping Layer 3 Enhancements: Policy Based Routing NAT Load Balancing / Failover OSPF VRRP Critical Resource Monitoring Default Gateway Prioritization PPPoE Client Security Enhancements Security Enhancements: IPsec VPN Auto IPsec Secure © 2012 Motorola Solutions Proprietary & Confidential 27

Security Enhancements

© 2012 Motorola Solutions Proprietary & Confidential IPsec VPN Overview WiNG 5.3 re-introduces support for standards based IPsec VPN on select WiNG 5.X Access Points Site-to-Site VPN Remote VPN Host to Host Remote VPN support added to Controllers! Can be used when MINT and/or user traffic needs to be secured over an IPv4 network Access Point  Controller within a site or over a Public network Branch Offices Remote Teleworkers Secure communications to specific hosts (i.e. Controller  RADIUS or LDAP) Completely new IPsec implementation which integrates tightly with NAT and VRRP in addition to providing support for redundant peers © 2012 Motorola Solutions Proprietary & Confidential 29

© 2012 Motorola Solutions Proprietary & Confidential IPsec VPN VPN Configuration Example 1 – Topology Configuration Example Notes: In this example RFSX000-1 is configured to provide Remote VPN services to user using a generic VPN client. The users are authenticated against a local user database and once authenticated the VPN client will negotiate a IPsec AES end-user tunnel and will receive an IP address form the internal pool 192.168.100.0/24. © 2012 Motorola Solutions Proprietary & Confidential 30

© 2012 Motorola Solutions Proprietary & Confidential IPsec VPN VPN Configuration Example 2 – Topology Configuration Example Notes: In this example RFSX000-1, RFSX000-2 and WS2000-1 are connected over a public network using an IPsec VPN tunnel. ACLs are defined on each device to match specific traffic which is encrypted over the tunnel: RFSX000-1 - An ACL named Site2 is defined that matches traffic from the 192.168.1/24 network destined to 192.168.2.0/24. RFSX000-1 - An ACL named Site3 is defined that matches traffic from the 192.168.1/24 network destined to 192.168.3.0/24. RFSX000-2 - An ACL named Site1 is defined that matches traffic from the 192.168.2.0/24 network destined to 192.168.1.0/24. RFSX000-2 - An ACL named Site3 is defined that matches traffic from the 192.168.2.0/24 network destined to 192.168.3.0/24. In addition as each RFSX000 is performing NAT, deny rule have been defined in the NAT ACL so that IPsec traffic destined to the remote site is not NATTed by the RFSX000s: RFSX000-1 - An ACL named NAT is defined that denies traffic destined to the 192.168.2.0/24 and 192.168.3.0/24 networks but permits traffic destined to the Internet. RFSX000-2 - An ACL named NAT is defined that denies traffic destined to the 192.168.1.0/24 and 192.168.3.0/24 networks but permits traffic destined to the Internet. © 2012 Motorola Solutions Proprietary & Confidential 31

© 2012 Motorola Solutions Proprietary & Confidential Auto IPsec Secure Overview IPsec security for AP to Controller, Controller to Controller traffic , with minimal configuration: Set up IPsec tunnel based on configured list of controller host Set up IPsec tunnel based on statically configured link configuration No explicit traffic selector configured by user. Traffic selector internally derived! No explicit transform set configured by user! Only credentials configured is identity and authentication credentials! © 2012 Motorola Solutions Proprietary & Confidential 32

© 2012 Motorola Solutions Proprietary & Confidential Auto IPsec Secure Configuration Example – Topology © 2012 Motorola Solutions Proprietary & Confidential 33

Q&A