context

Cisco ASA: multiple context and capture

Packet captures are very useful for troubleshooting purposes. The Cisco ASA supports packet captures even in multiple context mode. I normally configure packet captures on CLI level. This can be done by configuring an access-list to match the specific traffic you would like to capture. Add the access-list and the specific interface in a capture command. Mostly I download the capture in raw format for further analysis with a tool like WireShark. The capture can be downloaded via TFTP or via a secure connection (HTTPS) to the Cisco ASA firewall.

When running a Cisco ASA in multiple context mode, I always disable the ability to connect directly to a context for management purposes. That way you have to access the admin context for management access, but this also denies the option to download the capture via a secure connection directly from the Cisco ASA traffic context.

The easiest way to download the capture in multiple context mode is via a TFTP transfer from the system context. Check the example command below. The capture is made within the context named contextA and the capture has the name captureA. The following command can be used to download the capture in raw (pcap) format.

copy /pcap capture:contextA/captureA tftp://10.10.10.10/captureA.pcap

You can now analyse the capture with WireShark

Configure IOS SSL VPN on IOS router

Yesterday I blogged about configuring a VPN client on an IOS router and today I blogged about importing PKCS12 certificates for WebVPN purposes. This follow up blog is about configuring the WebVPN functionality together with the AnyConnect client and port forwarding on an IOS router. I use the same setup as with the VPN client and also configured split-tunneling for the AnyConnect connection.

The Cisco IOS SSL VPN feature supports multiple options, like:

Clientless: usage of a web portal;
Thin client: usage of a web portal with port forwarding feature;
Full client: usage of the Cisco AnyConnect client;

This example shows you how to configure all options listed above. The fist step involves configuring the authentication method with an AAA method.

aaa new-model
aaa authentication login sslvpn local
username rene privilege 15 secret 5 $1$FkgJ$u3uU0rstyeaBXswW0EIX55

The authentication method is called sslvpn and uses the local database on the router for authenticating users. Next you have to configure the basic IP and port information for connecting to the SSL VPN feature of the router. I use the public IP address of the router and configured the WebVPN on port TCP/4400. I use the SSL trustpoint from my previous blog post.

webvpn gateway gateway_1
ip address 83.137.194.62 port 4400
ssl trustpoint trustpoint_www
inservice

To use the full client feature, you have to upload an AnyConnect client to the routers flash. You can upload multiple AnyConnect clients for different operating systems. I just upload a client for Windows.

webvpn install svc flash:/webvpn/svc.pkg sequence 1

Next you have to configure a “webvpn context”. Within the webvpn context you define multiple VPN parameters. The webvpn context contains configuration parameters to access an URL through the web portal, define the port forwarding features or apply a policy group to the webvpn context. Below you see an example configuration of a webvpn context.

webvpn context home
title “Booches Portal”
ssl authenticate verify all
!
url-list “WebServers”
heading “WebServers”
url-text “Inside webserver” url-value “http://192.168.1.10”
!
login-message “Booches”
!
port-forward “Port Forwarding”
local-port 444 remote-server “192.168.1.150” remote-port 5001 description “NAS TCP/5001 (Management)”
local-port 443 remote-server “192.168.1.150” remote-port 443 description “NAS TCP/443 (Photo,File System)”
local-port 222 remote-server “192.168.1.200” remote-port 22 description “Ubuntu TCP/22 (Management)”
!
policy group policy1
url-list “WebServers”
port-forward “Port Forwarding”
functions file-access
functions file-browse
functions file-entry
functions svc-enabled
hide-url-bar
svc address-pool “sslvpn”
svc keep-client-installed
svc split include 192.168.1.0 255.255.255.0

You can configure multiple webvpn contexts with different authentication methods, url-list or port forwarding parameters. Next you see some screenshots from the WebVPN. To access the WebVPN feature the user has to browse to https://83.137.194.62:4400/home, because I configured gateway gateway_1 domain home (full config at the end). The web portal login page is displayed below.

After logging in you will get to the web portal menu, where you can choose between the multiple client options.

The Bookmarks section list the URL list to access internal websites. The Tunnel Connection (SVC) option starts the Cisco AnyConnect client. If the AnyConnect client isn’t yet installed on the remote client, it will be pushed by the router. The Thin Client Application starts the port forwarding feature.

