Solved

Cisco Pix501-to-Pix501 VPN + Cisco VPN Client Remote Access

Posted on 2006-11-08
6
285 Views
Last Modified: 2013-11-16
Hi All,

I have spent the last couple of days working on a PIX-to-PIX and remote access VPN setup. I seem to have ironed out all of the problems and have my PIX configs working how I want them (using many of the past posts from Experts Exchange as a reference). I would like an expert to look over my main site config to see if it looks ok and answer a couple of brief questions that I have. The main site PIX is a Cisco Pix 501, with a second Cisco PIX 501 in a remote site to form a PIX-to-PIX VPN. The main site PIX also accepts connections from remote PCs that have the Cisco VPN Client installed. The main site PIX config is as follows:

---- START OF CONFIG

interface ethernet0 10baset
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password <my-password>
passwd <my-password>
hostname MAINSITE

fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol ils 389
fixup protocol pptp 1723
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69                      

names
name <my-routers-ip-address> router
name <my-pix-ip-address> pixoutside
name <my-mail-server-ip-address> serverext
name 192.168.1.1 pixinside
name 192.168.1.10 serverint

access-list 110 permit ip 192.168.1.0 255.255.255.0 192.168.254.0 255.255.255.0
access-list 110 permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0
access-list acl_out permit icmp any any time-exceeded
access-list acl_out permit icmp any any unreachable
access-list acl_out permit icmp any any echo-reply
access-list acl_out permit tcp any host serverext eq smtp

pager lines 24
mtu outside 1500
mtu inside 1500
ip address outside pixoutside 255.255.255.248
ip address inside pixinside 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
pdm history enable
arp timeout 14400

global (outside) 1 interface
nat (inside) 0 access-list 110
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
access-group acl_out in interface outside
static (inside,outside) serverext serverint netmask 255.255.255.255 0 0
route outside 0.0.0.0 0.0.0.0 router 1

timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout sip-disconnect 0:02:00 sip-invite 0:03:00
timeout uauth 0:05:00 absolute

aaa-server TACACS+ protocol tacacs+
aaa-server TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server RADIUS protocol radius
aaa-server RADIUS max-failed-attempts 3
aaa-server RADIUS deadtime 10
aaa-server LOCAL protocol local

http server enable
http 0.0.0.0 0.0.0.0 outside
http 0.0.0.0 0.0.0.0 inside

no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable

ip local pool vpnpool 192.168.254.200-192.168.254.254
sysopt connection permit-ipsec
crypto ipsec transform-set akemat esp-3des esp-sha-hmac
crypto dynamic-map cisco 1 set transform-set akemat
crypto map dyn-map 90 ipsec-isakmp dynamic cisco
crypto map dyn-map interface outside
isakmp enable outside
isakmp key <my-key> address 0.0.0.0 netmask 0.0.0.0
isakmp keepalive 180 30
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash sha
isakmp policy 20 group 1
isakmp policy 20 lifetime 1000
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption 3des
isakmp policy 10 hash sha
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400
vpngroup vpn_client_software address-pool vpnpool
vpngroup vpn_client_software dns-server <my-dns-servers>
vpngroup vpn_client_software default-domain cisco.com
vpngroup vpn_client_software split-tunnel 110
vpngroup vpn_client_software idle-time 1800
vpngroup vpn_client_software password <my-password>

telnet 0.0.0.0 0.0.0.0 inside
telnet timeout 10
ssh 0.0.0.0 0.0.0.0 outside
ssh timeout 10
console timeout 0
dhcpd address 192.168.1.201-192.168.1.250 inside
dhcpd dns <my-dns>
dhcpd lease 604800
dhcpd ping_timeout 750
dhcpd enable inside
terminal width 80

--- END OF CONFIG

My Questions:

1) Considering the following lines in my config:

