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

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

VPN Config Help

OK, this is probably a really simple screwup. I'm new to the PIX (a 515e in this case), and it's much different than the 2611 I'm used to configuring. All I want to do is setup for a VPN Client v4. I can connect, but cannot pass traffic through the tunnel. After connection, the client can ping the PIX through the tunnel, and the PIX can ping the client through the virtual address assigned. But the client cannot access anything on the trusted network. Here's what I have:

ip local pool vpnclients x.x.17.1-x.x.17.254

access-list INSIDE permit ip x.x.55.0 255.255.255.0 any

access-list INSIDE permit icmp x.x.55.0 255.255.255.0 any

access-list OUTSIDE permit ip any x.x.55.0 255.255.255.0

access-list OUTSIDE permit ip any host x.x.193.226

access-list OUTSIDE permit icmp any x.x.55.0 255.255.255.0

access-list OUTSIDE permit icmp any host x.x.193.226

access-list VPN-NAT permit ip any x.x.17.0 255.255.255.0

ip address WAN x.x.193.226 255.255.255.248

ip address WIN-LAN x.x.55.1 255.255.255.0

nat (inside) 0 access-list VPN-NAT

nat (inside) 0 x.x.55.0 255.255.255.0 0 0

access-group OUTSIDE in interface outside

access-group INSIDE in interface inside

sysopt connection permit-ipsec

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

crypto dynamic-map DYNMAP 20 set transform-set ENCRYPT

crypto map WANMAP 65535 ipsec-isakmp dynamic DYNMAP

crypto map WANMAP client authentication RADIUS

crypto map WANMAP interface outside

isakmp enable outside

isakmp policy 20 authentication pre-share

isakmp policy 20 encryption des

isakmp policy 20 hash md5

isakmp policy 20 group 2

isakmp policy 20 lifetime 86400

vpngroup vpngroup address-pool vpnclients

vpngroup vpngroup dns-server [ip of nameserver]

vpngroup vpngroup wins-server [ip of wins server]

vpngroup vpngroup default-domain mydomain.com

vpngroup vpngroup idle-time 1800

vpngroup vpngroup password ********

I have a full class C on my trusted network, so no NAT. And yes, I know I'm wide open, but first things first. I'll tighten up the ACLs after I get the VPN running. And this is a secondary firewall anyway, so I'm not completely vulnerable.

Many thanks...

Paul

5 REPLIES
Cisco Employee

Re: VPN Config Help

Hmmm, actually this config looks pretty good, can't see anything obviously wrong with it. You mention that this is a secondary firewall, so does this connection go through your primary firewall, you may want to make sure it's allowing everything through. Is your VPN client behind any sort of PAT device? If so, try adding "isakmp nat-traversal" to your configuration. Also, do the internal hosts have this PIX set as their default gateway, or at least do they have a route to the x.x.17.0 subnet that points to the PIX inside interface?

New Member

Re: VPN Config Help

Right now I'm still in testing mode; the test client is connected via a hub directly to the PIX's WAN interface. So the upstream firewall is not in this equation. And the internal hosts do have their default gateway pointing to the PIX interface. What's baffling to me is that if I tracert from the client, I can see that it going through the IPsec tunnel. I just can't get past it.

Cisco Employee

Re: VPN Config Help

So is the default gateway on your test PC set to the PIX's outside interface?

New Member

Re: VPN Config Help

Yes, currently. My original test setup had another upstream router with the default gateway on the test client then set up for it, but when that test failed I removed it and put the test client directly on the PIX's WAN interface.

New Member

Re: VPN Config Help

New info on problem...

I discovered the capture command with some very interesting results. Machine A is in the protected LAN, machine B in the VPN client. I setup a capture on the WAN port to capture all traffic to/from machine B. My first test was a ping from A to B. Without the tunnel to test the capture I get:

8 packets captured

13:37:15.961070 x.x.55.37 > x.1x.193.235: icmp: echo request

13:37:15.962016 x.x.193.235 > x.x.55.37: icmp: echo reply

13:37:16.961315 x.x.55.37 > x.x.193.235: icmp: echo request

13:37:16.962245 x.x.193.235 > x.x.55.37: icmp: echo reply

13:37:17.962505 x.x.55.37 > x.x.193.235: icmp: echo request

13:37:17.963420 x.x.193.235 > x.x.55.37: icmp: echo reply

13:37:18.962734 x.x.55.37 > x.x.193.235: icmp: echo request

13:37:18.963649 x.x.193.235 > x.x.55.37: icmp: echo reply

8 packets shown

Results are as expected.

Now with the tunnel established, the same test ping from A to B:

11 packets captured

13:43:46.663539 x.x.55.37 > x.x.193.235: icmp: echo request

13:43:51.454703 x.x.193.235 > x.x.193.226: ip-proto-50, length 132

13:43:51.864594 x.x.55.37 > x.x.193.235: icmp: echo request

13:43:52.790608 x.x.193.235.500 > x.x.193.226.500: udp 84

13:43:52.790928 x.x.193.226.500 > x.x.193.235.500: udp 84

13:43:52.956829 x.x.193.235 > x.x.193.226: ip-proto-50, length 132

13:43:54.459158 x.x.193.235 > x.x.193.226: ip-proto-50, length 132

13:43:56.870575 x.x.55.37 > x.x.193.235: icmp: echo request

13:44:01.876556 x.x.55.37 > x.x.193.235: icmp: echo request

13:44:02.805546 x.x.193.235.500 > x.x.193.226.500: udp 84

13:44:02.805897 x.x.193.226.500 > x.x.193.235.500: udp 84

11 packets shown

FYI...x.x.193.226 is the PIX WAN port.

Several interesting things here.

1) PIX is placing the ping echo request on the wire unexcrypted. Why isn't the traffic using the established tunnel?

2) I see no correlated evidence of a reply from the VPN client, either encrypted of not.

3) The client is setup for UDP transparent tunneling. So why the protocol 50 traffic? I thought that was the point of transparent tunneling, to get past the ISPs like earthlink who block protocol 50 traffic.

So next I run the same capture while pinging from the VPN client (B) to the inside network host (A).

8 packets captured

13:52:28.165656 x.x.193.235 > x.x.193.226: ip-proto-50, length 92

13:52:33.393397 x.x.193.235 > x.x.193.226: ip-proto-50, length 92

13:52:35.569398 x.x.193.235.500 > x.x.193.226.500: udp 84

13:52:35.569703 x.x.193.226.500 > x.x.193.235.500: udp 84

13:52:38.400858 x.x.193.235 > x.x.193.226: ip-proto-50, length 92

13:52:43.408304 x.x.193.235 > x.x.193.226: ip-proto-50, length 92

13:52:45.584472 x.x.193.235.500 > x.x.193.226.500: udp 84

13:52:45.584762 x.x.193.226.500 > x.x.193.235.500: udp 84

8 packets shown

The "length 92" packets appear to correspond with the echo request. There is no evidence of a reply, either encrypted or not.

Anyone have a clue what;s going on here? For such a basic setup, I can't believe it's so hard to get it working.

134
Views
0
Helpful
5
Replies