Category: Wifi

Bar guest wifi

The-WhittlerLeave a comment

Protip, try these PSK’s before asking at the bar or restaurant:

drinkmorebeer

coldbeer

icecoldbeer

Most businesses have guest wifi and it usually works smoothly. However, I’ve identified a design issue for a specific use case. Default DHCP settings and a standard /24 Subnet work well for many environments. But an area with hundreds or thousands of guests coming and going daily has unique needs. Some guests at my local sports bar had reported that they could not connect to the guest wifi but only on some of their devices. It’s usually a new device or someone who doesn’t visit often. I knew the cause was that we were running out IP’s as I had run into the same symptoms years prior. With a building max capacity of 500 guests, 254 IP’s, and a DHCP lease of 7 days doesn’t meet their needs.

Since most non-chain bars and restaurants will likely have limited IT resources I think a software solution from network vendors is needed. During the initial hardware setup, a series of questions should be asked to determine the network’s needs. For these high-traffic environments, I advise the following.

SSID “Company Name Guest”.

If you’re in a shared building that has overlapping wifi signals consider all companies using the same SSID for easy roaming.

Subnet size equal to the building max capacity multiplied by at least 2.

Lease timer 8 hours.

Name Servers 8.8.8.8 and 1.1.1.1.

Side note: Recently I was wondering why we even put passwords on guest wifi. I’m disappointed that I only now learned that open wifi does not encrypt the traffic. But at the same time, I’m happy as I can freely admit I didn’t know something and I got to learn something. I’ve seen the warnings but thought they were general “be safe in an unknown neighborhood” and not “everything is unencrypted”. But that does point to an opportunity to write about why that is and how we can change it. Without investigating, I think a certificate provided by the Access Point similar to how HTTPS works.

Securing the wired network with 802.1X

The-WhittlerLeave a comment

This post covers an innovation project I did to secure the wired network at a shared conf center with 802.1X.

Every few months we had to disable the wired network in order to prevent non-employees from being able to get online. This was not scalable, was prone to human error, and scheduling confusion. I planned to automate the process by enabling 802.1X aka dot1q on the switches using our Windows AD via Cisco ACS.

Any Domain joined devices that plugged in would get access to our corp VLAN, and unknown devices would go into a dead VLAN. Long term I planned to enable a wired guest VLAN and had it labbed out for non local switched wifi where the guest VLAN exists on the switch you’re connected to but didn’t around to labbing local switching using CAPWAP tunnels.

Wired Guest Access using Cisco WLAN Controllers Configuration Example:

http://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/99470-config-wiredguest-00.html

Phones would end up in the VoIP VLAN but they weren’t equipped for dot1x authentication. So I had two options either manually add each MAC address to a list in the ACS which is not scalable or supportable. Instead I removed the user VLAN from the ports with phones connected. The voice VLAN itself was locked down with a strict ACL that only allowed communication with the VoIP server.

Client configs:

In this environment there were only Windows clients. Windows needs to be configured to enable their supplicant for dot1x. Anything with Windows can and should be controlled by Group Policy. I researched the needed settings and how to set them via GPO. Then I worked with the Windows team to roll out the GPO to a pilot group and finally deploy globally.

Configuring 802.1X Wired Authentication on a Windows 7 Client:

https://documentation.meraki.com/MS/Access_Control/Configuring_802.1X_Wired_Authentication_on_a_Windows_7_Client

You can do the same thing with other versions of Windows just this was the one I worked with.

Windows AD GPO guide:

https://msdn.microsoft.com/en-us/library/dd759237.aspx

When these Win 7 machines were upgraded to Win 10 the GPO still worked.

 

Switch configs:

!Debug 802.1x all

!Debug radius all

conf t

aaa new-model

aaa authentication dot1x default group radius

aaa authorization network default group radius

aaa accounting network default start-stop group radius

dot1x system-auth-control

dot1x guest-vlan supplicant

radius server acs1.foo.com

 address ipv4 10.1.181.2 auth-port 1812 acct-port 1813

 key 0 This-IsTheSharedSecret123

exit

radius server acs2.foo.com

 address  ipv4 10.2.181.2 auth-port 1812 acct-port 1813

 key 0 This-IsTheSharedSecret123

exit

!User ports

interface <interface>

 authentication port-control auto

 authentication host-mode multi-domain

 dot1x pae authenticator

 authentication event no-response action authorize vlan 15

 authentication event fail action authorize vlan 15

!Phone ports

interface <interface>

no switchport access vlan 1010

end

copy run start

ACS Configs:

I already had the ACS configured to do dot1x auth for wifi clients so it was simple to just add the new switches to the rule set.

 

It was a success and opened the door to securing all wired networks.

Guest wifi and branch backup VPN redo

The-WhittlerLeave a comment

This post is about a situation I ran into a while ago and records my configs and testing for converting from a PBR setup to VRF on a Cisco 881 router with a diagram at the end.

Through a combination of configs involving PBR (Policy Based Routing) AKA Source Routing (as opposed to standard Destination Routing), Proxy Server exceptions, and Default Route/missing Default Route it was impossible to get to internet facing apps/sites over guest wifi or branch backup VPN.

I knew I could use VRF’s (Virtual Routing and Forwarding) to separate the traffic and solve the issue, but had to prove it to my team as they weren’t familiar with VRF’s. A Cisco router without VRF’s built only has the “global routing table”. VRF’s create separate instances of routing tables; one for each VRF, while leaving the global in place.

