cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
301
Views
0
Helpful
5
Replies

Odd problem with PIX to Cisco VPN Client..

jhaggett
Level 1
Level 1

I've used a similar config to this on a few other configs and everything worked great. My problem now is, the connection is made, and my machine is sending data, but, nothing is being recieved. I'm also noticing a lot of bypassed packets. Any have any idea why?

PIX Version 6.3(1)

interface ethernet0 auto

interface ethernet1 auto

nameif ethernet0 outside security0

nameif ethernet1 inside security100

enable password xxxxx

passwd xxxx

hostname pixfw

domain-name corp.ca

fixup protocol ftp 21

fixup protocol h323 h225 1720

fixup protocol h323 ras 1718-1719

fixup protocol http 80

fixup protocol ils 389

fixup protocol rsh 514

fixup protocol rtsp 554

fixup protocol sip 5060

fixup protocol sip udp 5060

fixup protocol skinny 2000

fixup protocol smtp 25

fixup protocol sqlnet 1521

names

access-list test permit tcp any host 207.229.x.x eq smtp

access-list test permit tcp any host 207.229.x.x eq www

access-list test permit tcp any host 207.229.x.x eq 3306

access-list nonat permit ip 192.168.100.0 255.255.255.0 192.168.200.0 255.255.25

5.0

access-list 151 permit ip 192.168.100.0 255.255.255.0 192.168.200.0 255.255.255.

0

pager lines 24

mtu outside 1500

mtu inside 1500

ip address outside 207.229.x.x 255.255.255.224

ip address inside 192.168.100.86 255.255.255.0

ip audit info action alarm

ip audit attack action alarm

ip local pool VPNPOOL 192.168.200.1-192.168.200.20

pdm history enable

arp timeout 14400

global (outside) 1 interface

nat (inside) 0 access-list nonat

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

static (inside,outside) tcp 207.229.x.x www 192.168.100.138 www netmask 255.2

55.255.255 0 0

access-group test in interface outside

route outside 0.0.0.0 0.0.0.0 207.229.x.x 1

timeout xlate 3:00:00

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

timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00

timeout uauth 0:05:00 absolute

aaa-server TACACS+ protocol tacacs+

aaa-server RADIUS protocol radius

aaa-server LOCAL protocol local

no snmp-server location

no snmp-server contact

snmp-server community public

no snmp-server enable traps

floodguard enable

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 mymap 10 ipsec-isakmp dynamic dynmap

crypto map mymap interface outside

isakmp enable outside

isakmp key ******** address 0.0.0.0 netmask 0.0.0.0

isakmp identity address

isakmp client configuration address-pool local VPNPOOL outside

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 XXX address-pool VPNPOOL

vpngroup XXX dns-server 192.168.100.14

vpngroup XXX wins-server 192.168.100.14

vpngroup XXX idle-time 7200

vpngroup XXX password ********

vpngroup dns idle-time 1800

telnet timeout 5

ssh 192.168.100.87 255.255.255.255 inside

ssh 192.168.100.0 255.255.255.0 inside

ssh timeout 60

console timeout 0

terminal width 80

Cryptochecksum:xxxxx

: end

5 Replies 5

patrick.cannon
Level 1
Level 1

Reset your security association, but don't wipe it out!!! Just force it to renegotiate the tunnel again and you should be fine.

I've done that with no luck :(

Not applicable

What I do not see is a route statement for your VPN IP pool to your PIX's default gateway. You should have a statement that looks something like:

route outside 192.168.200.0 255.255.255.0 207.229.x.x 1

Also, make sure any routers on the Internal network know to route these IPs to the PIX.

If that is not the issue, what kind of device is your VPN client behind? If you do not configure a Linksys DSL/Cable FW/Router for IPSEC Passthrough, then the tunnel will be made, the packets will be sent to the PIX, but when the PIX sends the packets back, the Linksys will drop them.

Hope this helps.

Shouldn't the statement:

route outside 0.0.0.0 0.0.0.0 207.227.x.x 1 cover that though?

Not applicable

Assuming that your PIX does not pick up any dynamic routes using RIP or OSPF then yes, that would suffice. I would consider adding that route statement anyway, just to hard code this on to the PIX. Kind of like puting a deny any any statement at the end of an ACL. It is there by default, but is good practice to put that line in anyway.

Just my .02 on how I do it with my company.