• pfSense SG-1000 running 2.4 BETA
• Cisco VIRL — Core 0.10.29.12
• VMWare ESXi 5.5 Update 1
• Generic VLAN Aware Layer 2 Switching

I will not go through the entire installation of Cisco VIRL. I am just going to go through what I do in my personal environment to allow the FLAT & FLAT2 networks to be routable to the world. I have the SNAT network setup in a similar fashion, but I do not often use it so I will only mention SNAT this once.

I will also not go through the process of adding VLANs and interfaces to the pfSense SG-1000. If this is something you would like me to cover in more detail just leave a comment or shoot me a tweet and I would be glad to help you out!

Instead of using the stock 172.16.1.0/24 & 172.16.2.0/24 FLAT networks, I have updated the VIRL configuration for my local environment. This evolved changing the second octet from 16 to 23. Once that is completed I saved the changes in the VIRL admin portal and allowed it to go through the LENGTHY process of reconfiguration. This takes a while…grab a drink…

After that I setup a VLAN (I used 200) and assigned it to an new interface on my pfSense SG-1000. I then give that interface the gateway IP of the FLAT network (172.23.1.0/24) and enable:

After everything is saved I added the FLAT2 gateway as a secondary virtual IP on the same interface:

After this configuration is done all that is left is to add a rule to allow traffic to pass through the interface. The last rule in this list in the one that allows all traffic originating on the Interface to access the Internet. The top three rules are added by pfBlockerNG, a package I highly recommend if you are a pfSense user!

Note…you DO NOT need to enable DHCP on your pfSense box! DHCP is handled by the VIRL system.

Ok, now all the pfSense prep is complete! Take the time to trunk your new VLAN through your infrastructure and into your VMWare environment. Once the VLAN is in ESXi it is as easy as applying the VLAN to the FLAT and FLAT2 interfaces on your VIRL VM. In most cases this is Network adapters 2 & 3:

Once this is complete you should be able to ping the gateway IPs from the FLAT (br1) and FLAT2 (br2) interfaces:

Great! Now…how do you use this in a simulation? I created a quick two nod simulation to show the usage. The main thing to pay attention to is the use of the “Shared flat network” setting in the Management Network dropdown while you are designing your sim. You get to this Properties screen by clicking the background in the simulation window:

Now save your sim and launch it. Once you launch the sim you will see that the nodes show “ACTIVE — UNREACHABLE”. Also, if you right click on the device and hover over “Telnet…” you will see that a 172.23.1.X IP has been assigned to the management port on the device:

While the IP is assigned to the device, it is not automatically configured on the device. If you log into the console of the device you will see that there are two interfaces, even though only one is shown on the sim. The first interface, Gi0/0 in this case, is connected to the imaginary back-end management network. You will need to configure this interface to use DHCP. It will pull the IP it has been assigned and you should be able to ping out to the gateway and beyond. I recommend using a mangement VRF just like you would in production. This way management will not interfere with your lab. See my config below:

As you see from the output above, DHCP hands out the IP VIRL has assigned. It must be noted this IP will change every time you launch the sim! So, how do you set a static IP? See the screen cap below. In the latest Alpha: While in the design pane you would click on the device, then scroll down to the bottom where it asks you to enter the Management address. If you enter an address that is not in the management scope, it will error when you try to launch the sim. In earlier versions of VIRL you will need to enter the static_ip extension manually. I have captured that in a screen shot as well.

Now when you launch the sim you will see that the telnet IP for node 1 is the static IP we assigned:

You will also notice that the device become reachable after you configure the management IP properly:

Now you just need to configure your remote access method of choice (Telnet/SSH) and you are off to the races!

I hope this helps and if you have any questions, corrections, or additions please leave a comment or hit me up on twitter!

Cisco VIRL, pfSense, and Routed Management Networks was originally published in Network Hobo on Medium, where people are continuing the conversation by highlighting and responding to this story.

All of the conclusions below were based off of my individual findings dealing with Vue and my cable provider. But, I used some parts of pfSense that a lot of people talk about and I thought it would be good to put it on paper for others to find.

For all of the pfSense examples below I am using pfSense 2.4.0-BETA on an Netgate SG-1000.

The Issue

When the decision to cut the cord it was with much excitement about the upcoming experimenting with different content providers. First we tested hardware and ended up settling on the Amazon FireTV. Then we started a free trial of both Sling and Playstation Vue. While going back and forth between the two I started to notice an issue. Sling was streaming without issue while we kept getting queued up with Vue.

I began to investigate. At the time I was running the system wireless through a Ubquiti UniFi setup, through our pfSense firewall, and out of our cable connection (70 down, 4 up). I noticed that while streaming Slack the data flow looked steady. But, when Vue was streaming, there were constant spikes in upload and download utilization. This really got me thinking…why would we be seeing spikes in both directions with a streaming service?

I started investigating. After digging and digging I finally found a post (which I can no longer find the link to…) that shed some light onto the subject. It was a description of the mechanism used by the Vue app to proactively monitor the bandwidth available to stream. It basically said that the due app was running a small bandwidth test periodically to test the available bandwidth for streaming.

This got me thinking about my cable internet provider. I had often run into issues with my link quality becoming garbage anytime I hit the limit on 70 down & 4 up on our account. The policing the company used was vicious and would drop packets like mad.

The Quick Test

I believed these periodic bandwidth tests were causing my providers aggressive policing to kick in and trash my link. To test my hypothesis I decided to put two limiter rules on my firewall. One was named upload and one was name download. I set the upload bandwidth to 2 meg and the download bandwidth to 5 meg (since this is the advertised Vue usage). I then put a rule on the LAN interface of my pfSense to catch traffic from my FireTV and apply the limiter.

