GRE pass-through on ZBF

Simple little config snippet for a Cisco Zone-Based firewall.

First you need to put in a deny statement for GRE traffic in an ACL.
Deny? Wait a second, don't we want traffic to pass?
Well of course we do! But if you remember in a Zone-Based firewall your outbound ACL is used in a class-map to inspect traffic; dynamically allowing bi-directional sessions. The reason we want to deny it is you can't inspect GRE traffic; it just doesn't work.

(config)#ip access-list extended ACL_PERMIT_GRE
(config-ext-nacl)#deny gre any any

Okay so we're not inspecting traffic, but we still need to pass it. To do this we have make a class-map to nest under out outbound and inbound policy-maps.

Now we'll create our class-map which matches GRE traffic, referencing the ACL we just made:

(config)#class-map type inspect match-all CMAP_PASS_GRE
(config-cmap)#match access-group name ACL_PERMIT_GRE

Then we want to apply this to our policy maps and define the action as pass.
The policy maps I'm applying these to also contain class-maps for generic traffic.

(config)#policy-map type inspect PMAP_UNTRUST_TO_TRUST
(config-pmap)#class type inspect CMAP_PASS_GRE
(config-pmap-c)#pass

(config)#policy-map type inspect PMAP_TRUST_TO_UNTRUST
(config-pmap)#class type inspect CMAP_PASS_GRE
(config-pmap-c)#pass

And that's about it, your GRE should be good to go. This will work for PPTP pass-through on a Cisco IOS running in ZBF and the same principal should apply for an ASA.

Site-to-Site VPNs - Part 1: The Basics

I've been getting a lot of questions lately about VPNs (virtual private networks); how they work, what are they, how to configure them. To most CCNA graduates it can be a bit confusing. Seeing as more than half the work in our NOC consists of VPN-related issues I thought it'd be good to get everything out in the open for those who aren't sure about them.

There are a couple different types of VPN connections (L2L, RAS, SSL, etc), however we're going to just with the basics and cover a site-to-site connection.

If you have your CCNA, you should be familiar with the concept of Frame-Relay. It allows two private networks to connect to one another as if there was nothing but a router in between. Nowadays we generally use MPLS or VPNs in place of a Frame-Relay PVC. What this allows you to do is more easily and dynamically connect multiple subnetworks together for very cheap (and in VPN cases, basically free - provided you have the equipment).

Speaking of equipment, we'll be covering three in these posts: a Cisco IOS-based router, a Cisco ASA, and a Juniper SSG - they all employ the same technology.

Core

Before we can configure our tunnels, we need to know how they operate. You'll hear terms like phases, SAs, "interesting traffic", route based vs policy based, encryption, and a million other terms thrown around by NOC-monkies; this is where we'll explain everything you need to know to keep up in the conversation and impress your friends.

Let's begin by breaking down the order of operations for establishing an IPSec VPN.

First we'll need some traffic that wants to connect to a remote host. This is called "interesting traffic"; it's interesting because it triggers an ACL (or policy). This ACL/policy is being monitored by the VPN on your firewall. ACL is hit, traffic is tunneled - simple. This is a policy based VPN. The alternative would be a route based VPN; I find these very popular on ScreenOS. They require you to create a virtual tunnel interface to route traffic towards as you would any other interface.

Your VPN can be configured in one of two modes, Aggressive or Main. Aggressive is used when your remote LAN is using a dynamic IP address or behind NAT; this will cause the tunnel peer or hub (where your VPNs terminate) to consider VPN requests from any peer IP address. However, all interesting traffic will have to be initiated from the remote firewall; the head doesn't know the IP of its peer until the tunnel is established.

Once your remote firewall has interesting traffic that needs to be tunneled, it reaches out to its peer's IP and initiates what's referred to as "Phase One negotiations".  In Phase One, the two peers negotiate an authentication method, encryption algorithm, hash algorithm, and Diffie Hellman group as well as a timeout - this is known as the proposal in Junipers and a Transform Set in Cisco-world. After both sides are in an agreement an IKE SA is created and a secure connection has been created between them so they can safety start with Phase Two. If a single setting in the Phase One proposal is mismatched between peers, the IKE SA will fail to be established.

In Phase Two, the keying material is generated, and the two peers agree upon the policy that will be used (known as a proxy ID in Juniper-land when using a route based tunnel). This mode, which is called quick mode, differs from Phase One in that it can't occur until after Phase One is successful and all of the Phase Two packets are encrypted. This makes troubleshooting a little more difficult as it is possible for Phase One to be successful but Phase Two to fail. If Phase Two is successful, it will result in a Phase 2 SA, also called an IPSec SA, and the tunnel will be fully established.

I'll be going into more detail about everything mentioned above in Part 2, when we go through deploying both route based and policy based IPSec VPNs on a Juniper SSG Firewall from start to finish.

EasyVPN LDAP Authentication

The following is a tutorial on how to enable an ASA to use LDAP (Active Directory) group policy for log-in authentication when connecting via Cisco EasyVPN.

