Re: Cannot get traffic accross PIX VPN

mjhagen · ‎03-08-2002

I have setup IPSec on a PIX 515 running 6.1(2) exacly as the documentation states. I can connect to the PIX using VPN Client 3.1 but I am not able to connect to or ping anything on the inside network. Below is my PIX config:

access-list 101 permit ip 171.16.1.0 255.255.255.0 172.16.2.0 255.255.255.0

ip address outside x.x.x.x 255.255.255.128

ip address inside 172.16.1.254 255.255.255.0

ip local pool vpnclients 172.16.2.100-172.16.2.150

global (outside) 1 x.x.x.x

nat (inside) 0 access-list 101

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

nat (dmz) 1 0.0.0.0 0.0.0.0 0 0

sysopt connection permit-ipsec

no sysopt route dnat

crypto ipsec transform-set myset esp-des 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 client configuration address-pool local vpnclients outside

isakmp policy 10 authentication pre-share

isakmp policy 10 encryption des

isakmp policy 10 hash md5

isakmp policy 10 group 2

isakmp policy 10 lifetime 86400

vpngroup vpn3000 address-pool vpnclients

vpngroup vpn3000 split-tunnel 101

vpngroup vpn3000 idle-time 1800

vpngroup vpn3000 password ********

srittenberg · ‎03-08-2002

you can't access the network via inside interface or just can't ping? is it icmp needs to be specifically permitted? because you were trying to ping from an outside interface to host behide an inside interface which is not allowed by PIX (if this is a PIX) without permitting icmp.

mjhagen · ‎03-11-2002

Both, I cannot ping or connect to anything. I have enabled ICMP any any just for testing.

pdentico · ‎03-12-2002

The config looks right. Could it be a routing issue behind the firewall?? For the machines that you are trying to ping behind the firewall are they pointed to the firewall for their default route?? If not is there a route to the pooled subnet??

Just a thought,

Good luck!!

mjhagen · ‎03-12-2002

I have set static routes on my internal router to route all traffic for the 172.16.x.x to my internal address of the firewall.

pdentico · ‎03-12-2002

Could you elaborate a little on your internal setup. I am missing the big picture. If you have an internal router and it has a static route to the 172.16.0.0 to the firewall, what is the ip address of what you're trying to ping?

If it is something other than 172.16.1.x than you have to add it to the acl.

mjhagen · ‎03-12-2002

I have a production network up and running with another PIX. The default route for our internal network is that PIX. I am testing another PIX using IPSec so I setup another subnet on our internal network so I would not impact the production Lan. I have the test PIX, secondary IP of internal router and MY internal PC all using 172.16.1.x. All this works and I can see other devices from my internal PC 172.16.1.x to my production Lan. When I use another machine with VPN client outside our network I can connect to the PIX but that is it.

srittenberg · ‎03-12-2002

I just looked over your config again, there is no crypto map xxxx match address access_list_ID statement, so the crypto map doesn't have the access-list to be included to teh ipsec. Have you look at this? by the way, I haven't worked with 3000 concentrator, so I'm not sure by including the vpngroup pool is the same as the crypto map statement, I assume not.

sstaker · ‎03-12-2002

You do not need a match address for a client, only with a lan to lan.... However..... you are using access-list 101 as a split-tunnel list. ONLY traffic in access-list 101 of your config will be considered "interesting" and go through the vpn tunnel. You need to add all of the networks behind the pix that you want to be able to communicate with to this access-list instead of just the one network you have now. With your current config you will only be able to communicate with the single network that the pix's inside interface is on. Let me know if this doesn't make snese.

sampathsr · ‎03-13-2002

Try this:

To one of the machines on the inside network (in the IP subnet of 172.16.1.x), add one more address from the subnet 172.16.2.x...

see whether u r able to telnet or ftp into this machine (enable one of these services in this test machine..

Best Regards

Sampath

SampathSR@yahoo.com

New York, NY.

mjhagen · ‎03-13-2002

It did make sense in what IU had setup as only allowing communication to the single subnet. I was able to get it working this morning. I had to do 2 things. First and probably the biggest issue was I had to create a static route on my internal router for the subnet that the IP pool was defined to. I then changed my access list to allow any any just to eliminate an access list issue. I then backed up to my original access list and still did not work. I then re-booted the firewall and everything started working.

chlovell · ‎03-18-2002

I take it that the tunnel establishes but you cannot pass traffic?

1. Bring up the tunnel

2. Do a show crypto ipsec sa and not the encrypts and decrypts

3. Initiate a ping to an internal device that has its default gateway pointed at pix

4. Do another show crypto ipsec sa and not which counters have incremented.

asafayan · ‎03-13-2002

I have the exact same issue. Have you found a resolution? I used the CCO article: http://www.cisco.com/warp/customer/110/pix3000.html

I am familiar with the Concentrator series. When you configure remote access with a concentrator platform, you must tell the client how it will authenticate. By this I don't mean the IKE Phase 1 authentication which is configured via the CLI statement: isakmp policy 10 authentication pre-share. I mean an actual end-user login/password authentication. With the concentrators, you tell the remote access client to authenticate via local database on the concentrator OR via NT domain OR via RADIUS server. I don't see any PIX CLI statements which dictate this functionality.

When my client connects to the PIX, it dialog box rather quickly disappears and I see the "lock" icon in my task bar. When you look at the client parameters via this "lock" utility, I see the client has properly been assigned the first address in my configured pool. What I don't see are any encrypted packets coming "in" to the client.

The resources I am trying to access are in a WORKGROUP on the INSIDE interface of the PIX. Regardless of whether or not my VPN client has NetBIOS name resolution, the fact is that the client doesn't even have PING reachability with the network resources on the INSIDE interface of the PIX.

I will follow up with you if I get resolution to this.

Regards,

Amir Safayan

Security Practice Manager

www.msdinc.com

asafayan@msdinc.com

mjhagen · ‎03-13-2002

I was able to get it working this morning. I had to do 2 things. First and probably the biggest issue was I had to create a static route on my internal router for the subnet that the IP pool was defined to. I then changed my access list to allow any any just to eliminate an access list issue. I then backed up to my original access list and still did not work. I then re-booted the firewall and everything started working.

asafayan · ‎03-14-2002

My LAN segment hosts default to my INSIDE interface of my PIX so packets go to that interface and the PIX routes them to the POOL. If your inside router where defaulting to the PIX INSIDE interface, then the PIX should pass them to the POOL subnet. In other words, your router should default them to your PIX without the static route you put in.

What access-list are you referring to? The access-list that says "don't NAT packets from the INSIDE subnet going to the VPNGROUP pool". That was my problem...I hadn't created this access-list with the NAT 0 (inside) access-list statement. So the PIX was seeing those packets and NATing them and that was breaking IPSec. I put that access-list and NAT statement in and it worked fine. I used an LMHOSTS file on my remote client and was able to map drives through the tunnel with no problems.