Connectivity problem with PIX as VPN server

Artem Mitskiy · ‎08-09-2013

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

names

!

interface Ethernet0

nameif outside

security-level 0

ip address xxx.xxx.xxx.xxx 255.255.255.128

!

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 172.30.1.253 255.255.0.0

!

interface Ethernet1.4

description internal side of office network

vlan 4

nameif office-lan

security-level 100

ip address 192.168.1.253 255.255.254.0

!

interface Ethernet1.104

vlan 104

nameif office-dmz

security-level 50

ip address 192.168.104.253 255.255.255.0

!

interface Ethernet2

shutdown

no nameif

no security-level

no ip address

!

interface Ethernet3

shutdown

no nameif

no security-level

no ip address

!

interface Ethernet4

shutdown

no nameif

no security-level

no ip address

!

interface Ethernet5

shutdown

no nameif

no security-level

no ip address

!

ftp mode passive

access-list 101 extended permit ip any 192.168.0.0 255.255.254.0

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

access-list split-office-dmz standard permit 192.168.104.0 255.255.255.0

pager lines 24

mtu outside 1500

mtu management 1500

mtu office-lan 1500

mtu office-dmz 1500

ip local pool pool-office-dmz 192.168.104.100-192.168.104.200 mask 255.255.255.0

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 0.0.0.0 0.0.0.0 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 192.168.0.0 255.255.254.0 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

parameters

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 192.168.104.100 255.255.255.255 [1/0] via yyy.yyy.yyy.yyy, outside (yyy - is default gteway)

When in my opinion it should be like 192.168.104.100 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?

Jan Rolny · ‎08-09-2013

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 192.168.104.100-192.168.104.200. See line

ip local pool pool-office-dmz 192.168.104.100-192.168.104.200 mask 255.255.255.0

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

Best Regards,

Jan

Artem Mitskiy · ‎08-09-2013

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.

Jan Rolny · ‎08-09-2013

Hi,

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...

Jan