access-list 110 permit ip 192.168.30.0 255.255.255.0 192.168.254.0 255.255.255.0
access-list 110 permit ip 192.168.30.0 255.255.255.0 192.168.40.0 255.255.255.0
vpngroup vpn_client_software split-tunnel 110

Is this the normal way to do a split tunnel? I am concerned that the split tunnel mentions access-list 110 which is a access list for both the PIX-to-PIX vpn and Remote Access VPN subnets. Should I be creating more than one access-list?

2) Machines on the internal network of the main site can reach the remote access PCs. Is this normal/ok?

3) Regarding the following lines:

isakmp enable outside
isakmp key <my-key> address 0.0.0.0 netmask 0.0.0.0
isakmp keepalive 180 30
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash sha
isakmp policy 20 group 1
isakmp policy 20 lifetime 1000
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption 3des
isakmp policy 10 hash sha
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400

I couldn't seem to get both VPNs working without having a isakmp policy 20 and a isakmp policy 10 set of commands. I am not sure why, but assume it has something to do with the isakmp key line?

4) Any other comments or recommendations will be most appreciated. If any changes are made, I will post the final solution as a future reference for others.

Thanks,

Peter
0
Comment
Question by:PeteJH
6 Comments
 
LVL 20

Accepted Solution

by:
calvinetter earned 250 total points
ID: 17904368
1) It's best to have an ACL for your split-tunneling, separate but identical to your "nat (inside) 0" statement.  You could simply do this:
  access-list split_acl permit ip 192.168.30.0 255.255.255.0 192.168.254.0 255.255.255.0
  access-list split_acl permit ip 192.168.30.0 255.255.255.0 192.168.40.0 255.255.255.0
  vpngroup vpn_client_software split-tunnel split_acl
  clear xlate

2) That's ok.

3) >...I am not sure why, but assume it has something to do with the isakmp key line?
      Sort of.  The "isakmp key" line just defines how your remote VPN peers authenticate to your main PIX.  To establish a VPN tunnel, the VPN peers first negotiate a set of iskamp parameters (ie, "isakmp policy" settings on your main PIX) to secure the initial authentication exchange (where in this case they'd exchange the pre-shared key). If the peers agree on the isakmp policy settings, they move on to authentication, which if successful, they eventually continue on to the latter stages of negotiation & finally build a tunnel.
   If your other PIX & the Cisco VPN clients didn't work until you added 'policy 10', then I'd suggest removing 'isakmp policy 20' & re-testing.  You can certainly have both another PIX & remote VPN clients share the same isakmp policy (as long as both find it acceptable).  To remove 'policy 20', do this on your main PIX:

clear cry isak sa
no isakmp enable outside
no isakmp policy 20
crypto map dyn-map interface outside
isakmp enable outside

Then, verify if both the remote PIX & a remote VPN client can establish a VPN tunnel & pass traffic normally. If so, then save your config & you're done.

cheers
0
 
LVL 28

Assisted Solution

by:batry_boy
batry_boy earned 250 total points
ID: 17904649
Hello,

1)  First, the access-list statements in your question 1 do not match the access-list statements from the above PIX configuration.  Which access-list statements are correct?  See below:

From above configuration:

access-list 110 permit ip 192.168.1.0 255.255.255.0 192.168.254.0 255.255.255.0
access-list 110 permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0

From question:

access-list 110 permit ip 192.168.30.0 255.255.255.0 192.168.254.0 255.255.255.0
access-list 110 permit ip 192.168.30.0 255.255.255.0 192.168.40.0 255.255.255.0

Where are the following networks in your environment?  192.168.2.0/24, 192.168.30.0/24, 192.168.40.0/24

Since you only specify the "vpngroup" command in your question, can I assume that you are only concerned about split tunneling your remote access VPN users?  I hate assuming things because you know what they say about assuming!

If we do assume that you are only wanting to allow split tunneling for your remote access VPN users, then here is the syntax of the access-list command to implement it:

access-list split_acl permit ip <local_network> <local_netmask> <foreign_network> <foreign_netmask>

So, for example, your DHCP pool assigns 192.168.254.x to your remote access VPN users and you wanted to only send traffic from these users to the internal network located at 192.168.30.0/24, then you would use the following commands:

access-list split_acl permit ip 192.168.30.0 255.255.255.0 192.168.254.0 255.255.255.0
vpngroup vpn_client_software split-tunnel split_acl

To translate these two statements into English:

"Take traffic coming from 192.168.254.x destined for 192.168.30.x and send it down the IPSEC tunnel.  All other traffic will be sent in the clear directly out the remote user's Internet connection outside the IPSEC tunnel."

One thing to note is that I've never seen Cisco recommend that a split-tunnel ACL be identical but separate to the "nat 0" ACL, although you do need to make sure the traffic defined in the split-tunnel ACL is exempted from NAT and is therefore INCLUDED AS PART OF the "nat 0" ACL.  There's a distinction there.  Cisco DOES recommend that you make a crypto ACL separate but identical to the "nat 0" ACL.  However, the crypto ACL is only used in a site-to-site VPN definition and is different from a split-tunnel ACL.

So, to summarize, if you can provide more information about exactly how you want the split-tunneling defined then I can provide the commands to do this.  If you just want remote access VPN users traffic to destined for the internal network to be tunneled and all of their other traffic to go straight out to the Internet, then you would use the following commands (assuming that the inside network is 192.168.1.0/24):

access-list split_acl permit ip 192.168.1.0 255.255.255.0 192.168.254.0 255.255.255.0
vpngroup vpn_client_software split-tunnel split_acl

2)  This is normal.  If you have security concerns about your internal devices reaching the remote access VPN user machines while they have a tunnel established, you could always have your remote VPN users enable a personal firewall.  However, you don't want to block access to the remote user PC's because this would defeat the purpose of having them establish a remote VPN session to your internal network in the first place.  Every time they tried to access a resource on the internal network, the return traffic would not make it back to the remote PC.

3)  This is purely anecdotal evidence, but my experience has been that remote access VPN users using the Cisco VPN client software need the DH group 2 setting and the PIX site-to-site VPN needs the DH group 1 setting in the ISAKMP policy settings.  I've always used this as a rule of thumb and have never had any problems with it.  Also, I just checked configuration examples from Cisco's website for both remote access and PIX site-to-site VPN scenarios and they confirm what I just mentioned about using DH group 1 for PIX site-to-site and DH group 2 for the remote access users using the Cisco VPN client software.

4)  The following are some recommendations to increase the overall security posture of your PIX configuration:

a)  If possible, have any site-to-site connections utilize a static public IP address so that you can get away from using the "isakmp key" wildcard form of :

isakmp key <string> address 0.0.0.0 netmask 0.0.0.0

  This essentially allows any device to try and establish a site-to-site VPN session with the main site PIX.  The device will still have to have all of the proper ISAKMP and IPSEC settings to establish connectivity, but this is still one more thing to implement for enhanced security.

b)  Explicity define where you allow management sessions to be initiated from.  Remove the following commands from your PIX configuration:

ssh 0.0.0.0 0.0.0.0 outside
http 0.0.0.0 0.0.0.0 outside
http 0.0.0.0 0.0.0.0 inside

    I would not allow management of the firewall on the outside interface if at all possible.  I realize that in some environments this is not an option, but try to avoid it if you can.  Instead of allowing SSH and HTTPS from the outside, use a remote access VPN session through the PIX first, and then allow HTTPS and SSH sourced from the VPN client pool.  For example:

ip local pool vpnpool 192.168.254.200-192.168.254.254
ssh 192.168.254.192 255.255.255.192 inside
http 192.168.254.192 255.255.255.192 inside
management-access inside

    If you must allow management access to the firewall from the Internet, do so with a /32 mask on the source IP address.  For example,