After setting up this quick test I cleared my current firewall states so all the flows would be caught by the new rules. We fired up a show on Vue and I watched the limiters. Everything was working as it should on the firewall. Also, the stream was solid and I was not seeing the traffic spikes we were seeing earlier. I was seeing some drops on the limiters, but they did not seem to be affecting the quality of the stream.

I decided to put this into a more sustainable configuration so that I could maintain it moving forward, and make it scalable as we added FireTVs in other rooms of the home.

The Long Term Solution

Since we were planning to add more FireTVs to the home I decided to:

1. Create static DHCP reservations for the devices
2. Create a host alias group in pfSense that contains all of the devices
3. Create an upload and download limiter
4. Create a rule a firewall rule on my LAN interface to catch traffic and apply the limiter.

1. Create Static DHCP Reservations

To be sure I grabbed the proper devices each time, and to prevent myself from having to configure static IPs on my devices, I decided to use static DHCP reservations. Luckily static IP reservations are very easy in pfSense. I went to Status > DHCP Leases and found my FireTV. I then select the white background plus sign:

This will take you to the “Static DHCP Mapping on LAN” page. Here you will fill out all the information required for your environment. The only requirement is IP Address. The rest of the fields will accept the default settings from your DHCP configuration.

2. Create a Host Alias Group in pfSense That Contains All of the Devices

Once the static DHCP reservation is complete we move on to creating the alias group. For this I went to Firewall > Aliases > IP and clicked the “+ Add” button at the bottom of the list. Luckily for us the aliases setup within pfSense is very straightforward! Enter a desired name & description. Then make sure “Host(s)” is selected in the “Type” dropdown. After this add your new static IP to the “IP or FQDN” field. If you have more devices to add to this group just click the “+ Add Host” button and add as many as you need!

3. Create an Upload and Download Limiter

Now that we have our devices statically addressed and in an alias group we move on to configuring the limiters. We will need one limiter for the upload side and one for the download side. You will see why in the creation of the rule to catch traffic.

To configure a limiter is pfSense go to Firewall > Traffic Shaper > Limiters and select “+ New Limiter”. Below I have a screenshot of my AmazonTV_Download Limiter:

There are a lot of other fields available, but these are the basic ones that need to be filled out. I also created another limiter named AmazonTV_Upload. This one is set to 2 Mbit/s. I could probably lower that, since my FireTV shouldn’t be uploading anything to the Internet…

Once these are created be sure to save and apply your changes!

4. Create a Rule a Firewall Rule on My LAN Interface to Catch Traffic and Apply the Limiter.

This is where the rubber hits the road! Once all of the other pieces are configured we are ready to create a firewall rule to apply the limiters to the traffic. To do this we go to Firewall > Rules > LAN (because all of my FireTV devices are on the LAN network).

Here we select the “Add” button with the arrow pointing up. This is chosen so that the new rule will catch the FireTV traffic before it hits any other rules on the LAN interface. Depending on your rule setup you may need this rule to be elsewhere. If you are using floating rules always be mindful of your order of operations within the firewall. Floating rules are processed first!

I have included a screenshot of my Amazon FireTV rule below. You will see that I am using the alias group as the source with any as the destination matching on any protocol. The limiter is configured under the advanced options, so you will need to click the “Display Advanced” button at the bottom of the rule. At the bottom of the Advanced section you will see “In / Out Pipe”. This is where we put our limiters to use!

I like to pretend I am standing on the firewall looking at the device. So, the “In” pipe is where you put your upload rule and the “Out” pipe is where you put your download rule. They have added some language to explain this in the section.

Once the rule is saved and applied all you need to do is power cycle your FireTV so it will pick up the new IP reservation and then everything should start working.

Monitoring

To monitor your limiters go to Diagnostics > Limiter Info. Here you will see the real time data pertaining to the usage of your configured limiters. I have included the output from mine below as an example:

Final Thoughts

This is just one way I have used limiters. They are a VERY powerful tool in the pfSense arsenal!

If there are any questions/feedback/corrections please feel free to reach out in the comments below!

PlaystationVUE, Amazon FireTV, pfSense, and Traffic Limiting was originally published in Network Hobo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Quick Note

I thought I would make a quick post about how I reset the toner counters on my brother HL-3170CDW. I find myself having to search for these steps every few months.

The Request:

I love my brother HL-3170CDW printer (CLICK HERE). It performs great and always works for us. The one thing I do not like is buying toner cartridges…and I have yet to do so! I have owned this printer since August 13, 2013 and have yet to replace the toner even though I use it regularly. My current page count is a total 1,432 pages with 1,009 being color and 423 being monochrome and I am still using the starter cartridges that came with the printer. The brother spec sheet (CLICK HERE) states that the starter cartridges are good for 1,000 pages each, but I have been given the “Toner Low” error almost 3 times now.

The Solution:

The secret behind the continual use of the toner cartridges is the ability to reset the counters so the printer thinks the cartridges are new again. I will continue to do this until print quality decreases. Below are the steps to reset the counters. I always reset all cartridges…just to save myself time.

1. Open the top lid of the printer and leave ajar.
2. Press and hold the “Secure” and “X Cancel” buttons.
3. Use the arrow keys to select the cartridge model you would like to reset and press “OK”.
4. Press the UP arrow to reset the cartridge.
5. Once reset is selected you will see “ACCEPTED” on the screen.

After you perform the reset for the needed cartridges just close the printer lid and hit “X Cancel” to exit back to the main menu. DONE!

From time to time I also use the cartridge sliders to clean the wires and preventative maintenance to keep the printer running in good shape.

Thanks!

I would like to say thank you to the following resources:

• YouTube

