Restart a single context on an ASA with virtual instances

The Cisco ASA firewall can run as virtual host for multiple virtual ASA’s known as contexts.  We recently ran into an issue where a memory leak made one context inoperable.  Rather than reload the entire ASA and take out the other contexts we wanted to only restart the context that was having problems.  Unfortunately there is no way to reboot an individual context as the reload command does not exist inside a context.  The solution is to delete the context and recreate it.  This may sound daunting, but it takes a few seconds and your config is restored.  First login to the ASA and change to the context that’s having problems and save the config.  In our case the context named “transparent” was the one that stopped working.  (You may not want to save the config if a configuration issue broke the context.  If so this step is optional.) login as: admin admin@10.10.10.1’s password: Type help or ‘?’ for a list of available commands. ASA5525/admin> ASA5525/admin> en Password: ************ ASA5525/admin# changeto context transparent ASA5525/transparent# wr mem Then switch to the system context (the hypervisor layer) and show the context information.  In our case we have three contexts: admin, customer and transparent. ASA5525/transparent# changeto system ASA5525# show run context ! admin-context admin context admin   allocate-interface GigabitEthernet0/0   allocate-interface GigabitEthernet0/1   allocate-interface GigabitEthernet0/1.2   allocate-interface Management0/0   config-url disk0:/admin.cfg ! context customer   allocate-interface GigabitEthernet0/0   allocate-interface GigabitEthernet0/1.499   config-url disk0:/customer.cfg ! context transparent   allocate-interface GigabitEthernet0/3 outside   allocate-interface GigabitEthernet0/4 inside   config-url disk0:/transparent.cfg ! Copy the config for the context causing you problems.  Then remove the context. ASA5525# conf t ASA5525(config)#...

Troubleshoot Ruckus AP not connecting to Virtual SmartZone cloud controller

Here are a list of things to troubleshoot when a Ruckus AP is not registering to a Virtual SmartZone (VSZ) cloud controller. Ensure that the public IP address of the site where the AP resides is permitted through the firewall protecting the VSZ. Check that the AP has a valid private IP address and is pingable from the router at that site. SSH into the AP.  default credentials are super/sp-admin).  If those credentials don’t work then the AP has received its config from the controller and the zone credentials must be used. Ping an external IP address to confirm the AP can reach the internet. Run “get scg” rkscli: get scg ------ SCG Information ------ SCG Service is disabled. AP is not managed by SCG. State: Not Available - busy or not running. SCI is disabled. Server List: (IP or FQDN of VSZ shows here) No SSH tunnel exists Failover List: Not found Failover Max Retry: 2 DHCP Opt43 Code: 6 Server List from DHCP (Opt43/Opt52): Not found SCG default URL: RuckusController SCG config|heartbeat|mesh status|status intervals: 300|30|300|900 SCG gwloss|serverloss timeouts: 1800|7200 ---------------------------- If you see “SCG Service is disabled” Then run “set scg enable” and this should start the SCG service. If the Server List is incorrect or empty run “set scg ip {IP or FQDN goes here}” to point the AP to the VSZ...

Barracuda ADC Load Balancer – How to show client IPs and not the proxy IP address – Part 2

In my first post on showing the client IP addresses through a Barracuda ADC load balancer, I showed how to get Direct Server Return to work for clients on the same network by adding loopback interfaces on the back-end servers.  In this post I will discuss a problem when using a layer 7 proxy service with Client Impersonation enabled on a multi-homed ADC. One of the requirements for client impersonation is that the back-end servers must use an ADC IP address as the default gateway.  In traditional two-armed deployments where the real servers sit behind the ADC this is not a problem.  However when the network is more complex and the ADC has interfaces in different networks and both VIPs and real servers sit on each of these networks then there can be some unexpected behaviors when it comes to the routing of packets. For example this diagram shows an ADC that sits on a management network, DMZ and LAN.  We have both VIPs and real servers on the DMZ and LAN. The problem that occurs in this environment is that when back-end servers are setup to use the ADC as the default gateway, they can no longer get to other networks.  For example, we discovered that packets that came from the back-end servers in the DMZ could not reach the LAN or get to the internet.  We found that the packets were coming in on the ADC’s DMZ interface, but then leaving the ADC’s management interface!  The Barracuda documentation states: If you have multiple networks, you must specify a default gateway on the NETWORK > Routes page for every interface that accepts incoming traffic. Even though default routes were added on the DMZ interface as shown below, the...

