Suggested prerequisite reading:
»Cisco Forum FAQ »Various Site-to-Site IPSec VPN: Cisco, Juniper, Checkpoint, Sonicwall, Zywall
Note:
All of the following sample configurations assume the ASA or PIX Firewall uses static Public IP address. Typically you assign one IP address of the IP block provided by your ISP to the ASA or PIX Firewall Outside interface. Assigning static IP address to VPN Concentrator (the ASA or PIX Firewall in this case) is considered best practice to keep security in place especially when the VPN Concentrator runs Site-to-Site VPN.
Sample Configuration of IPSec VPN Concentrator
When you plan to have a PIX or ASA firewall to act as both firewall and VPN concentrator, following is the sample configuration.
Assumptions:
* The 1st LAN subnet is 192.168.0.0/24 with 192.168.0.1 (the PIX inside interface) as the default gateway
* There is also 10.0.0.0/8 as 2nd LAN subnet, where from PIX or ASA firewall is reachable via 192.168.0.2
* There will be remote users VPN into the PIX using Cisco VPN Client software, creating ESP-based IPSec VPN tunnel
* There are separate subnets for VPN users. In these sample configurations, there are 192.168.1.0/24 for VPN users logged in as Admin and 192.168.2.0/24 for VPN users logged in as Sales.
* Note that you cannot use the same subnet for both LAN and VPN users due to routing consistency
* No default gateway to access the LAN subnet will be received by VPN users once the IPSec VPN tunnel is established; which will set the VPN users' PC to proxy arp to reach the LAN subnet
* There are multiple VPN groups where one is for Admin users and another is for Sales users. This way the PIX or ASA firewall can distinguish between one user and another
* When Admin users wish to VPN in as Admin let's say, then the users must use the appropriate VPN group credential (in this case, the Admin VPN group credential) which include the correct PIX or ASA firewall Public IP address and VPN group password
* As general rule, all settings in PIX or ASA firewall must match all settings in the VPN Client software. Some of those settings are the VPN group credentials, routing, and permitted subnets in the ACL. Any slightest mismatch will cause connection problem.
1. Single VPN User Group without external AAA Server
* The remote users will VPN in using specific Group Authentication credential, which in this sample configuration is Admin as the Group Name and is ******** as the Group Password as indicated on the vpngroup Admin password ******** command
* The VPN users log in as Admin receive IP address within the admin range from 192.168.1.1 to 192.168.1.254 (the 192.168.1.0/24 subnet).
* No external AAA (Authentication, Authorization, and Accounting) server as the TACACS+/RADIUS server
* SSH attempt to the PIX/ASA itself is not authenticated on the OS version 7.0 or above sample configuration and is authenticated locally on the OS version 6.3 sample configuration
PIX Firewall configuration running OS version 6.3
ASA/PIX Firewall Sample Configuration running OS version 7.0 or above
2. Multiple VPN User Groups with external AAA Server
* The remote users will VPN in using specific Group Authentication credential, which in this sample configuration is either Admin or Sales
* The VPN users log in as Admin receive IP address within the admin range from 192.168.1.1 to 192.168.1.254 (the 192.168.1.0/24 subnet). Similarly, the VPN users log in as Sales receive IP address within the sales range from 192.168.2.1 to 192.168.2.254 (the 192.168.2.0/24 subnet).
* There is a TACACS+/RADIUS server at 192.168.0.204 to serve the AAA (Authentication, Authorization, and Accounting) functionality for all remote users
Note: check out following FAQ for more info on TACACS and RADIUS
»Cisco Forum FAQ »Secure and Monitor Network Access with AAA (TACACS/RADIUS) and Privilege Level
* The TACACS+ service is used to provide PIX/ASA configuration management access, such as telnet and ssh to the PIX/ASA itself
* The RADIUS service is used to provide production access (the LAN) to remote VPN users
* The aaa authentication match command will authenticate remote user login attempts according to the RADIUS credential that are being used to log in
* The aaa authorization match command will authorize remote user access to only specific subnets according to the authenticated RADIUS credential that are acknowledged
* The aaa accounting match command will record all activities done by all remote users according to their RADIUS credential
PIX Firewall configuration running OS version 6.3
3. Single VPN User Group with external Windows Active Directory Domain Controller Server
* The remote users will VPN in using specific Group Authentication credential, which in this sample configuration is Admin as the Group Name as indicated on the tunnel-group Admin type ipsec-ra command; and is ******** as the Group Password as indicated on the tunnel-group Admin ipsec-attributes pre-shared-key * command
* The VPN users log in as Admin receive IP address within the admin range from 192.168.1.1 to 192.168.1.254 (the 192.168.1.0/24 subnet).
* Starting OS version 7.0, AAA server protocol of NT (Microsoft Windows Active Directory Domain Controller), LDAP (RFC 4510), Kerberos (RFC 4120), and SDI (RSA SecurID) are available as alternatives of TACACS+ and RADIUS
* In this sample configuration, external Microsoft Windows Active Directory Domain Controller server is used primarily to authenticate remote users
* The use of such Microsoft authentication system is defined on the aaa-server NT_DOMAIN command, which include the protocol, Domain Controller name and IP address.
* When the Domain Controller is unavailable or unreachable, local credentials as indicated on the username Admin1 password ***** encrypted privilege 15 and the username Admin2 password ***** encrypted privilege 15 commands are used as failover to authenticate remote users
* This failover mechanism is defined on the tunnel-group Admin general-attributes authentication-server-group NT_DOMAIN LOCAL command
* Similar authentication process for Sales remote user group, however there is no failover to local credentials
* Telnet attempt to the PIX/ASA itself is not authenticated
ASA/PIX Firewall Sample Configuration running OS version 7.0 or above
Notes:
* Since the PIX or ASA firewall acts as both firewall and VPN concentrator, the isakmp nat-traversal is necessary to simultaneously serve VPN users accessing the LAN subnet and to keep LAN subnet machines able to access the Internet
* When the PIX or ASA firewall is dedicated to only serve as VPN Concentrator, then the isakmp nat-traversal, the global 1-nat 1 pair commands might not be necessary
* Remote users can opt to either enable transparent tunneling or not when using the Cisco VPN Client software. When transparent tunneling is enabled, the ESP protocol is encapsulated within UDP (UDP port 4500) by default, which then makes the VPN traffic able to pass through any NAT/PAT device in between. This encapsulation feature is useful when either there is any NAT/PAT device in between or ESP protocol is not permitted to pass through. In addition, this encapsulation feature also enables the remote users to be able to access the LAN and the Internet at the same time.
* As you may notice, configuration with sufficient amount of external authentication servers such as AAA (TACACS+/RADIUS) server and Domain Controller server is more secure and accountable
* When your network currently does not have AAA server, you can setup one for free. Check out this FAQ for details.
»Cisco Forum FAQ »Are there Free authentication packages for TACACS or RADIUS to secure my router?
* If specific remote users must authenticate with specific AAA server, then you can simply modify the AAA command to do so. Following is illustration
Sample Configuration of PPTP or L2TP Windows VPN Concentrator and Others
»Cisco Forum FAQ »Configure router and ASA/PIX Firewall to support various VPN technologies
 feedback form
 feedback form
by Covenant  edited by aryoba
last modified: 2009-06-11 12:10:07 |