Reset Toner Counter on brother HL-3170CDW was originally published in Network Hobo on Medium, where people are continuing the conversation by highlighting and responding to this story.

I have a client with a data center, a headquarters/DR site, and a lot of branches spread out all over the world with Internet connectivity.

They are currently using static IPSEC Internet facing VPNs to connect to their data center and HQ environemts, but the company is hitting a growth spurt and they are quickly realizing this solution is becoming difficult to scale and manage with their limited in-house IT staff.

The client wanted to stick with Internet based VPNs for connectivity. They also wanted a solution that would allow them to easily stand up a new remote site quickly with a template configuration and provide tunnel redundancy between the data center and HQ locations. They also wanted direct site-to-site communications when necessary.

The Solution:

The examples below are from my lab. They are working in production with different crypto algorithms.

Since this client has an existing Cisco routing environment and plans to continue to use Cisco routers it was decided that a DMVPN setup would work best to met their needs. To provide the type of connectivity they desired a Phase 3 dual-hub setup would be the best bet.

The client also had an existing EIGRP setup that ran between the HQ and data center over an existing GRE tunnel. This GRE tunnel will be removed and replaced with the DMVPN as well. There is nothing special with the EIGRP configuration used on the routers when using this DMVPN setup besides the EIGRP aggregate statements we will place on the hub tunnel interfaces.

First lets look at the standard crypto config that goes on all routers, both hub and spoke:

crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key t3$tk3y address 0.0.0.0        
crypto isakmp keepalive 10
!
!
crypto ipsec transform-set TRANSSET ah-sha-hmac esp-aes 256 esp-sha-hmac 
 mode transport
!
crypto ipsec profile VPNPROF
 set transform-set TRANSSET

For the following tunnel interface examples we need to lay out an example IP scheme so everything makes sense:

• EIGRP AS: 1
• Data Center
• WAN IP: 1.1.1.1
• Tunnel100: 10.100.0.1
• LAN 1: 192.168.10.0 /24
• LAN 2: 192.168.11.0 /24
• HQ
• WAN IP: 2.2.2.2
• Tunnel100: 10.100.0.10
• LAN 1: 192.168.20.0 /24
• LAN 2: 192.168.21.0 /24
• SPOKE 1
• WAN IP: 3.3.3.3
• Tunnel100: 10.100.0.20
• LAN: 192.168.41.0 /24
• SPOKE 2
• WAN IP: 4.4.4.4
• Tunnel100: 10.100.0.30
• LAN: 192.168.51.0 /24

Lets look at the configuration for our first hub…the Data Center:

interface Tunnel100
ip address 10.100.0.1 255.255.255.0
no ip redirects
no ip split-horizon eigrp 1
ip pim dr-priority 100
ip pim sparse-dense-mode
ip nhrp authentication t3$tk3y
ip nhrp map multicast dynamic
ip nhrp map multicast 2.2.2.2
ip nhrp map 10.100.0.10 2.2.2.2
ip nhrp network-id 100
ip nhrp holdtime 360
ip nhrp nhs 10.100.0.10
ip nhrp shortcut
ip nhrp redirect
ip summary-address eigrp 1 192.168.0.0 255.255.0.0
ip summary-address eigrp 1 192.168.10.0 255.255.255.0
ip summary-address eigrp 1 192.168.11.0 255.255.255.0
ip tcp adjust-mss 1416
tunnel source Ethernet0/0
tunnel mode gre multipoint
tunnel key 100
tunnel protection ipsec profile VPNPROF

For this hub config you will see a few different things.

First you will see that in addition to the standard DMVPN dynamic statements you will also see a static config that is pointing to the second hub, in this case the HQ site.

You will also see the command ip nhrp shortcut and ip nhrp redirect. These commands enable the smooth creation of spoke-to-spoke tunnels and are additions in Phase 3.

Now for the summary addresses…

First we want to cover the entire private IP space that could be used inside the organization. Since this organization uses strictly 192.168.X.X space we place the 192.168.0.0/16 aggregate on the hub tunnel. But, since this is a dual-hub design, we also need to place the site specific aggregates on the tunnel as well. Since this sites design does not allow us to cleanly roll up the subnets each /24 was added as a separate statement.

The reason behind these aggregates is because the spoke will only see routes from the hub. In DMVPN Phase 3 the EIGRP relationship only exists between the spoke and hub. When a spoke tries to route to the IP space of another spoke the hub will pass the more specific route via an NHRP message and inject it into the spoke as an H designated route. The more specifics allow the traffic to flow directly to the hub that possesses that IP space. If the more specific aggregates were not configured both hubs would only advertise the /16 aggregate and this could lead to less than optimal routing.

Now lets look at the HQ tunnel remembering that HQ is the second hub:

interface Tunnel100
ip address 10.100.0.10 255.255.255.0
no ip redirects
no ip split-horizon eigrp 1
ip pim dr-priority 95
ip pim sparse-dense-mode
ip nhrp authentication t3$tk3y
ip nhrp map multicast dynamic
ip nhrp map multicast 1.1.1.1
ip nhrp map 10.100.0.1 1.1.1.1
ip nhrp network-id 100
ip nhrp holdtime 360
ip nhrp nhs 10.100.0.1
ip nhrp shortcut
ip nhrp redirect
ip summary-address eigrp 1 192.168.0.0 255.255.0.0
ip summary-address eigrp 1 192.168.20.0 255.255.255.0
ip summary-address eigrp 1 192.168.21.0 255.255.255.0
ip tcp adjust-mss 1416
tunnel source Ethernet0/0
tunnel mode gre multipoint
tunnel key 100
tunnel protection ipsec profile VPNPROF

