PIX 6.3(4) software vpn client ver 4.8 support

[phaddad]

I can't seem to get a Cisco software VPN

client ver 4.8 to connect to a PIX running

6.3(4) and can't find any reference in the

4.8 release notes regarding PIX os support.

Is this supported, indicating that I have a

config problem?

thanks,

Peter

[jackko]

the issue is very likely to relate to the config. the reason being pix v6.3.x is very recent and it should be supported by the latest vpn client software.

below are the sample codes for configuring remote vpn access on pix:

access-list 101 permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0

access-list 120 permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0

nat (inside) 0 access-list 101

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

isakmp identity address

isakmp nat-traversal 20

crypto ipsec transform-set vpnset esp-3des esp-md5-hmac

ip local pool ippool 10.1.1.11-10.1.1.21

vpngroup vpnclient address-pool ippool

vpngroup vpnclient idle-time 1800

vpngroup vpnclient dns-server x.x.x.x

vpngroup vpnclient password xxxx

vpngroup vpnclient split-tunnel 120

crypto dynamic-map dynmap 10 set transform-set vpnset

crypto map remote_vpn 20 ipsec-isakmp dynamic dynmap

username cisco password cisco123

aaa-server LOCAL protocol local

crypto map remote_vpn client authentication LOCAL

crypto map remote_vpn client configuration address initiate

crypto map remote_vpn client configuration address respond

for further assistance, please post the entire config with public ip masked.

[phaddad]

Thanks for the help.

I changed the isakmp policy from AES-SHA to 3des-md5,

as well as the crypto ispec transfom for the dynamic

portion of the crypto map and things seem to be

working now. I do have a couple of questions

regarding this and VPN connectivity in general

if you have time.

1>AES & SHA aren't supported on the sw client?

2>I'm using the sysopt connection permit-ipsec

command. I want to make sure I understand how the

security works on this. My understanding is that

no interface acls are applied to the decrypted

tunnel traffic stream, so that the client has

full access to the inside networks as defined

in the crypto map match acl. Is this correct?

3>I've read that the crypto map match acls identify

traffic to be encrypted/decrypted by IPSEC.

However the ACLs all seem to use the native

address ranges that would be encapsulated within

IPSEC. For example:

access-list 100 permit ip 10.10.11.0 255.255.255.0 10.0.8.0 255.255.255.0

So if an encrypted packet from the peer at the

10.0.8.0/24 end shows up on the outside interface

of the local PIX, doesn't it have to be decrypted

in order to determine the real source IP? So it

seems like a chicken and egg problem.

4>So if #2 is correct, what would be the

implementation details of the alternative, eg

not enabling sysopt connection permit-ipsec, and

using interface acls to control the traffic to the

appropriate inside interfaces (assuming that there

are many "inside" interfaces that don't trust each

other). I'm interested in both the static and

dynamic cases in a 6.3(4) environment.

thanks.

Peter

[jackko]

1. i couldn't found much doco on v4.8 but i do believe it is supported even on v4.6. just wondering if the group was 2 as well before replacing aes with 3des.

http://www.cisco.com/en/US/products/sw/secursw/ps2308/products_administration_guide_chapter09186a00802d3ac3.html#wp1168133

2. with "sysopt connection permit-ipsec" enabled, all crypto traffic will not be ignored and not checked by any acl. there are several ways to retrict remote vpn access. e.g. split tunneling. one difference between using "sysopt" and split tunneling as an attempt to restrict remote vpn access is that with split tunneling, the restriction is up to the ip level; whereas with "sysopt", the restriction is up to the protocol/port level.

3. the acl is not used as a filter. i.e. not being used to permit/deny traffic as a typical acl. this is used by the pix to determine what sort of traffic should or should not be encrypted.

4. as mentioned, if ip level is fine, then all required would be split tunneling.

e.g.

access-list 110 permit ip host

vpngroup vpnclient split-tunnel 110

then remote vpn host will have access to this specific server and nothing else, however, the server is "open" to the remote vpn host. in other words, all protocol/port are permitted.

alternatively, as you already know, disable the command "sysopt connection permit-ipsec" is another way.

with this command disabled, inbound acl will be required for vpn traffic.

e.g.

no sysopt connection permit-ipsec

access-list 111 permit tcp host eq 3389

access-group 111 in interface outside

[phaddad]

It was DH group 2 before.

you said:

with "sysopt connection permit-ipsec" enabled, all crypto traffic will not be ignored and not checked by any acl. there are several ways to retrict remote vpn access. e.g. split tunneling. one difference between using "sysopt" and split tunneling as an attempt to restrict remote vpn access is that with split tunneling, the restriction is up to the ip level; whereas with "sysopt", the restriction is up to the protocol/port level.

did you mean "will be ignored" in the 1st sentence?

On point 3 it was thinking about the other direction,

eg when the crypto acl is used to decrypt inbound

traffic. Doesn't it have to decrypt the packet to

see if the source/dest addresses match the acl? But

its supposed to use the acl to determine if it

should decrypt the packet?

On point 4, I've always assumed that split tunneling

controlled which traffic was encryted at the client

end, eg the split tunnel acl was downloaded to the

client. I didn't think that the split tunnel acl

actually enforced access policy on the PIX.

I will try the "no sysopt" path with acls on the

outside i/f, that sounds like the safest approach.

So in that acl (111 in your example), if one is using

private (RFC 1918) address space for both the server

and vpn pool address, one should use those in the

acl even though they will be encapsulated within

ipsec. That would imply that after the packet is

decrypted then the outside i/f acl is applied, is

that correct? Sorry I'm being painfully explicit,

I just want to make sure that I understand this.

There doesn't seem to be any external documentation

on how this process really works, at least that I can

find.

thanks for your help.

Peter

[jackko]

1. please excuse me for the typo. yes, i mean that all crypto traffic will be ignored with the command "sysopt connection permit-ipsec" disabled.

3. i believe the crypto acl is used in both directions.

4. split tunneling was not designed to use as a tool to restrict remote vpn access, however, it could be used to restrict at some degree.

with the command "sysopt connection permit-ipsec" disabled, pix will first decrypt the packet and examine the packet against the inbound acl.

[bertels.p]

Hi Peter;

I have a PIX 515e with 6.3 on it.. I have clients using 4.8 and they connect fine. If possible paste your conf without the outsite ip and usernames and passwords..

Cheers

pb

Doh! missed all the replys...sorry..