Barracuda ADC Load Balancer – How to show client IPs and not the proxy IP address – Part 1

In order to see the client origination IP address on the real back-end servers when a Barracuda ADC load balancer is used there are two options.  The first is to use layer 4 load balancing on the service type.  The other option is to use a layer 7 proxy service and enable client impersonation (while setting the default gateway to the ADC - but this causes other problems that I’ve discussed in part 2 of this post).  Both of these options work ok for clients outside of the back-end server network, but these do not work if the clients are in the same layer 2 network.  (For example if your virtual IP is 10.0.0.5 and the back-end servers are 10.0.0.10, 10.0.0.11 and your client is 10.0.0.100, then neither of these options will work).  This is because when the back-end server sees that the IP address is on the same network, it will not send the return packets back through the Barracuda ADC, but rather straight to the client and thus break the TCP stream. The solution to this is to use a layer 4 TCP service with “Direct Server Return” (DSR) enabled, plus a loopback interface must be added to each of the back-end servers that have the IP address of the service virtual IP (VIP) assigned to them.   DSR will cause the ADC to change the data frame’s MAC address to the MAC of the real server before placing the packet back on the wire.  The server will accept the packet (bound for the service VIP) because the loopback has been assigned the same IP.  The server will then respond back directly to the client using the VIP as the source address. To do this, first go to the device manager and right click...

NetFlow setup for 3750x with C3KX-SM-10G

The Cisco 3750x switch does not support NetFlow natively, but the C3KX-SM-10G module has ASICs that support NetFlow.  With the C3KX-SM-10G module, NetFlow can only be run on the 4 interfaces in the module — this does not add NetFlow on the entire switch. It is however possible to capture the switch’s traffic and port mirror (SPAN) it over to one of the C3KX-SM-10G interfaces so that it can be exported for NetFlow.  The problem is that in order to mirror traffic to a port and export NetFlow, the port must be in an UP state.  In order to force the port up we took an LC fiber patch cable and split apart the plastic end and pulled the cable apart so that we had 2 single fiber strands.  Then we plugged in an SFP and connected the port into itself by looping the single fiber back to the same SFP.  Use caution with this as it will create a loop — it might be better to setup the mirror first as it will put the port in an UP/DOWN state that I’ll mention later. First setup the port mirroring selecting the source VLANs or interfaces.  Also point the SPAN at the interface where the fiber loop is on the C3KX-SM-10G. monitor session 5 source vlan 1 - 5 , 7 , 100 monitor session 5 destination interface Gi4/1/2 Then setup the NetFlow export.  Start by defining the flow monitoring records. flow record NETFLOW  match datalink source-vlan-id  match datalink dot1q priority  match datalink mac source-address  match datalink mac destination-address  match ipv4 version  match ipv4 tos  match ipv4 ttl  match ipv4 protocol  match ipv4 source address  match ipv4 destination address  match transport source-port  match...

Barracuda ADC Load Balancer with OWA – Login loop

We had a problem with Barracuda’s ADC load balancer and Outlook Web App for Exchange 2013.  The user would get to the OWA login screen and login only to be brought back to the login screen again in an endless loop.  We were using the “Instant SSL” service type as described in the following Barracuda document: https://techlib.barracuda.com/adc/msx2013deploy The problem was that “Rewrite Support” was enabled on the service.  Disabling this allowed the users to login without...