As you can see the configuration is close to identical except for the static NHRP configuration, the EIGRP aggregates, and the PIM DR priority.

Now that we have our hubs configured we can put together the configuration for our spokes. This tunnel config will be used over and over again as new spokes are rolled out. Since the HQ and Data Center IPs remain static the only thing that needs to be changed for each spoke would be the tunnel interface IP address and the source interface.

Remember…the spokes use the same crypto config as the hubs:

interface Tunnel100
 ip address 10.100.0.20 255.255.255.0
 no ip redirects
 ip pim sparse-dense-mode
 ip nhrp authentication t3$tk3y
 ip nhrp map multicast 1.1.1.1
 ip nhrp map multicast 2.2.2.2
 ip nhrp map 10.100.0.1 1.1.1.1
 ip nhrp map 10.100.0.10 2.2.2.2
 ip nhrp network-id 100
 ip nhrp holdtime 360
 ip nhrp nhs 10.100.0.1
 ip nhrp nhs 10.100.0.10
 ip nhrp registration no-unique
 ip nhrp shortcut
 ip nhrp redirect
 ip tcp adjust-mss 1416
 ip ospf network point-to-multipoint
 tunnel source Ethernet0/0
 tunnel mode gre multipoint
 tunnel key 100
 tunnel protection ipsec profile VPNPROF

Pretty basic right? This config will create static DMVPN tunnels to both hubs. When you run a show dmvpn command you will see the following output on the spoke:

SPOKE1#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface: Tunnel100, IPv4 NHRP Details 
Type:Spoke, NHRP Peers:2, 
# Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
    1  1.1.1.1         10.100.0.1       UP   01:20:18    S
    1  2.2.2.2         10.100.0.10      UP   01:20:08    S

Great! The spoke is now up and connect to the hubs! Lets take a look at the routing table:

Routing table truncated to show relevant pieces

SPOKE1#sh ip route

10.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
C        10.100.0.0/24 is directly connected, Tunnel100
L        10.100.0.20/32 is directly connected, Tunnel100
D        10.254.254.1/32  [90/27008000] via 10.100.0.1, 01:23:00, Tunnel100
D        10.254.254.10/32 [90/27008000] via 10.100.0.10, 01:23:00, Tunnel100
D        10.254.254.30/32 [90/28288000] via 10.100.0.10, 01:23:00, Tunnel100
D     192.168.0.0/16 [90/27008000] via 10.100.0.10, 01:23:00, Tunnel100
                     [90/27008000] via 10.100.0.1, 01:23:00, Tunnel100
  192.168.41.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.41.0/24 is directly connected, Loopback1
L        192.168.41.1/32 is directly connected, Loopback1
D     192.168.10.0/24 [90/27008000] via 10.100.0.1, 01:23:00, Tunnel100
D     192.168.11.0/24 [90/27008000] via 10.100.0.1, 01:23:00, Tunnel100
D     192.168.20.0/24 [90/27008000] via 10.100.0.10, 01:23:00, Tunnel100
D     192.168.21.0/24 [90/27008000] via 10.100.0.10, 01:23:09, Tunnel100

As you see we only have the aggregates in the spoke routing table.

Now lets try to ping the LAN IP space on SPOKE 2. Lets look at the show dmvpn once again:

SPOKE1#ping 192.168.30.1 source Lo1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.114.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.30.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/5 ms
SPOKE1#sh dmvpn                     
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface: Tunnel100, IPv4 NHRP Details 
Type:Spoke, NHRP Peers:3,

# Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
      1 1.1.1.1         10.100.0.1        UP 01:30:11     S
      1 2.2.2.2         10.100.0.10       UP 01:30:01     S
      2 4.4.4.4         10.100.0.30       UP 00:00:29     D
                        10.100.0.30       UP 00:00:29   DT1

Nice! The dynamic tunnel popped up without a problem. The following route was added to the routing table:

H     192.168.30.0/24 [250/1] via 10.100.0.30, 00:04:38, Tunnel100

Just like we expected…NHRP has injected the more specific with the H designator.

Now, if either of the hubs were to fail the other hub would continue to act as the NHRP server and the dynamic environment would continue to function.

Conclusion:

DMVPN is a very useful tool in a Cisco routed environment. It can make rolling out new spokes very easy. There are also many ways to customize this environment. I see a lot of clients that will place the routers Internet interface and Internet default route into its own VRF and then have the tunnel passing routes into the global table. Then the hub will pass a default to the spoke and force all traffic through the hub. This allows for filtering and other security measures to be taken centrally.

THANKS!

Thanks for taking the time to read this. I hope you find it helpful! Please feel free to leave comments or contact me via twitter (@dancwilliams) if you have any questions or feedback.

Cisco DMVPN Phase 3 was originally published in Network Hobo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Now that Cisco has included SSL VPN licensing as part of the 15.3(3)M IOS I have had multiple clients ask about turning on the capability and reaching back into Active Directory for authentication.

The Solution:

The equipment I used to lab this solution:

• Cisco 881 w/ IOS 15.3(3)M3 (10.0.1.238)
• Windows Server 2008 R2 (10.0.1.231)

First we will go through the steps to configure the RADIUS server on Windows so we have access to Active Directory for authentication.

You must first ensure the “Network Policy and Access Services” role is installed on the server. Once this role is installed we will go into NPS (Local) > RADIUS Clients and Servers > RADIUS Clients. Here will will configure our router as a RADIUS Client. Be sure to make note of the key you specify here as you will need it when configuring the RADIUS server on the router.

Once our RADIUS client is configured we will move on to configuring the Network Policies in NPS (Local) > Policies > Network Policies and clicking NEW under Actions.

Under the Conditions Tab you will want to add a Windows Group that contains your users that are allowed VPN access and a NAS IPv4 Address to specify the requesting router.

