cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4450
Views
0
Helpful
9
Replies

VPN Client to PIX - no received bytes on client

chris.lantz
Level 1
Level 1

I have a PIX with 6.3(4) and the VPN Client 5.0.06.0110.  I can establish a tunnel, but can't pass traffic beyond the PIX to the network from the client.  I can ping the inside of the PIX, so I believe that the tunnel is fine, but maybe the ACL's are wrong?  Once the tunnel is established, under Statistics/Tunnel Details the Bytes Sent goes up, but the Bytes Received stays at 0.

If anybody would like to chime in, I'd appreciate it.

pixfirewall# sh conf
: Saved
: Written by enable_15 at 14:45:50.611 UTC Tue Dec 15 2009
PIX Version 6.3(4)
interface ethernet0 auto
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password xxxxx encrypted
passwd xxxxx encrypted
hostname pixfirewall
domain-name xxx.com
fixup protocol dns maximum-length 4096
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
fixup protocol tftp 69
names
access-list 101 permit ip 192.168.27.0 255.255.255.0 10.10.10.0 255.255.255.0
access-list 102 permit ip 192.168.27.0 255.255.255.0 10.10.10.0 255.255.255.0
pager lines 24
icmp permit any outside
icmp permit any inside
mtu outside 1500
mtu inside 1500
ip address outside 209.xxx.xxx.248 255.255.255.255
ip address inside 192.168.27.2 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
ip local pool ippool 10.10.10.1-10.10.10.254
pdm logging informational 100
pdm history enable
arp timeout 14400
nat (inside) 0 access-list 102
route outside 0.0.0.0 0.0.0.0 209.xxx.xxx.1 1
timeout xlate 0:05: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 TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server RADIUS protocol radius
aaa-server RADIUS max-failed-attempts 3
aaa-server RADIUS deadtime 10
aaa-server LOCAL protocol local
http server enable
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 gvnset esp-des esp-md5-hmac
crypto dynamic-map dynmap 10 set transform-set gvnset
crypto map gvnmap 10 ipsec-isakmp dynamic dynmap
crypto map gvnmap interface outside
isakmp enable outside
isakmp key ******** address xxx.xxx.142.105 netmask 255.255.255.255
isakmp identity address
isakmp nat-traversal 20
isakmp policy 9 authentication pre-share
isakmp policy 9 encryption des
isakmp policy 9 hash md5
isakmp policy 9 group 2
isakmp policy 9 lifetime 28800
vpngroup gvnclient address-pool ippool
vpngroup gvnclient dns-server 192.168.27.1
vpngroup gvnclient wins-server 192.168.27.1
vpngroup gvnclient default-domain xxx.com
vpngroup gvnclient split-tunnel 101
vpngroup gvnclient idle-time 1800
vpngroup gvnclient password ********
telnet 192.168.27.0 255.255.255.0 inside
telnet timeout 15
ssh timeout 60
management-access inside
console timeout 0
terminal width 80
Cryptochecksum:xxx
pixfirewall#

1 Accepted Solution

Accepted Solutions

busterswt
Level 1
Level 1

Servers on the 192.168.27.0 network likely need a route that points the 10.10.10.0/24 network back to the PIX. It's possible your client VPN traffic is making it out but the other end doesn't know how to get back.

View solution in original post

9 Replies 9

busterswt
Level 1
Level 1

Servers on the 192.168.27.0 network likely need a route that points the 10.10.10.0/24 network back to the PIX. It's possible your client VPN traffic is making it out but the other end doesn't know how to get back.

James, you were absolutely right.  I am such a bonehead...that's a Networking 101 thing.  Anyway, adding a route to the gateway made everything work.  Thanks for the prompt answer.

P.S. I have a Linksys BEFSX41 that I'd like to configure for that VPN, so that I could have a permanent tunnel going...feeling brave?

I can certainly help with the PIX side of the config, but don't have any experience with the Linksys side. If you can get the Linksys configured we can likely configure the PIX with no prob.

James

Well now that's interesting...Cisco filtered out my self-description of the word bone and the word head put together.  Just trying to keep it real.  Oh well.

