Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

PIX VPN, Connect made, but can't access Inside Network

--begin ciscomoderator note-- The following post has been edited to remove potentially confidential information. Please refrain from posting confidential information on the site to reduce security risks to your network. -- end ciscomoderator note --

I will appreciate any help that can be offered. I seem to have a symptom of a PIX VPN problem with many solutions, that is; I can connect and establish a SA, but cannot access the network on the other side of the PIX. I’ve tried almost everything I’ve been able to learn here, and come up empty.

Here’s my situation; I have a network of one core router and 14 spokes. Each spoke router services another network. All are private networks in the range. All routers at the spoke have a default gateway that points back to the hub. The hub has a default gateway pointing to the PIX that's located on it’s subnet.The PIX connects to a border router that is Telco equipment and it’s configuration is unknown. The Telco provided the address range of A.B.C.224 The PIX outside interface has an IP of A.B.C.230 I’ve PAT’ed A.B.C.226 and NAT’ed A.B.C.227-A.B.C.229, but you can see that in the config below.

The PIX is used to provide internet service to approximately 100 users. This all works fine. Now my new task has been to get (for now) three users access to the private network (so the from their homes using VPN encryption of broadband internet access. The VPN client workstations are Laptops running Win XP.

OK, What I’ve accomplished so far is to establish an IPSEC tunnel from a client using Cisco VPN Client 3.6.3. My PIX is configured with a VAC, 3DES keys, and Ver 6.2.2 of the PIX Firewall software. I have configured XAUTH (Radius) and am using a Win2K Server to provide RADIUS authentication and using the transform set of ESP-3DES ESP-MD5-HMAC. This is all working as well. The SA gets established and the connection is good. An IP address is assigned from the pool. There is a static route in the core router of IP ROUTE (that last IP is the PIX Inside interface and the subnetted route is the address pool). There is also a route in the PIX of ROUTE 1 (the last route is the core router).

OK, so here’s what’s happening. I connect to my ISP and bring up the VPN Dialer. I connect to the address A.B.C.230 and get a prompt for the RADIUS authentication. I reply and get XAUTH granted. The SA is established and everything is looking great. I try to ping a server on the inside and the pings timeout. On the PIX, with DEBIG CRYPTO IPSEC and ISAKMP running I get the following error to the pings:

IPSEC<ipsec_cipher_handler>: ERR: bad pkt ->

This error occurs for each ping.

Does anyone know where I’ve gone wrong. I still have some hair, please help me save the rest…


Configuration has been sanitized.

PIX Version 6.2(2)

nameif ethernet0 outside security0

nameif ethernet1 inside security100

enable password *********** encrypted

passwd *********** encrypted

hostname Firewall


clock timezone CEST 1

clock summer-time CEDT recurring last Sun Mar 2:00 last Sun Oct 3:00

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


name WebSense

name Backup

name OSHQ

name Radius

access-list outside_cryptomap_dyn_20 permit ip any

access-list VPN permit ip

pager lines 40

logging on

logging timestamp

logging monitor emergencies

logging buffered critical

logging trap critical

logging host inside Radius

interface ethernet0 auto

interface ethernet1 auto

icmp deny any outside

mtu outside 1500

mtu inside 1500

ip address outside A.B.C.230

ip address inside

ip verify reverse-path interface outside

ip audit name Pol1 attack action alarm drop reset

ip audit name Pol2 attack action alarm

ip audit name Pol3 info action alarm drop reset

ip audit name Pol4 info action alarm

ip audit interface outside Pol3

ip audit interface outside Pol1

ip audit interface inside Pol4

ip audit interface inside Pol2

ip audit info action alarm

ip audit attack action alarm

ip local pool Test

ip local pool Access_OSHQ

no failover

failover timeout 0:00:00

failover poll 15

failover ip address outside

failover ip address inside

pdm location Backup inside

pdm location WebSense inside

pdm location inside

pdm location Radius inside

pdm location inside

pdm logging critical 100

pdm history enable

arp timeout 14400

global (outside) 1 A.B.C.227-A.B.C.229 netmask

global (outside) 1 A.B.C.226 netmask

nat (inside) 0 access-list VPN

nat (inside) 1 0 64

route outside A.B.C.225 1

route inside 1

timeout xlate 1:00:00

timeout conn 0:30: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:03:00 absolute uauth 0:01:00 inactivity

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 Radius XXXXXX timeout 10

url-server (inside) vendor websense host WebSense timeout 30 protocol TCP version 1

url-cache dst 128KB

filter url http

http server enable

http OSHQ inside

no snmp-server location

no snmp-server contact

snmp-server community public

no snmp-server enable traps

tftp-server inside Backup \

floodguard enable

sysopt connection permit-ipsec

no sysopt route dnat

auth-prompt prompt Your are accessing a Private Computer Network. This network is Monitored and Illegal Access Attempts are reported to the FBI.

auth-prompt accept Welcome to the WHO? Overseas Division

auth-prompt reject You are UNAUTHORIZED to access this network. A report of your attempt will be made to appropriate agencies. The FBI investigates crimes against this company.

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

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

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

crypto dynamic-map outside_dyn_map 20 set transform-set ESP-3DES-MD5 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

crypto map inside_map client authentication partnerauth

crypto map inside_map interface inside

isakmp enable outside

isakmp enable inside

isakmp policy 20 authentication pre-share

isakmp policy 20 encryption 3des

isakmp policy 20 hash md5

isakmp policy 20 group 2

isakmp policy 20 lifetime 28800

vpngroup SrMgmt address-pool Access_OSHQ

vpngroup SrMgmt dns-server

vpngroup SrMgmt wins-server Backup Backup

vpngroup SrMgmt default-domain oshq

vpngroup SrMgmt idle-time 900

vpngroup SrMgmt password ********

vpngroup Test address-pool Test

vpngroup Test dns-server

vpngroup Test wins-server Backup

vpngroup Test default-domain OSHQ

vpngroup Test idle-time 1800

vpngroup Test password ********

telnet OSHQ inside

telnet timeout 15

ssh timeout 5

terminal width 80


: end


New Member

Re: PIX VPN, Connect made, but can't access Inside Network

Just so I don't mislead anyone. Ping is not the only access that doesn't work. Nothing is getting through. Sorry. If any one is wondering, the PIX is a 515-BUN-UR


New Member

Re: PIX VPN, Connect made, but can't access Inside Network

Found my own answer. Don't put your group address pool within the inside range of IP addresses. I moved the pool to Made the same changes to the access-list and that did the trick. Of course I put a route in the core router for the x.x.127.x back to the PIX.

New Member

Re: PIX VPN, Connect made, but can't access Inside Network

We have just gone through a similar excercise. We are setting up IPSec VPN groups with XAuth. We had previously established aaa services over TACACS+ with the Cisco Secure ACS3.2. We found that after XAuth, the user permissions had to be set inside of the ACS to allow (authorize) particular VPN traffic.

The challenge is you can not rely on your PIX logs and debugs to determine this variable. Check the logs on the ACS box and see what you find.