Under the Constraints tab you will only select Unencrypted Authentication (PAP, SPAP).

The Settings tab can be left at default. Make sure that you move your new policy to the top of the list!

Now that we have the Windows Server piece configured we can move on to the configuration of the router. I have included the main configuration blocks below. Be sure to bind radius requests to the interface with the IP you specified in the Windows Server configuration or else requests may fail. Depending on the environment some people choose to use a loopback address for this.

Note: The only interface I have configured on this router is the Fa4 interface with the IP 10.0.1.238 which is plugged into my lab environment. Also, when you first issue the webvpn gateway NAME command and self-signed cert and trustpoint will be configured. I have included a reference doc at the bottom that goes through the SSL VPN config in more detail.

aaa new-model
!
radius server RADIUS 
address ipv4 10.0.1.231 auth-port 1645 acct-port 1646 
key XXXXXXXXX
!
aaa group server radius TEST881
 server name RADIUS
!
ip radius source-interface FastEthernet4 
!
aaa authentication login SSL_VPN group TEST881 local
!
webvpn gateway SSLVPN_Gateway
    ip address 10.0.1.238 port 443  
    http-redirect port 80
    ssl trustpoint TP-self-signed-4045373729
    inservice
!
webvpn context SSLVPN_Context
    title "Network Hobo VPN"
    login-photo file flash:/Blog_LOGO.png
    logo file flash:/Blog_LOGO.png
    login-message "Secure Access"
    aaa authentication list SSL_VPN
    gateway SSLVPN_Gateway
    !
    ssl authenticate verify all
    !
    url-list "Internal Sites"
        heading "LAB"
        url-text "CACTI" url-value "http://10.0.1.241"
        url-text "IOU-WEB" url-value "http://10.0.1.34"
    inservice
    !
    policy group SSLVPN_DefaultPolicy
        url-list "Internal Sites"
    default-group-policy SSLVPN_DefaultPolicy

Once you have your RADIUS server and additional aaa config in place you can test RADIUS authentication using the following command:

TEST_881#test aaa group radius dwilliams Test1Test1 legacy 
Attempting authentication test to server-group radius using radius
User was successfully authenticated.

Next you can navigate to your SSL VPN site and attempt to log in. Everthing should be good to go if you have followed the steps above.

Conclusion:

The ability to implement the Cisco IOS SSL VPN and tie it back into AD without any additional cost or licensing is a big thing to many of my clients. This will give many existing organizations a new capability to lock down their edge and really enhance remote access capabilities with the investment of a little time and possibly some consulting dollars. While I mainly focused on authenticating through AD/RADIUS in this article there are many other capabilities of the SSL VPN that I did not cover.

Maybe in a future write up…

THANKS!

I would like to say a quick thank you to the following references while I was working through this:

• Clientless SSL VPN on Cisco IOS Router — Knowledge Base

Cisco IOS SSL VPN with AD/RADIUS Authentication was originally published in Network Hobo on Medium, where people are continuing the conversation by highlighting and responding to this story.

I have a client with multiple 6807 VSS pairs that required an IOS upgrade. All of the pairs have a single SUP2-T in each chassis and were in the 15 code train.

Although the ISSU process is very straight forward I wanted to put this quick process up as I had to search through multiple documents to gather all the pieces I needed to knock it out.

The Solution:

Since these switches were in the proper code train to utilize ISSU I decided that was the best route to go. It also helps that everything was already dual-homed. This process is for VSS pairs with only one SUP per chassis! If you have another configuration you can reference the Cisco document provided at the bottom of the post.

Some example text was taken from the Cisco Document referenced below

One of the first things you want to verify is that there is a current boot variable configured on the VSS pair pointing to the version of code that is running currently. Some devices only have one version of code on the bootdisk so there is not a boot variable configured. For the ISSU to perform properly you MUST configure the boot variable:

Router(config)# boot system flash bootdisk:s72033-oldversion.v1

Next you will want to download the new image from your favorite file transfer spot to your bootdisk. I prefer to use FTP:

Router# copy ftp: bootdisk:
Address or name of remote host []? test.ftp.local
Source filename []? s72033-newversion.v2
Destination filename [s72033-newversion.v2]?
Accessing ftp://test.ftp.local/s72033-newversion.v2...!!!!! Complete

Once the image is downloaded you will want to copy the image over to the slavebootdisk:

Router# copy bootdisk: slavebootdisk:
Source filename []? s72033-newversion.v2
Destination filename [s72033-newversion.v2]?
Copy in progress...CCCCCCCCCCCCCCC Complete

After you have the images on both bootdisks you can begin the ISSU process.

The first step is to verify the VSS pair is ready for the ISSU upgrade:

Router# show issu state detail
Slot = 1/3
RP State = Active
ISSU State = Init
Boot Variable = bootdisk:s72033-oldversion.v1,12;
Operating Mode = sso
Primary Version = N/A
Secondary Version = N/A
Current Version = bootdisk:s72033-oldversion.v1
Variable Store = PrstVbl

Slot = 2/3
RP State = Standby
ISSU State = Init
Boot Variable = bootdisk:s72033-oldversion.v1,12;
Operating Mode = sso
Primary Version = N/A
Secondary Version = N/A
Current Version = bootdisk:s72033-oldversion.v1

Router# show redundancy states
my state = 13 -ACTIVE
peer state = 8 -STANDBY HOT
Mode = Duplex
Unit = Secondary
Unit ID = 18

Redundancy Mode (Operational) = sso
Redundancy Mode (Configured) = sso
Redundancy State = sso
Maintenance Mode = Disabled
Communications = Up

