Consider a customer’s network that has many branches that serves WiFi clients, and you have sensitive public data internally or you are a public sector entity, and you have strict requirements to completely isolate the “Guest” SSID used to access the Internet from the internal network and any other internal SSIDs. At the same time, you have requirements to apply policies over the guest network, such as IPS, URL filtering, AMP and so on with the most cost-effective solution in terms of both operation and TCO.
There are several ways to achieve that, ranging from deployment of Anchor/Guest controllers, NGFW, SDWAN, and so on, but this can add a lot of operational overheads in case you have many branches, not to mention increased costs in running and maintaining the extra hardware.
Looking at how we can address the above :
- You need the most secure way to isolate the Gues/Internet from the internal network. I can only think of separate L2 and L3 VRFs, possibly solutions like Anchor Controllers, EoGRE or any other centralized tunneling to HQ for example might work.
- Guest/Internet Security: SDWAN and NGFW solutions can fully satisfy the requirements, but we still need to buy new hardware and subscriptions and manage them.
- Cost Effectiveness: Utilize the same wireless network without the need to build a separate isolated network for guests, if there is a way to satisfy requirements without adding extra hardware, it would be great.
Cisco Secure Access provides traffic monitoring and inspection and provides NGFW capabilities at layers 3–7 and drops unsafe packets. Secure web gateway inspects web traffic, including encrypted files, for protection. Files are scanned, known malicious content is blocked, and unknown files are sandboxed and analyzed. Controls can block specific activities and destinations that violate policy
In this demo, we will do the following:
- We will use a Local WLC in each site running in local mode.
- We will isolate the “Guest” SSID in separate VRF along with another isolated Front End Internet VRF.
- We will integrate the WLC with Cisco Secure Access and place the Tunnel towards Secure Access/Internet in the Guest VRF.
- Secure Access is flexible, you can easily extend this secure Internet access to cover private access to applications, ZTNA, client or clientless-based access and many others.
Advantage of such implementation is that remote branches only need a WLC and Access Points. There is no need for any complicated dedicated security devices to be implemented in each branch, and you can utilize Cisco Secure Access running in cloud as the main platform for security. Although internal employees’ access can still be processed through Secure Access for private access, we will assume that there is already a sort of WAN/Intranet connection.
Assuming you have access to Cisco Secure Access and already configured the tunnel parameters (Public IP’s of primary and secondary tunnels of Secure Access, tunnel identity, and passphrase), the related main Crypto configs are as follows:
vrf definition Guest
address-family ipv4
exit-address-family
vrf definition Internet
address-family ipv4
exit-address-family
Here, we have created two VRFs; the "Guest" VRF, which will be mapped to the Guest SSID, and also create the "Internet", which represents the Front End VRF, which is simply a VRF that has only static route towards the Internet and no path towards any sort of client subnets, even for the Guests. The Front VRF ip routing table is simple, only the local subnet towards the Internet and a static route towards the Intenret:
WLC(config)#ip route vrf Internet 0.0.0.0 0.0.0.0 192.90.90.1
WLC#sh ip route vrf Internet
Gateway of last resort is 192.90.90.1 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 192.90.90.1
192.90.90.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.90.90.0/24 is directly connected, GigabitEthernet3
L 192.90.90.2/32 is directly connected, GigabitEthernet3
Let's have a look at how the crypto CLI related are configured towards Cisco Secure Access, notice the power of IOS XE in being VRF aware of IPSEC Virtual Tunnel Interfaces (VTI):
sh run | sec crypto
crypto ikev2 proposal sse-proposal
encryption aes-gcm-256
prf sha256
group 20
crypto ikev2 policy sse-pol
match fvrf Internet
proposal sse-proposal
crypto ikev2 keyring sse-keyring
peer sse
address 3.29.140.80
pre-shared-key XXXXXXXXXX
peer sse2
address 3.29.180.139
pre-shared-key XXXXXXXXXX
crypto ikev2 profile sse-ikev2-profile-tunnel1
match fvrf Internet
match identity remote address 3.29.140.80 255.255.255.255
identity local email demotunnel@xxxxxxxxxxx-sse.cisco.com
authentication remote pre-share
authentication local pre-share
keyring local sse-keyring
dpd 10 2 periodic
crypto ikev2 profile sse-ikev2-profile-tunnel2
match fvrf Internet
match identity remote address 3.29.180.139 255.255.255.255
identity local email demotunnel@xxxxxxxxxxx-sse.cisco.com
authentication remote pre-share
authentication local pre-share
keyring local sse-keyring
dpd 10 2 periodic
crypto ipsec transform-set sse-transform esp-gcm 256
mode tunnel
crypto ipsec profile sse-ipsec-profile-1
set transform-set sse-transform
set ikev2-profile sse-ikev2-profile-tunnel1
crypto ipsec profile sse-ipsec-profile-2
set transform-set sse-transform
set ikev2-profile sse-ikev2-profile-tunnel2
What is left is to look at the VTI tunnel interfaces themselves:
interface Tunnel1
vrf forwarding Guest
ip unnumbered GigabitEthernet3
ip tcp adjust-mss 1350
tunnel source GigabitEthernet3
tunnel mode ipsec ipv4
tunnel destination 3.29.140.80
tunnel vrf Internet
tunnel protection ipsec profile sse-ipsec-profile-1
interface Tunnel2
vrf forwarding Guest
ip unnumbered GigabitEthernet3
ip tcp adjust-mss 1350
tunnel source GigabitEthernet3
tunnel mode ipsec ipv4
tunnel destination 3.29.180.139
tunnel vrf Internet
tunnel protection ipsec profile sse-ipsec-profile-2
Notice that the tunnel themselves are assigned to the Guest VRF, and they are using a Front End VRF to access the destination of the tunnel. Looking at the routing table below, we can clearly see how we are indeed maintaining high level of security:
WLC#sh ip route vrf Guest
Routing Table: Guest
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
H - NHRP, G - NHRP registered, g - NHRP registration summary
o - ODR, P - periodic downloaded static route, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
& - replicated local route overrides by connected
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
S* 0.0.0.0/0 is directly connected, Tunnel1
5.0.0.0/32 is subnetted, 1 subnets
C 5.5.5.5 is directly connected, Loopback100
9.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 9.9.9.0/24 is directly connected, Vlan99
L 9.9.9.9/32 is directly connected, Vlan99
Vlan 99 is simply the one that is mapped to the Guest SSID, and loopback 100 is a dummy loopback that exist in the Guest VRF for testing only. Note that we have a static route towards the tunnels, one as primary, and another as secondary in case of failure of the 1st one.
WLC#sh run | sec ip route vrf Guest
ip route vrf Guest 0.0.0.0 0.0.0.0 Tunnel1
ip route vrf Guest 0.0.0.0 0.0.0.0 Tunnel2 200
WLC#
Now that the tunnels are up, let's test some ICMP traffic from the dummy loopback in the Guest VRF.
WLC#ping vrf Guest 8.8.8.8 source loopback 100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 5.5.5.5
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 11/12/15 ms
WLC#
Now that we are routing towards Secure Access, you can now build your policies accordingly in the cloud, but let's have a look at our ping from Secure Access:
Thanks Vasily for giving us access to Secure Access
3 Comments
