Re: Cisco Client not working after Watchguard VPN configured

niculac · ‎09-26-2005

We have a Pix 515 running and just recently setup a VPN to a watchguard device which is working but our VPN clients (software based) are now not working for all users. In doing so, I added the following commands and now the VPN client is not able to connect. The client software now does not even prompt for username/password. The commands added are:

ACCESS-LIST FIREDOOR PERMIT IP x.x.x.x 255.255.255.0 x.x.x.x 255.255.255.0

CRYPTO IPSEC TRANSFORM-SET PIXTRANSFORM esp-3des esp-sha-hmac

CRYPTO MAP FIREDOORMAP 10 IPSEC-ISAKMP

CRYPTO MAP FIREDOORMAP 10 MATCH ADDRESS FIREDOOR

CRYPTO MAP FIREDOORMAP 10 SET PEER x.x.x.x

CRYPTO MAP FIREDOORMAP 10 SET TRANSFORM-SET PIXTRANSFORM

CRYPTO MAP FIREDOORMAP 10 SET SECURITY-ASSOCIATION LIFETIME SECONDS 360 KILOBYTES 8192

CRYPTO MAP FIREDOORMAP INTERFACE outside

SYSOPT CONNECTION PERMIT-IPSEC

NAT 0 ACCESS-LIST FIREDOOR

ISAKMP POLICY 20 AUTHENTICATION PRE-SHARE

ISAKMP POLICY 20 ENCRYPTION DES

ISAKMP POLICY 20 HASH SHA

ISAKMP POLICY 20 GROUP 1

ISAKMP POLICY 20 LIFETIME 86400

Anyone know what command is conflicting with our VPN client and how I could resolve it so both the watchguard VPN and clients could connect? The VPN between the PIX and a Watchguard is working fine though.

Attached is the complete pix config.

Thanks in advance for a reply.

jackko · ‎09-26-2005

there are 2 statements with acl firedoor and with both private and public ip masked, i assume:

ACCESS-LIST FIREDOOR PERMIT IP 255.255.255.0 255.255.255.0

nat (inside) 0 access-list FIREDOOR

CRYPTO MAP FIREDOORMAP 10 MATCH ADDRESS FIREDOOR

the pix with crypto map firedoormap 10 looks up the acl firedoor in determining whether the packet should or should not be encrypted and sent to the remote peer (watchguard). the reason why remote vpn doesn't work is because the pix will encrypt/send any traffic with destination to the remote peer (watchguard) as per the 2nd line of acl firedoor.

try

ACCESS-LIST no_nat PERMIT IP 255.255.255.0 255.255.255.0

nat (inside) 0 access-list no_nat

no ACCESS-LIST FIREDOOR PERMIT IP 255.255.255.0 255.255.255.0

clear xlate

gfullage · ‎09-26-2005

You defined a new crypto map (called FIREDOORMAP) and assigned that to the outside interface. You can only have one crypto map assigned to an interface, so your existing VPN client map (called AMWELDmap) is now no longer assigned anywhere and therefore is not working.

If you have both a LAN-to-LAN tunnel and a VPN client tunnel coming in on the outside interface you need to combine both crypto maps into one and assign that to the outside interface. Do the following to define a VPN client map and add it to the existing FIREDOORMAP assigned on teh interface:

crypto map FIREDOORMAP 99 ipsec-isakmp dynamic dynamicvpnmap

crypto map FIREDOORMAP client configuration address initiate

crypto map FIREDOORMAP client configuration address respond

crypto map FIREDOORMAP client authentication AMWELDauth

You'll also need to split up your crypto access-list and your LAN-to-LAN tunnel access-list. Your existing FIREDOOR access-list defines the traffic that will be tunnelled across the LAN-to-LAN tunnel. You need to define a new "nat 0" ACL that includes both the LAN-to-LAN tunnel traffic AND the VPN client traffic, the following should do:

The following two lines are your existing FIREDOOR ACL but with a new name called NONAT, the third line is defining traffic to your VPN client pool:

access-list NONAT permit ip x.x.x.x 255.255.255.0 x.x.x.x 255.255.255.0

access-list NONAT permit ip x.x.x.x 255.255.255.0

nat (inside) 0 access-list NONAT

Leave your existing FIREDOOR ACL in place, you still need it for the crypto map definition.