client count = 132
client_notification_TMR = 30000 milliseconds
keep_alive TMR = 9000 milliseconds
keep_alive count = 0
keep_alive threshold = 18
RF debug mask = 0x0

Once the pair is verified to be good to go you will want to load the new image onto the standby chassis. This will load the new code on the standby and reload the chassis. If you have EVERYTHING DUAL HOMED you will not see an interruption in traffic.

Router# issu loadversion bootdisk:s72033-newversion.v2

000133: Aug 6 16:17:44.486 PST: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/3/4, changed state to down
000134: Aug 6 16:17:43.507 PST: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet2/3/4, changed state to down
000135: Aug 6 16:17:43.563 PST: %LINK-3-UPDOWN: Interface TenGigabitEthernet2/3/4, changed state to down
000136: Aug 6 16:17:44.919 PST: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/3/4, changed state to down

(Deleted many interface and protocol down messages)

%issu loadversion executed successfully, Standby is being reloaded

(Deleted many interface and protocol down messages, then interface and protocol up messages)

0000148: Aug 6 16:27:54.154 PST: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/3/5, changed state to up
000149: Aug 6 16:27:54.174 PST: %LINK-3-UPDOWN: Interface TenGigabitEthernet2/3/5, changed state to up
000150: Aug 6 16:27:54.186 PST: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet2/3/5, changed state to up
000151: Aug 6 16:32:58.030 PST: %HA_CONFIG_SYNC-6-BULK_CFGSYNC_SUCCEED: Bulk Sync succeeded

During the process you will want to run the following command until you see that the ISSU Sub-State is Load Version Complete:

Router# show issu state detail
Slot = 1/3
RP State = Active
ISSU State = Load Version
Boot Variable = bootdisk:s72033-oldversion.v1,12
Operating Mode = sso
Primary Version = bootdisk:s72033-oldversion.v1
Secondary Version = bootdisk:s72033-newversion.v2
Current Version = bootdisk:s72033-oldversion.v1
Variable Store = PrstVbl

Slot = 2/3
RP State = Standby
ISSU State = Load Version
Boot Variable = bootdisk:s72033-newversion.v2,12;bootdisk:s72033-oldversion.v1,12
Operating Mode = sso
Primary Version = bootdisk:s72033-oldversion.v1
Secondary Version = bootdisk:s72033-newversion.v2
Current Version = bootdisk:s72033-newversion.v2

Router# show redundancy status
my state = 13 -ACTIVE
peer state = 8 -STANDBY HOT
Mode = Duplex
Unit = Secondary
Unit ID = 18

Redundancy Mode (Operational) = sso
Redundancy Mode (Configured) = sso
Redundancy State = sso
Maintenance Mode = Disabled
Communications = Up

client count = 132
client_notification_TMR = 30000 milliseconds
keep_alive TMR = 9000 milliseconds
keep_alive count = 1
keep_alive threshold = 18
RF debug mask = 0x0

Once this state is reached you will want to go into the next step to force a switchover to the standby chassis that is running the new code and being upgrading the remaining chassis. Once you issue the runversion command it will start a rollback timer that is by default set to 45 minutes. If you do not commit the version (next step) before the timer runs out the upgrade will be rolled back!

Router# issu runversion
This command will reload the Active unit. Proceed ? [confirm]
(Deleted many lines)

Download Start
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
(Deleted many lines)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Download Completed! Booting the image.
Self decompressing the image : ##########################################################################################
(Deleted many lines)

##########################################################################

running startup....

(Deleted many lines)

000147: Aug 6 16:53:43.199 PST: %HA_CONFIG_SYNC-6-BULK_CFGSYNC_SUCCEED: Bulk Sync succeeded

Once the chassis has rebooted we will once again want to verify the ISSU state and redundancy state:

Router# show issu state detail
Slot = 2/3
RP State = Active
ISSU State = Run Version
Boot Variable = bootdisk:s72033-newversion.v2,12;bootdisk:s72033-oldversion.v1,12
Operating Mode = sso
Primary Version = bootdisk:s72033-newversion.v2
Secondary Version = bootdisk:s72033-oldversion.v1
Current Version = bootdisk:s72033-newversion.v2
Variable Store = PrstVbl

Slot = 1/3
RP State = Standby
ISSU State = Run Version
Boot Variable = bootdisk:s72033-oldversion.v1,12
Operating Mode = sso
Primary Version = bootdisk:s72033-newversion.v2
Secondary Version = bootdisk:s72033-oldversion.v1
Current Version = bootdisk:s72033-oldversion.v1

Router# show redundancy status
my state = 13 -ACTIVE
peer state = 8 -STANDBY HOT
Mode = Duplex
Unit = Primary
Unit ID = 39

Redundancy Mode (Operational) = sso
Redundancy Mode (Configured) = sso
Redundancy State = sso
Maintenance Mode = Disabled
Communications = Up

client count = 134
client_notification_TMR = 30000 milliseconds
keep_alive TMR = 9000 milliseconds
keep_alive count = 1
keep_alive threshold = 18
RF debug mask = 0x0

You will now want to commit the new version to reload the standby chassis and have it run the new image:

Router# issu commitversion
Building configuration...
[OK]
000148: Aug 6 17:17:28.267 PST: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet2/3/4, changed state to down
000149: Aug 6 17:17:28.287 PST: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/3/4, changed state to down

(Deleted many interface and protocol down messages)

%issu commitversion executed successfully

(Deleted many interface and protocol down messages, then interface and protocol up messages)

000181: Aug 6 17:41:51.086 PST: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/3/5, changed state to up
000182: Aug 6 17:42:52.290 PST: %HA_CONFIG_SYNC-6-BULK_CFGSYNC_SUCCEED: Bulk Sync succeeded

Once this has completed your entire VSS pair will be upgraded. You can verify the upgrade by once again checking the ISSU & redundancy state:

Router# show issu state detail
Slot = 2/3
RP State = Active
ISSU State = Init
Boot Variable = bootdisk:s72033-newversion.v2,12;bootdisk:s72033-oldversion.v1,12
Operating Mode = sso
Primary Version = N/A
Secondary Version = N/A
Current Version = bootdisk:s72033-newversion.v2
Variable Store = PrstVbl

Slot = 1/3
RP State = Standby
ISSU State = Init
Boot Variable = bootdisk:s72033-newversion.v2,12;bootdisk:s72033-oldversion.v1,12
Operating Mode = sso
Primary Version = N/A
Secondary Version = N/A
Current Version = bootdisk:s72033-newversion.v2

Router# show redundancy status
my state = 13 -ACTIVE
peer state = 8 -STANDBY HOT
Mode = Duplex
Unit = Primary
Unit ID = 39

Redundancy Mode (Operational) = sso
Redundancy Mode (Configured) = sso
Redundancy State = sso
Maintenance Mode = Disabled
Communications = Up

client count = 134
client_notification_TMR = 30000 milliseconds
keep_alive TMR = 9000 milliseconds
keep_alive count = 1
keep_alive threshold = 18
RF debug mask = 0x0

Conclusion:

Once I found all of the information I needed this was a very easy process and actually did not take as long as I expected. The boot variable was one issue I ran into but once I figured out what it was asking for that was easy to fix. Another thing to be mindful of is that after the upgrade process your original active processor will be the standby processor.

THANKS!

I would like to say a quick thank you to the following references while I was working through this:

• Cisco Release 15.1SY Supervisor Engine 2T Software Configuration Guide

Cisco 6807 VSS ISSU Upgrade was originally published in Network Hobo on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. If you do not have a FQDN for your nameserver you will want to create an A record pointing to its IP:

THANKS!

I would like to that Glen Kemp who began discussing this topic with me. I thought I should put this up even though GoDaddy clearly supports this procedure in their Support Forums.

GoDaddy: Delegate Subdomain to Different Nameserver was originally published in Network Hobo on Medium, where people are continuing the conversation by highlighting and responding to this story.

I thought I would make a quick post around how I prepare audio files for deployment in Unity Connection, Communications Manager, Contact Center Express, and other Cisco UC[1] products. This post will be focused around Unity Connections but the same method can be used for all applications.

The Request:

Due to inclement weather conditions in the southeast I had multiple clients that needed emergency messages uploaded to their Unity Connection auto attendants. I have some clients that have call handler managers and record and configure their own messages on the systems. But, I have quite a few that would much rather just record a message with whatever is handy (an iPhone more and more these days) and e-mail it to me for uploading and configuration.

The Solution:

I like to use the Switch application by NCH Software for this task. For the amount of time I spend performing this task I find the software to be extremely easy to use, accepting of every format I have thrown at it, and relatively inexpensive.

I thought the best way to show how to do this would be by shooting a quick video:

Also here is a quick screen shot of the settings for the WAV conversion so it will be in the format Cisco likes! I know we have all run into this especially with things like music on hold…

Conclusion:

This is just a short post on a topic I am asked about often. I am sure there are MANY different ways to accomplish this task using many different tools and methods. I would love for you all to share your method in the comments so we can all learn!

1. Unified Communications

© Daniel C Williams and NetworkHobo.com, 2014. Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Daniel C Williams and NetworkHobo.com with appropriate and specific direction to the original content.

Convert Audio Files for use with the Cisco Unified Communications Suite was originally published in Network Hobo on Medium, where people are continuing the conversation by highlighting and responding to this story.

Two new Nexus 7Ks have been installed at one of my client’s data centers. Management connectivity was brought up to the data center core and verified. I was given console access and told to configure TACACS+[1] authentication and authorization on the F2 VDC[2].

The Solution:

Configuring TACACS+ on the Nexus 7K is totally different than on IOS and even different than on the Nexus 5K equipment. It also requires a certain order of operations and there is one solid “gotcha” that most people run into. But, knowing these going in will make this a painless procedure.

The first thing to remember is that you MUST enter the TACACS+ server key UNENCRYPTED. Most templates within many organizations I work with keep the TACACS+ key in its encrypted format within template documents. Entering it into a Nexus 7K in this format WILL NOT WORK. Been there…done that…

First you will need to make sure the TACACS+ feature in enabled on the NEXUS 7K by entering the following command:

config
feature tacacs+

Now you will need to decide how to configure your TACACS+ server keys. You can either configure a global key for all servers or on a per-server basis:

Global Key:

tacacs-server key 0 TESTKEY

Per-Server Key:

tacacs-server host X.X.X.X key 0 TESTKEY

Now you will need to list all of your TACACS+ hosts. Previously I showed you how to enter a host with a per-server key. If you use a global key you will use this command:

tacacs-server host X.X.X.X

Now we need to configure a TACACS+ group to use for authentication, authorization, accounting, etc. Here is an example:

aaa group server tacacs+ TESTNAME
    server X.X.X.X
    server X.X.X.X
    server X.X.X.X
    use-vrf VRFNAME

The servers you enter into the group must first be defined as tacacs-server hosts as shown in the previous configuration . If you know this fact going in it is a huge time saver! It is also recommended that you configure the VRF that you would like to use for TACACS+ access. If you have no VRFs configured just use the following code to use the default VRF:

use-vrf default

Now you want to tell the Nexus 7K where to source the request from. For example if you were to use VLAN 2 for the TACACS+ source interface you would use the following code:

ip tacacs source-interface vlan 2