ssh 1.1.1.1 255.255.255.255 outside
http 1.1.1.1 255.255.255.255 outside

    This will at least filter out most of the Internet from being able to try and establish a management session (except for the people who know how to spoof IP addressing, but that's another story!)

c)  Disable the "telnet" protocol.  I know it's only allowed on the inside interface, but it's still clear text and some industrious internal user may be watching traffic...who knows?  When an encrypted protocol such as SSH is available on the PIX coupled with the availability of SSH clients, why even bother with telnet?

d)  Change the snmp public community string.  It is currently set to "public" which is the default.  The whole world knows about this as the default and as such should be changed to something unique.

e)  Set up a syslog server and enable logging to it from the PIX.  Syslog information is valuable in many troubleshooting situations.  For example, if your syslog server IP address is 192.168.1.100, then use the following lines:

logging on
logging timestamp
logging trap debugging
logging host 192.168.1.100

This turns on the most verbose level of logging.  In some environments, this may overburden the PIX from a CPU perspective, so you can use the following line instead:

logging trap informational

This turns on logging at one level below "debugging" and will not include as much output, but will still give you enough for most troubleshooting scenarios.

f)  Define an NTP server for time synchronization.  This goes along with the syslog recommendation above.  For example:

ntp server 140.221.8.88 source outside prefer

Accurate timestamps are critical when analyzing syslog information.  Also, your other network devices should be using NTP for time synchronzation as well, preferably to the same time source.

g)  Disallow pings from the PIX outside interface.  This will cause the PIX to not respond to ping requests from the Internet in case someone is doing a ping sweep or some other reconnaissance maneuver.

icmp deny any outside

    You can always turn this off with the "no" form of the command if you need to troubleshoot connectivity from the world.

Hope this helps!
0
 

Author Comment

by:PeteJH
ID: 17911205
Thanks very much for your detailed replies....it is most appreciated. I can't wait to tighten/clean up my configs based on your suggestions! I should get to this in the upcomng days and will post my next config as soon as I am done.

Batry_boy, regarding your questions:
Q> First, the access-list statements in your question 1 do not match the access-list statements from the above PIX configuration.  Which access-list statements are correct?
A> I changed IPs at the last minute! In the question, 192.168.30.0 should be 192.168.1.0 (main site network) and 192.168.40.0 should be 192.168.2.0 (remote site network).

Q> If you just want remote access VPN users traffic to destined for the internal network to be tunneled and all of their other traffic to go straight out to the Internet, then you would use the following commands (assuming that the inside network is 192.168.1.0/24)
A> You were right, this is what I wanted. Sorry for not being very clear.

Thanks again!
0

Featured Post

Maximize Your Threat Intelligence Reporting

Reporting is one of the most important and least talked about aspects of a world-class threat intelligence program. Here’s how to do it right.

Join & Write a Comment

Suggested Solutions

Title # Comments Views Activity
Microsoft Advanced Firewall Isolation 6 76
Land attack dropped sonicwall 4 474
Questions on windows ports 13 65
Hardening ScreenOS 8 68
If you are like regular user of computer nowadays, a good bet that your home computer is on right now, all exposed to world of Internet to be exploited by somebody you do not know and you never will. Internet security issues has been getting worse d…
Do you have a windows based Checkpoint SmartCenter for centralized Checkpoint management?  Have you ever backed up the firewall policy residing on the SmartCenter?  If you have then you know the hassles of connecting to the server, doing an upgrade_…
In this tutorial you'll learn about bandwidth monitoring with flows and packet sniffing with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're interested in additional methods for monitoring bandwidt…
This video shows how to remove a single email address from the Outlook 2010 Auto Suggestion memory. NOTE: For Outlook 2016 and 2013 perform the exact same steps. Open a new email: Click the New email button in Outlook. Start typing the address: …

759 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

22 Experts available now in Live!

Get 1:1 Help Now