LDAP stands for Lightweight Directory Access Protocol, which is an application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. Or in simpler terms, LDAP lets you access AD.

For the sake of this tutorial we will be adding a group to an ASA 5510

Add the AD group to the attribute map

We need to tell the ASA what domain and group to look at for the authentication process.

An attribute map for our purposes, is essentially a list of VPN groups that we want to use.
CN=Foobar VPN is setting Foobar VPN as the AD group. This is the exact name configured on the AD Server.
OU=VPN Groups is setting the OU as "VPN Groups". This is the OU that contains the Foobar VPN group on the AD Server.
DC=foobar, DC=com sets the domain as foobar.com
and lastly FoobarVPN is the local (the ASA's) name for this group.

ldap attribute-map LDAPAttMap
 map-value memberOf "CN=Foobar VPN,OU=VPN Groups,DC=foobar,DC=com" FoobarVPN

Define a group policy

So the ASA knows about the Windows server, but we don't have a local group policy set up for the VPN group. There's a whole whack of attributes that can be defined so lets get crackin'.

We won't be using a WINS server so here we define that as none. But we do have two local DNS servers, 192.168.1.11 and .12. The group policies allow you to define how many users that we're going to allow in at once. For this group we only want three at any one time.The vpn-filter is just an ACL to be applied to this tunnel. vpn-tunnel-protocol allows us to choose which encryption protocol we wish to use for the tunnel, here we've chosen SSL. This VPN is a split-tunnel , which allows users to access a public network (the internet) as well as a LAN at the same time using the same physical connection. Which LANs are accessible can be defined using the split-tunnel-network-list command. The value is simply another ACL. default-domain simply defines the domain this VPN will be accessing. address-pools lets us choose the DHCP pool we'll be using for addressing the connected clients. And lastly, we tell the ASA that the clients will be connecting through WebVPN and that the Cisco AnyConnect installer should remain installed after use.

group-policy FoobarVPN internal
group-policy FoobarVPN attributes
 wins-server none
 dns-server value 192.168.1.11 192.168.1.12
 vpn-simultaneous-logins 3
 vpn-filter value FoobarFilter
 vpn-tunnel-protocol ssl-client
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value FoobarVPN_Split
 default-domain value foobar.com
 address-pools value VPNPool
 webvpn
 anyconnect keep-installer installed

Setup a tunnel-group for remote access

Now that we have the ASA aware of the AD server and the group we need to use. We have to setup a tunnel group for our users. Tunnel groups contain a small number of attributes that pertain to creating the tunnel itself. Tunnel groups include a pointer to a group policy that defines user-oriented attributes.

Firstly, we have to set the FoobarVPN group that we defined previously as a remote-access group.
Now we can start to define some general attributes.

address-pool VPNPool defines VPNPool as the DHCP address pool (this pool is not defined in this tutorial). You can set up to 10 external DHCP servers and 6 pools. Because we are using the ASA as the DHCP server, it is not explicitly defined here.

authentication-server-group Foobar_LDAP specifies Foobar_LDAP as the AAA server group. This tutorial assumes this as been pre-defined. I'll include a snippet on how to quickly configure it at the bottom of this page.

default-group-policy FoobarVPN tells the ASA that the FoobarVPN we created in step two is the default policy group for this tunnel-group.

Going into the webvpn-attributes sub-tree we can enable WebVPN to use the FoobarVPN we defined in step two.

tunnel-group FoobarVPN type remote-access
tunnel-group FoobarVPN general_attributes
 address-pool VPNPool
 authentication-server-group Foobar_LDAP
 authentication-server-group (Internal) Foobar_LDAP
 default-group-policy FoobarVPN
tunnel-group FoobarVPN webvpn-attributes
 group-alias FoobarVPN enable

Bonus Round! Setting up the Authentication Server!

Welcome to the bonus round! This snippet will help you in initially configuring your ASA (or if you have the unfortunate pleasure of owning a PIX) to use an LDAP server.

So we're using LDAP so lets tell the ASA that: aaa-server Foobar_LDAP protocol ldap defines our server as Foobar_LDAP and specifies the protocol as LDAP .

Okay we told it a server exists, now we need to tell the ASA where to find it: aaa-server Foobar_LDAP (Internal) host 192.168.1.2 associates the Foobar_LDAP server we defines two seconds ago with the 192.168.1.2 IP address and lets the ASA know it's an internal server.

Then we specify the domain in which the server exists, foobar.com

And finally we give it the password, domain log-in, and tell the ASA that the server is running Windows.

aaa-server Foobar_LDAP protocol ldap
aaa-server Foobar_LDAP (Internal) host 192.168.1.2
 ldap-base-dn dc=foobar,dc=com
 ldap-group-base-dn dc=foobar,dc=com
 ldap-scope subtree
 ldap-naming-attribute saMAccountName
 ldap-login-password *****
 ldap-login-dn vpnasa@foobar.com
 server-type microsoft
 ldap-attribute-map LDAPAttMap