Some organizations also like to use directed requests to allow certain groups point their logins toward certain authentication servers outside of the standard group configuration. The command that allows this to happen is:

tacacs-server directed-request

After all of this has been configured you are ready to add your authentication strings and test. I always recommend ensuring authentication works before configuring anything further, especially authorization as it can definitely slow down the process. The aaa string you need to enter is as follows:

aaa authentication login default group TESTNAME

Now you can test using the following command:

test aaa group TESTNAME username password

This will allow you to verify TACACS+ is working properly. Once this is confirmed you can move on to the authorization and accounting configuration:

aaa authentication login console group TESTNAME
aaa authorization commands default group TESTNAME
aaa accounting default group TESTNAME
aaa authentication login error-enable

I have included the full config below. If commands are entered in this order you will be good to go!

config
feature tacacs+
tacacs-server key 0 TESTKEY
tacacs-server host X.X.X.X
tacacs-server host X.X.X.X
tacacs-server host X.X.X.X
aaa group server tacacs+ TESTNAME
    server X.X.X.X
    server X.X.X.X
    server X.X.X.X
    use-vrf VRFNAME
ip tacacs source-interface vlan 2
tacacs-server directed-request
aaa authentication login default group TESTNAME
aaa authentication login console group TESTNAME
aaa authorization commands default group TESTNAME
aaa accounting default group TESTNAME
aaa authentication login error-enable

Conclusion:

I had a selfish motive for writing this post…I was tired of join through it over and over again. If the order of operations is followed properly, and the gotchas are avoided, this can be a fun and painless procedure. I hope this helps everyone and if you have any questions or improvements just let me know!

THANKS!

I would like to say a quick thank you to the following references while I was working through this:

• Josh O’Brien (@joshobrien77) over at staticnat.com! You post on Nexus 7000 TACACS+ helped a TON. You can read it here.
• Cisco Nexus 7K Security Design Guide
• Cisco Nexus 7K TACACS+ Example

1. Terminal Access Controller Access-Control System Plus
2. Virtual Device Context

© Daniel C Williams and NetworkHobo.com, 2014. Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Daniel C Williams and NetworkHobo.com with appropriate and specific direction to the original content.

Configure TACACS+ Access on Nexus 7K was originally published in Network Hobo on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Request:

I was engaged by a long time client who was having an issue with their local SFTP[1] server. After some upgrades to their server infrastructure they noticed their phone/voicemail system had not been backed up in MONTHS! They asked if there was a way for me to perform an “emergency” backup to my system if they gave the voice VLAN access to the Internet temporarily while they fixed their SFTP issues.

The Solution:

It just so happened that when the client called me I was out of the office and working from the family home for the holidays. Here is the equipment I had available to me:

• Apple Airport Express MC414LL/A (Internet Gateway)
• MacBook Pro w/ OS X Mavericks 10.9.1

The Cisco phone system consists of the following components:

• Cisco CUCM[2] 9.0
• CUC[3] 9.0

This process is the same on both the CUCM and CUC. There are additional services to backup under CUC but the backup system is identical.

The first thing I needed to do was access the phone system and verify Internet connectivity. I used RDP[4] to access the client’s management server. Once logged in I accessed the phone system to verify Internet connectivity. This is done by logging into Cisco Unified OS Administration web page then going to Services > Ping and trying to ping an outside address (4.2.2.2 in this example):

Once Internet connectivity from the phone system was verified I moved on to configuring my local system to accept the transfer.

First I configured NAT on the Apple Airport Express to pass SSH (port 22) from the Internet to my laptop. Below are the screenshots:

First we access the Airport Utility and click on the Internet access router. Make note of the IP Address as you will need it later:

Next we click “Edit” and go to the “Network” tab. Then click the “+” below the “Port Settings” field:

Next use the drop down to select the “Remote Login — SSH” service and point it to the IP of your laptop. Click “Save” and then apply the configuration to the Airport Express:

Once this was configured I moved on to configuring my laptop to accept SSH connections. This process is pretty straight forward and I have included screenshots below:

Once SSH was configured on the laptop it was time to configure a backup device on the phone system and perform a manual backup. Below are the screenshots:

First I accessed the Disaster Recovery System > Backup > Backup Device and configured a new device. You would replace the X.X.X.X with you Internet/Public IP address that you got off of your Airport Express. Point the path to where you would like the backup files to be saved (I created a folder on my desktop to collect the files). Then use your laptop username and password. When you save the backup device it will test connectivity before declaring a successful save.

Next you will go into Backup > Manual and start a manual backup of all available services. You will select the services by checking the box beside each one. In Unity Connection you may receive popups concerning dependencies. This will be ok since you will be selecting all services to back up.

Once I verified the backups (Backup > History) were successful I loaded them to Dropbox and shared them out to my client. Too easy!

Conclusion:

This is a short post but the process definitely came through in a pinch so I wanted to get it documented. Luckily I was at a location with high enough bandwidth that the entire procedure was not TOO painful. I was able to help the client in their time of need and provide the level of service they are accustomed to receiving. That being said I will be setting up a full time SFTP server in the DMZ[5] at the office to handle these issues in the future.

If you have any questions or suggestions feel free to comment below! Thanks!

1. Secure File Transfer Protocol
2. Cisco Unified Communications System
3. Cisco Unity Connection
4. Remote Desktop Protocol
5. Demilitarized Zone

© Daniel C Williams and NetworkHobo.com, 2013. Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Daniel C Williams and NetworkHobo.com with appropriate and specific direction to the original content.

Cisco Unified Communications Manager & Unity Connection SFTP Emergency Backup to Mac OS X over the… was originally published in Network Hobo on Medium, where people are continuing the conversation by highlighting and responding to this story.