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

Connectivity problem with PIX as VPN server

I plan on using PIX 515e as VPN concentrator for remote clients to access my dmz network. The config of pix is as follows:

PIX Version 8.0(4)


hostname pixfirewall

enable password 8Ry2YjIyt7RRXU24 encrypted

passwd 2KFQnbNIdI.2KYOU encrypted



interface Ethernet0

nameif outside

security-level 0

ip address


interface Ethernet1

no nameif

security-level 100

no ip address


interface Ethernet1.1

description management interface in vlan1

vlan 1

nameif management

security-level 100

ip address


interface Ethernet1.4

description internal side of office network

vlan 4

nameif office-lan

security-level 100

ip address


interface Ethernet1.104

vlan 104

nameif office-dmz

security-level 50

ip address


interface Ethernet2


no nameif

no security-level

no ip address


interface Ethernet3


no nameif

no security-level

no ip address


interface Ethernet4


no nameif

no security-level

no ip address


interface Ethernet5


no nameif

no security-level

no ip address


ftp mode passive

access-list 101 extended permit ip any

access-list dmz-no-nat extended permit ip any

access-list split-office-dmz standard permit

pager lines 24

mtu outside 1500

mtu management 1500

mtu office-lan 1500

mtu office-dmz 1500

ip local pool pool-office-dmz mask

no failover

icmp unreachable rate-limit 1 burst-size 1

no asdm history enable

arp timeout 14400

nat (office-dmz) 0 access-list dmz-no-nat

route outside yyy.yyy.yyy.yyy 1

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00

timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00

timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute

dynamic-access-policy-record DfltAccessPolicy

aaa authentication ssh console LOCAL

no snmp-server location

no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart

crypto ipsec transform-set EzVPN esp-des esp-md5-hmac

crypto ipsec security-association lifetime seconds 28800

crypto ipsec security-association lifetime kilobytes 4608000

crypto dynamic-map EzVPN-dynmap 5 set transform-set EzVPN

crypto dynamic-map EzVPN-dynmap 5 set security-association lifetime seconds 28800

crypto dynamic-map EzVPN-dynmap 5 set security-association lifetime kilobytes 4608000

crypto map EzVPN-map 60 ipsec-isakmp dynamic EzVPN-dynmap

crypto map EzVPN-map interface outside

crypto isakmp enable outside

crypto isakmp policy 1

authentication pre-share

encryption des

hash md5

group 2

lifetime 86400

crypto isakmp policy 65535

authentication pre-share

encryption 3des

hash sha

group 2

lifetime 86400

telnet timeout 5

ssh office-lan

ssh timeout 10

ssh version 2

console timeout 0

threat-detection basic-threat

threat-detection statistics access-list

no threat-detection statistics tcp-intercept

group-policy vpn-office-dmz internal

group-policy vpn-office-dmz attributes

vpn-tunnel-protocol IPSec

split-tunnel-policy tunnelspecified

split-tunnel-network-list value split-office-dmz

vlan 104

tunnel-group tun-office-dmz type remote-access

tunnel-group tun-office-dmz general-attributes

address-pool pool-office-dmz

default-group-policy vpn-office-dmz

tunnel-group tun-office-dmz ipsec-attributes

pre-shared-key *


class-map inspection_default

match default-inspection-traffic



policy-map type inspect dns preset_dns_map


  message-length maximum 512

policy-map global_policy

class inspection_default

  inspect dns preset_dns_map

  inspect ftp

  inspect h323 h225

  inspect h323 ras

  inspect rsh

  inspect rtsp

  inspect esmtp

  inspect sqlnet

  inspect skinny

  inspect sunrpc

  inspect xdmcp

  inspect sip

  inspect netbios

  inspect tftp


service-policy global_policy global

prompt hostname context

(Username section and external ips omitted in sake of paranoia)

For remote client i use cisco vpn client 5.0.07

Clients can connect just fine, but can't ping office-dmz interface (which i expect should be possible) and pix cant ping remote client (printing "?" - unknown packet type), besides when i see stats on client there is 100 byte increase in recieved traffic for every ping from PIX.

Also for connected client created strange, in my opinion, route:

S [1/0] via yyy.yyy.yyy.yyy, outside  (yyy - is default gteway)

When in my opinion it should be like is directly connected, Virtual1234

So the question is is my problem related to ACLs? (can't ping)

Or is it IPSec related? (Unknown packet type may mean that something wrong with decrypting echo_replies on PIX)

Or is in a routing problem? (Strange route to client)

Or is there something else that i'm missing complitly?


Connectivity problem with PIX as VPN server

Hi Artyom,

is client VPN established correctly?

Regarding ACL's I didn't noticed that your acess-list is applied to any of your interface ip access-group statement) so in this case your access list will not work.

Next crypto isakmp policy 65535 and below is used for other VPN?

Regarding routes applied after VPN establishment seems correct becasou your IP pool for VPN clients is in range See line

ip local pool pool-office-dmz mask 

First VPN client will get IP adress. You should choose IP range which don't conflict with hosts in your network.

Best Regards,


Community Member

Connectivity problem with PIX as VPN server

Hi, Jan

Thanks for your time.

Yes client succesfully establishes connection to PIX and i can't see any errors or warns in debug level logs of a client.

Yeah. i know that) access lists created right now is for disabling nat for client network (dmz-no-acl) and creating split tunneling for client (split-office-dmz) so not appling them to interfaces was a desighn feature) I did not really knoww is pix working on basis "everything that is not restricted is allowed" (and than acls is not a problem here) or "everything that is not allowed is restricted" (and than i simply need to add permitting acls)

policy 65535 was added accordingly to one of the tutorials as "default policy for other cases" but clients never actualy fallthrough to that policy. And besides i've tried to remove it just in case - no luck.

problem with routes is not that address space is shared and there is some conflict. There is logical gap for me because PIX creates next-hop route via it's default gateway for address of a remote client. I can't see any logic here because every vpn client is directly connected to PIX via Virtual interface dedicated to that tunnel.


Connectivity problem with PIX as VPN server


by default all traffic is denied on PIX so you need to create and apply appropriate ACL's to permit traffic. Next what I would try is to ping from PC to PC not directly from PIX to PC. Or you can use extended ping and specify source interface. Or you can try packet-tracer.

Also please check logs regarding your ping if you see some bulit outbound connection...


CreatePlease to create content