IOS-XE comes with a mgmt-intf VRF by default for a separate management network. Carriers use VRF’s, or contexts in some non Cisco hardware, to keep customers traffic separate and allow for overlapping network schemes. If needed you can “leak routes” between VRF’s and/or the global routing table. This would be done if the carrier has something like a network monitoring server that needs to access customer devices.

I used a post by Jeremy Stretch at packetlife.net as a guide and to show that someone smarter than me confirmed the design. http://packetlife.net/blog/2012/sep/4/simultaneous-tunneled-and-native-internet-access/

Jeremy’s post goes into the details of building everything from the base up.

 

Testing:

Test from a computer on guest wifi:

C:\Users\>tracert google.com

Tracing route to google.com [172.217.5.78]

over a maximum of 30 hops:

  1 81 ms   139 ms 251 ms  172.17.1.1
  2  152 ms 35 ms 29 ms  [10.1.180.1]
  3  520 ms   173 ms 652 ms  [10.254.254.161]
  4  4 ms     6 ms  7 ms  [****]
  5  8 ms  5 ms    15 ms [****]
  6 12 ms 10 ms  6 ms  144.228.109.65
  7 34 ms   166 ms 219 ms  sl-mpe50-sea-.sprintlink.net [144.232.3.126]
  8  662 ms   638 ms 849 ms  72.14.242.31
  9  572 ms 45 ms  9 ms  108.170.245.115
10   578 ms   995 ms 370 ms  66.249.94.201
11   955 ms   618 ms 507 ms  209.85.240.228
12   268 ms   457 ms 447 ms  216.239.54.158
13   358 ms   342 ms 638 ms  216.239.51.124
14    61 ms 71 ms 51 ms  108.170.247.193
15    56 ms 88 ms 68 ms  108.170.237.113
16    55 ms 32 ms 44 ms  172.217.5.78

Trace complete.

Test from a computer on the regular corp wifi or LAN:

C:\Users\>tracert google.com

Tracing route to google.com [172.217.5.78]

over a maximum of 30 hops:
  1 12 ms  5 ms 11 ms  192.168.2.1
  2  5 ms  5 ms  3 ms  10.3.254.1 < --- Headend Tunnel interface
  3 10 ms  4 ms     5 ms [10.254.254.161]
  4 17 ms  2 ms     9 ms [***]
  5  6 ms  4 ms  4 ms  [****]
  6 10 ms  3 ms     7 ms 144.228.109.65
  7  6 ms  2 ms  2 ms  sl-mpe50-sea-.sprintlink.net [144.232.3.126]
  8  5 ms  4 ms     5 ms 72.14.242.31
  9  7 ms  4 ms  3 ms  108.170.245.115
10     9 ms 12 ms  9 ms  66.249.94.201
11    10 ms 29 ms 26 ms  209.85.240.228
12    34 ms 54 ms 59 ms  216.239.54.158
13    32 ms 32 ms 32 ms  216.239.51.124
14    30 ms 31 ms 30 ms  108.170.247.193
15    33 ms 30 ms 29 ms  108.170.237.113
16    38 ms 31 ms 40 ms  172.217.5.78

Trace complete.

 

Config differences:

ADD config:

First you have to create a named VRF. Some people use all caps for VRF names to make them stand out. I don’t because it’s a pain when you want to ping, trace, or use any VRF specific commands.

!The VRF names doesn’t matter but fdoor relates to Front Door VRF sometimes used with DMVPN. It separates the base routing and the “overlay routing” used by the VPN. You could also put all interfaces in VRF’s and not use the global routing table but I didn’t.

!Create the VRF.
!
ip vrf fdoor
!
!Required to support DHCP when using VRF’s.
no ip dhcp use vrf connected
!
!Place the internet interface in the VRF
interface <internet-interface>
ip vrf forwarding fdoor
!
!Place the guest interface in the VRF
interface vlan15
ip vrf forwarding fdoor
!
!Tell the tunnel to use the VRF for its source interface.
Interface <tunnel-number>
tunnel vrf fdoor

CHANGE config:

!The NAT needs to be told about the VRF.
!Change this:
ip nat inside source list 130 interface <internet-interface> overload
!
!To this:
ip nat inside source list 130 interface <internet-interface> vrf fdoor match-in-vrf fdoor overload
!The default route needs to be moved to the VRF.
!Change from this:
ip route 0.0.0.0 0.0.0.0 <internet-interface> <internet-gw>
!
!To this:
ip route vrf fdoor 0.0.0.0 0.0.0.0 <internet-interface> <internet-gw>

REMOVE config:

!
interface Vlan10
no ip policy route-map wifi-mgmt-route-map 
!
!
interface Vlan30
no ip policy route-map wifi-guest-route-map
!
!
interface Vlan36
no ip policy route-map LAN-route-map
!
!
no route-map wifi-mgmt-route-map permit 10
 !match ip address CAPWAP-traffic
 !set ip precedence flash-override
 !set ip next-hop <branch-LAN-gw>
!
no route-map LAN-route-map permit 10
 !match ip address all-except-localwifi
 !set interface Tunnel1999
!
no route-map wifi-guest-route-map permit 10
 !match ip address 130
!
!These routes are not needed as we have dynamic routes for the tunnel and a static default route for internet access in the fdoor VRF.
no ip route 0.0.0.0 0.0.0.0 vlan33 <branch-LAN-gw> 254
no ip route <DNS1> 255.255.255.255 <internet-interface> <internet-gw>
no ip route <DNS2> 255.255.255.255 <internet-interface> <internet-gw>

As you can see you end up with less configs and better routing. I was able to convert a few hundred of these setups over a few weeks with old school copy pasta. But it I had to do this again I’d spend time on a Python script that would convert, test, and document the results.