As for the Linksys, if you're willing, then let's do it.  My first question is: can I keep the settings for the software clients that I just got working (ie, aes, sha) and have separate ones for the Linksys connection.  From what I see in the Linksys config screen, my options are DES or 3DES and MD5 or SHA.  Key management is either Auto IKE or Manual (in which you have to enter one for encryption and one for authentication).  I also need to fill in a Tunnel Name, local secure group (subnet), remote secure group, remote security gateway,  main or aggressive mode, optional username, proposal 1 encryption and auth. type, group bit strength, key lifetime.  How's that for starters?

Hi Chris,

You can use your existing isakmp policy and transform-set that are currently configured on the PIX. They are both set for des/md5.

Existing stuff:

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

isakmp identity address

isakmp nat-traversal 20

isakmp policy 9 authentication pre-share

isakmp policy 9 encryption des

isakmp policy 9 hash md5

isakmp policy 9 group 2

isakmp policy 9 lifetime 28800

New Stuff (Add to the PIX):

ACL 102 is your NAT exemption list. 192.168.27.0/24 is the network local to the PIX, and x.x.x.x is the network behind the Linksys. y.y.y.y would be that netmask.

ACL L2L is known as the 'encryption domain'. This is interesting traffic that will pass over the tunnel. On the Linksys, x.x.x.x will be the 'local secure group' and 192.168.27.0 will be the 'remote' group.

--------

access-list 102 permit ip 192.168.27.0 255.255.255.0 x.x.x.x y.y.y.y

access-list L2L permit ip 192.168.27.0 255.255.255.0 x.x.x.x y.y.y.y

--------

The sysopt statement below will allow VPN traffic to bypass the access-list on the outside interface:

-------

sysopt connection permit-ipsec

-------

You have an existing crypto map enabled on the outside interface, and will need to add the following to it:

z.z.z.z is the outside IP of the Linksys device. On the Linksys, the remote security gateway is the outside IP of the PIX, or 209.xxx.xxx.248.

------

crypto map gvnmap 200 set transform-set gvnset

crypto map gvnmap 200 ipsec-isakmp

crypto map gvnmap 200 match address L2L

crypto map gvnmap 200 set peer z.z.z.z

------

The preshared key below is 123456789, but it can be whatever you like as long has both ends have the same thing.

------

isakmp key 123456789 address z.z.z.z netmask 255.255.255.255 no-xauth no-config-mode

------

On the Linksys, for simplicity sake, make both Phase 1 and Phase 2 use des, md5, and DH group 2 (1024-bit strength). You'll likely want to use Main Mode as well. PFS has not been enabled on the PIX, so look out for it and disable it on the Linksys.

This should get you started, and hopefully I haven't left anything out. If you have any questions, don't hesitate to ask!

James

OK, did everything, but when I hit the connect button on the Linksys, it goes into a reset-loop, where it resets itself, like it was just powered on.  Then after it's been up for a few seconds, resets again.  I have to unplug the WAN ethernet so that I can login to the Linksys and disable the VPN.

Is there logging that I can enable on the PIX to see what is happening?

Actually, it seems that we can get used 501's in the $50-75 range, so we've decided to get some more, rather than spend our time on a one-off solution with this Linksys.  So I'm not going to worry about it. 

Thanks for your input to date, and I hope you are feeling as generous when the time comes for me to setup the other PIXes!

I thought I'd resurrect this thread, since I mentioned that we were going to get a bunch of used 501's and try to hook them all together.  Well, they bought 7 of them and sent me one to figure out.  I still have the Cisco VPN Clients connecting to PIX #1, and I have now established a VPN from PIX #2 to the first one, but I can't pass any traffic.  I've attached the configs from both PIXes, and you can see what can be pinged and what can't.  Any ideas would be appreciated.  Eventually, PIX #1 needs to accept the VPN from PIX #2 as a dynamic address, but for now I've hardcoded an address in.

Hi cris
I could tell how to apply the gateway to your problem, if you could upload your solution. I have a very similar problem.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: