Re: VPN Connection - Authenticates but cant access the LAN

luke.cassar · ‎08-03-2004

Hi All,

we have a PIX 515E which I did not realise was already authenticating users for VPN (my previous post). Anyways, it turns out that the VPN configuration on the PIX is configured to authenticate against a Windows 2003 IAS server, and this works fine, with users authenticating sucessfully and getting an IP address from the appropriate range.

However these users can then only ping the PIX and things external to the PIX, they cant ping anything on the other side of the PIX (being the whole network).

I have had a look at the configuration, but cant see any obvious faults.. I am just wondering is there anything specific that I should look for. Also, are there parts of the config it would be helpful to put here for review?

Thanks in advance for your help.

Luke

jmia · ‎08-04-2004

Luke,

Sounds like it might be a crypto ACL issue. Can your Dial-Up vpn users ping a server on the inside LAN when they have been authenticated?

Can you post your full pix config here (takeout any sensitive info)

Thnaks -

Jay

bvanniekerk · ‎08-04-2004

Hi Luke

I've had something similar to your problem. Make sure you can ping the internal networks from the PIX console.

Remember that you need to route traffic from your internal users to the network assigned to the VPN clients.

Hope you get sorted.

Byron

Richard Burts · ‎08-04-2004

It is possible that there is something that prevents packets from the VPN clients getting to the inside network. But I would look more closely at whether responses from devices inside the network get back to the PIX. Are there entries for the pool of addresses of the PIX in the routing tables of the inside network?

I might also suggest that you run debug ip icmp on one of the routers in the inside network and then attempt to ping that router from one of the VPN client machines. This will show whether the ping is getting to the router or not. Or alternatively I might run debug ip packet where is an extended access list with permits for the host address of the VPN client as source and a permit for the host address of the VPN client as destination. Then attempt to ping, or traceroute, or telnet to the router. The debug will report only traffic from or to the VPN client.

HTH

Rick

HTH

Rick

luke.cassar · ‎08-04-2004

Thankyou all for your responses.

I have some of the configuration concerning the VPN configuration of the PIX. I have just verified that there is a route from the core LAN router to the PIX (default route, so any traffic from the vpn subnet should be able to get back to the pix).

Please let me know if anything looks amiss in the below.

Thanks again,

Luke Cassar

access-list vpngrp1_splitTunnelAcl permit ip 172.16.0.0 255.255.0.0 any

access-list inside_outbound_nat0_acl permit ip 172.16.0.0 255.255.0.0 vpnpool 255.255.255.0

access-list outside_cryptomap_dyn_20 permit ip any vpnpool 255.255.255.0

route outside 0.0.0.0 0.0.0.0 *Internet Router LAN* 1 (*Internet Router LAN* is next hop before ISP - public IP)

route inside 172.16.0.0 255.255.0.0 192.168.5.1 1 (192.168.5.1 is the core LAN router)

route inside vpnpool 255.255.255.0 192.168.5.1 1 (192.168.5.1 is the core LAN router)

route inside 192.168.0.0 255.255.0.0 192.168.5.1 1 (192.168.5.1 is the core LAN router)

nat (inside) 0 access-list inside_outbound_nat0_acl

nat (inside) 2 vpnpool 255.255.255.0 0 0

nat (inside) 1 172.16.0.0 255.255.0.0 0 0

nat (inside) 1 192.168.0.0 255.255.0.0 0 0

static (inside,outside) *Mail Server Public* *Mail Server Private* netmask 255.255.255.255 0 0

sysopt connection permit-ipsec

crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac

crypto dynamic-map outside_dyn_map 20 match address outside_cryptomap_dyn_20

crypto dynamic-map outside_dyn_map 20 set transform-set ESP-DES-MD5

crypto map outside_map 65535 ipsec-isakmp dynamic outside_dyn_map

crypto map outside_map client authentication partnerauth

crypto map outside_map interface outside

isakmp enable outside

isakmp policy 20 authentication pre-share

isakmp policy 20 encryption des

isakmp policy 20 hash md5

isakmp policy 20 group 2

isakmp policy 20 lifetime 86400

vpngroup vpngrp1 address-pool vpnpool1

vpngroup vpngrp1 dns-server *LAN DNS SERVERS*

vpngroup vpngrp1 wins-server *LAN WINS SERVERS*

vpngroup vpngrp1 default-domain *domain name*

vpngroup vpngrp1 split-tunnel vpngrp1_splitTunnelAcl

vpngroup vpngrp1 idle-time 1800

vpngroup vpngrp1 password ********

jmia · ‎08-04-2004

Luke,

Here's a config I've just compiled and tested and it works fine. Also, as a reference check this URL:

http://www.cisco.com/warp/public/110/pix3000.html

access-list nonat permit ip 10.0.1.0 255.255.255.0 10.0.8.0 255.255.255.0

ip local pool VPN_DIAL 10.0.8.1-10.0.8.254

nat (inside) 0 access-list nonat

sysopt connection permit-ipsec

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

crypto dynamic-map dynmap 10 set transform-set vpndial

crypto map VPDN_ACCESS 10 ipsec-isakmp dynamic dynmap

crypto map VPDN_ACCESS interface outside

isakmp enable outside

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 VPDN_IN address-pool VPN_DIAL

vpngroup VPDN_IN dns-server

vpngroup VPDN_IN wins-server

vpngroup VPDN_IN default-domain

vpngroup VPDN_IN split-tunnel nonat

vpngroup VPDN_IN idle-time 1800

vpngroup VPDN_IN password

vpngroup VPND_IN idle-time 1800

Hope this helps and let me know how you get on.

Jay

luke.cassar · ‎08-08-2004

Thanks Jay,

this has provided a good reference to compare the current config against.

One thing that has been brought to my attention though is that the VPN pool in our setup is 172.16.75.1-172.26.75.254, and this is meant to be a class C subnet, however clients connecting to the VPN are recieving a 255.255.0.0 subnet mask instead of 255.255.255.0 subnet mask.

We could not find anywhere to specify a subnet mask for the client pool, and looking at the access list rules to stop putting NAT on traffic headed to the VPN pool, it reads as follows:

access-list inside_outbound_nat0_acl permit ip 172.16.0.0 255.255.0.0 vpnpool 255.255.255.0

The source part of that ACL is fine as the lan spans a lot of the 172.16.X.X ranges (most lan subnets are 255.255.252.0), but the vpnpool part has the wrong mask. Is that part relevant at all?

Also, is there any way to specify what subnet mask a VPN client recieves, or should we change the pool to something which will default to a proper class C subnet mask?

Thanks again for your help in relation to this matter.

Regards,

Luke