jackko · ‎10-05-2005

just wondering how you go.

niculac · ‎10-05-2005

Thanks for the info and follow-up. It actually is not going very well. Since I added those commands the FireDoor LAN to LAN VPN has dropped and has currently been down for over 12 hours now. It might not be because of the new config, in fact I tried to back everything back out but still the VPN is down. This was still working after i put in the new commands and wr mem, it stopped a few hours after, then came back up, then went down after a few hours and now has been down ever since (that was yesterday).

Also, the remote client VPN is now authenticating users and making it appear that you are logged in but there is no communication happening from the remote user and the internal LAN. Almost as if the VPN is not giving the user a internal IP. I have attached the current config if you would have time to look over. Any other input would be GREATLY appreciated.

jackko · ‎10-05-2005

commands missing from the config you've just posted. e.g. nat 0

it would be better if you can post another config with masked public ip only not both public and private ip. it's very time consuming to read the config like this.

niculac · ‎10-05-2005

I have since relized the NAT 0 missing command. I added it back, LAN to LAN still didn't come back up. I removed all the new commands, still nothing. Then about 20 minutes later it came back up, so not sure if it is related to the config or not (I assume that NAT command missing was definately a problem).

I attached the config with the just the external IPs masked. So do you see anything keeping the Client VPN from communicationing with the LAN (even though it is now authenticating them) or any issue with the Firedoor VPN LAN to LAN?

Thanks again.

jackko · ‎10-05-2005

1. only one crypto map is allowed. so consolidate both crypto map amweldmap and firedoormap into one crypto map. you can distinuish the two with different number e.g. you've got crypto map firedoormap 10, so you can user crypto map firedoormap 20 replacing the crypto map amweldmap.

2. don't use the same subnet as the vpn client pool. so change your existing pool from 192.1.1.190-192.1.1.199 to sth different, since the lan behind the pix is 192.1.1.0/24.

below is a sample, which has both lan-lan vpn and remote vpn access configured.

access-list 101 permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0

access-list 101 permit ip 192.168.1.0 255.255.255.0 10.1.1.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 120 permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0

ip address inside 192.168.1.10 255.255.255.0

ip local pool ippool 10.1.1.51-10.1.1.101

global (outside) 1 interface

nat (inside) 0 access-list 101

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

sysopt connection permit-ipsec

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

crypto dynamic-map dynmap 10 set transform-set myset

crypto map myvpn 10 ipsec-isakmp dynamic dynmap

crypto map myvpn 20 ipsec-isakmp

crypto map myvpn 20 match address 110

crypto map myvpn 20 set peer

crypto map myvpn 20 set transform-set myset

crypto map myvpn client configuration address initiate

crypto map myvpn client configuration address respond

crypto map myvpn client authentication LOCAL

crypto map myvpn interface outside

isakmp enable outside

isakmp key ******** address netmask 255.255.255.255 no-xauth no-config-mode

isakmp identity address

isakmp nat-traversal 20

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 vpnclient address-pool ippool

vpngroup vpnclient split-tunnel 120

vpngroup vpnclient idle-time 1800

vpngroup vpnclient password ********

niculac · ‎10-06-2005

I am following everything except #2. If i change the pool that I assign remote vpn clients, how will they communicate on the LAN? The LAN ip range is 192.1.1.0, which I don't see referenced at all in teh config. I would assume that needs to be in a access list that allows 192.168.1.0 network and the ippool network to communicate with the internal network, right?

jackko · ‎10-06-2005

if the vpn client pool range is part of the lan behind the pix, remote vpn may or may not work properly.

e.g.

remote vpn user <--> internet <--> pix <--> lan

remote vpn user - assigned ip 10.0.0.100

lan behind pix - subnet 10.0.0.0/24

let say there is a file server with ip 10.0.0.200. the remote user want to access the server via the vpn. firstly, the remote user will send an request, and then the server will response. however, when the server tries to send a response, it looks up the destination address. the destination address is the vpn client assigned address, so it's 10.0.0.100 and from the server point of view, it's local. so the server will send an arp request out. arp request would not be encrypted/sent to the remote pc, as arp request is a broadcast.

that's why when you look at cisco reference, the vpn client pool is always separate to the lan behind the pix.

you are absolutely right in saying that an acl is required. if you take another look at my sample config.