All the relevant configuration from the example above can be found below.

aaa new-model
aaa authentication login sslvpn local
username rene privilege 15 secret 5 $1$FkgJ$u3uU0rstyeaBXswW0EIX55
!
ip local pool sslvpn 10.10.1.1 10.10.1.254
!
webvpn gateway gateway_1
ip address 83.137.194.62 port 4400
ssl trustpoint trustpoint_www
inservice
!
webvpn install svc flash:/webvpn/svc.pkg sequence 1
!
webvpn context home
title “Booches Portal”
ssl authenticate verify all
!
url-list “WebServers”
heading “WebServers”
url-text “Inside webserver” url-value “http://192.168.1.10”
!
login-message “Booches”
!
port-forward “Port Forwarding”
local-port 444 remote-server “192.168.1.150” remote-port 5001 description “NAS TCP/5001 (Management)”
local-port 443 remote-server “192.168.1.150” remote-port 443 description “NAS TCP/443 (Photo,File System)”
local-port 222 remote-server “192.168.1.200” remote-port 22 description “Ubuntu TCP/22 (Management)”
!
policy group policy1
url-list “WebServers”
port-forward “Port Forwarding”
functions file-access
functions file-browse
functions file-entry
functions svc-enabled
hide-url-bar
svc address-pool “sslvpn”
svc keep-client-installed
svc split include 192.168.1.0 255.255.255.0
default-group-policy policy1
aaa authentication list sslvpn
gateway gateway_1 domain home
max-users 2
inservice

I like for SMB solutions the IOS SSL VPN feature, because it is powerful and works over SSL, but it is also flexible and can almost publish every service.

Cisco Firewall Design and Deployment

The session about firewall design and deployment didn’t reveal a lot of new things about the Cisco ASA appliance or FWSM module. The only new thing for me was the possibility to configure a redundant interface for a Cisco ASA appliance. The screen shot below shows the cabling scheme for an implementation with and without interface redundancy.

This interface redundancy makes it possible to connect a ASA to two different physical switches. When the active switch would crash, the second switch would become the active switch.

Important here is to notice that this configuration doesn’t provide load-balancing across two links. The configuration is only for link redundancy.

To configure interface redundancy you can use the configuration snippet shown below.

interface Redundant1
member-interface GigabitEthernet0/2
member-interface GigabitEthernet0/1
no nameif
no security-level

no ip address
!
interface Redundant1.4
vlan 4
nameif inside
security-level 100
ip address 172.16.10.1 255.255.255.0
!
interface Redundant1.10

vlan 10
nameif outside
security-level 0
ip address 172.16.50.10 255.255.255.0

The configuration of interface redundancy has some caveats as listed below:

Firewalls have to be configured in Active/Standby mode. No load-balancing or link aggregation is supported;
Interface redundancy is available on Cisco ASA 5510 and above. The ASA 5505 already has a build in switch and FWSM doesn’t have any physical interfaces;
Subinterfaces (IEEE 802.1Q) need to be configured on top of the logic redundant interface;

During the session the different modes for the firewalls have been discussed. Normally we only use the Routed Mode, but there are more modes like described below:

Routed mode: traditional mode of the firewall. Two or more interfaces that separate two or more layer 3 domains;
Transparent mode: the firewall acts as a bridge and functions mostly at layer 2 of the OSI model (this functions is often used for filtering traffic between two routers who, for example, exchange routing information through a dynamic routing protocol);
Multi-context: one physical firewall is divided in more virtual firewalls;
Mixed mode: using routed and transparent firewalls in a virtual environment (NOTE: mixed mode is only supported in FWSM today);

Firewall virtualization using multiple context has some caveats. We, Ictivity consultants, already noticed these caveats during firewall implementations. Firewall virtualization has the following caveats:

No support for VPN services;
No support for dynamic routing protocols;
No way to configure the sharing of CPU usage between contexts;
No support for multicast routing (multicast bridging is supported);

Especially not supporting VPN services (site-to-site VPN, remote access VPN and SSL VPN) is mostly the most used reason for not using multiple context implementation for the firewall.