From: Szabo, Vilmos (VS183600@exchange.UnitedKingdom.NCR.COM)
Date: Thu Jun 12 2003 - 05:34:18 GMT-3
Joe,
You are right. To my surprise the wild-card pre-shared key authentication
works together with vpngroup definitions.
I tested EZVPN Client authenticated by 'isakmp key ***** address x.y.x.w
netmask 255.255.255.255' plus added 'vpngroup <name> split-tunnel <acl>'.
After Client is authenticated the mode config pushed down and split-tunnel
operates as defined via acl.
Until now I believed that two technique can not be mixed. I thought that
vpngroup configuration exclude the old style definitions.
Once again something that is not clearly described in documentation and only
the practice can reveal it.
Regards,
Vilmos
-----Original Message-----
From: Joe Deleonardo [mailto:jdeleonardo@cox.net]
Sent: 12 June 2003 01:00
To: George Hansen; security@groupstudy.com; ccielab@groupstudy.com
Subject: Re: PIX VPN client remote access question
Oh, I see what you're talking about.
I was think of split tunneling from behind the pix. That's why I mentioned
nat 0.
But bear with me for a second... in this Cisco config:
http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_62/config
/basclnt.htm#997762
I don't see why using the wildcard as opposed to the 32 bit match peer...
why you still couldn't use the vpngroup split-tunnel. I mean it's steps 8,
9 & 10 that allow a client to connect... right?
So... well... I mean it seems it would probably still work to use a 32 bit
mask with the key AND use the vpngroup command.
No? Am I missing something?
Step 3 Configure a wildcard, pre-shared key:
isakmp key cisco1234 address 0.0.0.0 netmask 0.0.0.0
Step 8 Create a dynamic crypto map:
crypto dynamic-map cisco 4 set transform-set strong-des
Specify which transform sets are allowed for this dynamic crypto map entry.
Step 9 Add the dynamic crypto map set into a static crypto map set:
crypto map partner-map 20 ipsec-isakmp dynamic cisco
Step 10 Apply the crypto map to the outside interface:
crypto map partner-map interface outside
Step 11 Enable Xauth:
crypto map partner-map client authentication partnerauth
Step 12 Configure IKE Mode Config related parameters:
ip local pool dealer 10.1.1.1-10.1.1.254
----------------------------------------------------------------------------
----
Note To configure the Cisco VPN 3000 Client version 2.5/2.6, include
the crypto map partner-map client configuration address initiate command in
this step.
----------------------------------------------------------------------------
----
Step 13 Configure Cisco VPN 3000 Client policy attributes to download to
the Cisco VPN Client:
vpngroup superteam address-pool dealer
vpngroup superteam dns-server 10.0.0.15
vpngroup superteam wins-server 10.0.0.15
vpngroup superteam default-domain example.com
vpngroup superteam split-tunnel 80
vpngroup superteam idle-time 1800
----- Original Message -----
From: "George Hansen" <ghansen@stealthnetwork.com>
To: <security@groupstudy.com>; <ccielab@groupstudy.com>
Cc: "Joe Deleonardo" <jdeleonardo@cox.net>
Sent: Wednesday, June 11, 2003 3:27 PM
Subject: RE: PIX VPN client remote access question
I think you will lose the split-tunneling specifically because you are
not using the 'vpngroup split-tunnel' command. I don't think you can
support split-tunnel on the PIX without this command.
The 'nat 0' will not affect split-tunnel. 'nat 0' would only affect
traffic that has reached the PIX, while split-tunnel directs traffic
away from the PIX (at the client). In addition, if it did reach the PIX
the PIX would refuse to route traffic it had just received on it's
outside interface back out the same interface to the Internet.
Also, you are correct that you can use ACLs on the outside to allow
specific VPN clients to come in based on ip address and traffic type or
tcp port. It cannot be used at the same time as 'sysop connection
ipsec-permit', just as you've stated.
HTH,
George
-----Original Message-----
From: Joe Deleonardo [mailto:jdeleonardo@cox.net]
Sent: Wednesday, June 11, 2003 2:14 PM
To: Ji, Daniel; security@groupstudy.com
Cc: ccielab@groupstudy.com
Subject: Re: PIX VPN client remote access question
Daniel,
I think everyone is a little right in what they're saying.
With out the Sysopt command the firewall will not accept IPSec
connections
unless there are specific access-lists or conduits configured. Sysopt
commands are used to bypass conduit or access-list permit commands. All
packets that arrive on the VPN tunnel will not be checked by the
conduits or
acls configured on the pix with the sysopt command.
The first acl example will allow a VPN to established... if they're
authenticated, but only encrypt traffic back to those addresses. If it
doesn't match the nat 0 acl then... assuming outbound connections are
allowed... the traffic will be NATed... and sent out of the pix in clear
-
to the RFC 1918 address... which of course won't be routed on the
Internet
and then dropped.
I haven't tried this, but I think I understand it well enough to say
that if
you remove the sysopt command and add an acl to the outside interface
from
the specific ips that you want to access the VPN with ports 50, 51 & 500
only those hosts should be able to access the VPN. That's if they are
VPN
clients with static IPs.
Of if it's just a matter of allowing specific remote sites to connect
then
Vilmos is correct as well with the 'isakmp key ****** address x.y.z.w
netmask 255.255.255.255' method to identify a peer. But I don't think
you'd
loose split tunneling... I mean as long as you continued to use NAT 0.
I guess it would help to know a little bit more about the problem. The
specific situation and why? I ask because I wonder if there's something
that AAA could do.
Well I hope I helped and didn't cofuse the situation more.
Cheers,
Joe
----- Original Message -----
From: "Charles Church" <cchurch@wamnet.com>
To: "Ji, Daniel" <DJi@ahs.llumc.edu>; <security@groupstudy.com>
Cc: <ccielab@groupstudy.com>
Sent: Wednesday, June 11, 2003 6:26 AM
Subject: RE: PIX VPN client remote access question
> Daniel,
>
> The access-list won't do anything. Your problem is the
> "sysopt connection permit-ipsec" line. It allows (I think) both ESP
and
IKE
> (UDP 500, and IP protocol 50) to always connect TO the PIX. It will
not
> allow those THROUGH the PIX however. I don't think there are any
options
on
> the PIX to limit connection source addresses. But between shared
keys,
> certificates, and extended authentication using local accounts or
TACACS,
it
> should be pretty secure being open to anyone. Of course, you could
always
> block the IPSec on a router outside of the PIX...
>
> Chuck Church
> CCIE #8776, MCNE, MCSE
> Wam!Net Government Services
> 13665 Dulles Technology Dr. Ste 250
> Herndon, VA 20171
> Office: 703-480-2569
> Cell: 585-233-2706
> cchurch@wamnet.com
> PGP key:
http://pgp.mit.edu:11371/pks/lookup?search=chuck+church&op=index
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> Ji, Daniel
> Sent: Tuesday, June 10, 2003 8:18 PM
> To: security@groupstudy.com
> Cc: ccielab@groupstudy.com
> Subject: PIX VPN client remote access question
>
>
> Hi folks,
> I am working on setting up a PIX 501 to do VPN client remote access.
> Everything works fine except that the requirement is to have VPN
client
> SOURCE IP ADDRESS checked for access. In other words, only VPN clients
> with specific IP addresses will be allowed to connect to PIX to setup
> VPN tunnel. How do I accomplish this? I've tried AccessGroup on the
> outside interface but didn't work. Any PIX/VPN guru help me out here?
> Thanks a million!
>
> Daniel Ji
>
------------------------------------------------------------------------
> PIX Config fllows:
>
>
> PIX Version 6.2(2)
>
> nameif ethernet0 outside security0
>
> nameif ethernet1 inside security100
>
> enable password tVS.P/in/fhLI0xc encrypted
>
> passwd 2KFQnbNIdI.2KYOU encrypted
>
> hostname PIX
>
> domain-name xxxx
>
> fixup protocol ftp 21
>
> fixup protocol http 80
>
> fixup protocol h323 h225 1720
>
> fixup protocol h323 ras 1718-1719
>
> fixup protocol ils 389
>
> fixup protocol rsh 514
>
> fixup protocol rtsp 554
>
> fixup protocol smtp 25
>
> fixup protocol sqlnet 1521
>
> fixup protocol sip 5060
>
> fixup protocol skinny 2000
>
> names
>
> access-list 101 permit ip 192.168.0.0 255.255.255.0 192.168.0.0
> 255.255.255.0
>
> access-list 10 permit ip host 10.251.31.25 any
>
> pager lines 24
>
> interface ethernet0 10baset
>
> interface ethernet1 10full
>
> mtu outside 1500
>
> mtu inside 1500
>
> ip address outside 10.251.31.190 255.255.255.0
>
> ip address inside 192.168.0.1 255.255.255.0
>
> ip audit info action alarm
>
> ip audit attack action alarm
>
> ip local pool medipool 192.168.0.10-192.168.0.15
>
> pdm history enable
>
> arp timeout 14400
>
> nat (inside) 0 access-list 101
>
> access-group 10 in interface outside
>
> route outside 0.0.0.0 0.0.0.0 10.251.31.190 1
>
> timeout xlate 3:00:00
>
> timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323
> 0:05:00 sip 0:30:00 sip_media 0:02:00
>
> timeout uauth 0:05:00 absolute
>
> aaa-server TACACS+ protocol tacacs+
>
> aaa-server RADIUS protocol radius
>
> aaa-server LOCAL protocol local
>
> aaa-server partnerauth protocol radius
>
> aaa-server partnerauth (inside) host 192.168.0.8 cisco123 timeout 5
>
> aaa-server partnerauth (inside) host 143.197.69.113 cisco123 timeout 5
> no snmp-server location
>
> no snmp-server contact
>
> snmp-server community public
>
> no snmp-server enable traps
>
> floodguard enable
>
> sysopt connection permit-ipsec
>
> no sysopt route dnat
>
> crypto ipsec transform-set mediset esp-3des esp-md5-hmac
>
> crypto dynamic-map dynmap 10 set transform-set mediset
>
> crypto map medimap 10 ipsec-isakmp dynamic dynmap
>
> crypto map medimap client configuration address initiate
>
> crypto map medimap client configuration address respond
>
> crypto map medimap interface outside
>
> isakmp enable outside
>
> isakmp key ******** address 10.251.31.25 netmask 255.255.255.255
>
> isakmp identity address
>
> isakmp policy 10 authentication pre-share
>
> isakmp policy 10 encryption 3des
>
> isakmp policy 10 hash md5
>
> isakmp policy 10 group 2
>
> isakmp policy 10 lifetime 86400
>
> vpngroup medigroup address-pool medipool
>
> vpngroup medigroup dns-server 143.197.69.194
>
> vpngroup medigroup wins-server 143.197.69.194
>
> vpngroup medigroup default-domain xxxxx
>
> vpngroup medigroup split-tunnel 101
>
> vpngroup medigroup idle-time 1800
>
> vpngroup medigroup password ********
>
> telnet timeout 5
>
> ssh timeout 5
>
> terminal width 80
>
> Cryptochecksum:448418097fa51752de762f0c0f02d55c
>
> : end
>
> [OK]
>
>
>
> Confidentiality Note:
>
> The preceding e-mail message (including any attachments) contains
> information that may be confidential, protected by applicable legal
> privileges, or constitute non-public information. It is intended to be
> conveyed only to the designated recipient(s). If you are not an
intended
> recipient of this message, please notify the sender by replying to
this
> message and then delete it from your system. Use, dissemination,
> distribution or reproduction of this message by unintended recipients
is
not
> authorized and may be unlawful.
[GroupStudy removed an attachment of type application/octet-stream which had
a name of note3.gif]
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:10:57 GMT-3