Cisco EZVPN client LAN access

P

Protoform-X

[H]ard|Gawd
Joined
Jan 30, 2002
Messages
1,203
I have a UC500 series phone system that I installed for a client. The client is requesting that their remote users who use the Cisco VPN client to connect to the UC500's EZVPN server be able to access local network resources. That sounds simple enough, but I really don't know anything about Cisco VPN configuration, so I was hoping someone could give me a break down of what to do. Here's a break down of some of my config. I can provide more as needed:

*Phones work over the VPN and split-tunneling is enabled* - Initially that's all the access they needed.

Data VLAN: 10.105.0.x
Voice VLAN: 10.1.1.x
Unity Express: 10.1.10.1

show run | section crypto:
Code: 
UC540#sh run | sec crypto
<SNIP>
ip local pool SDM_POOL_1 172.20.20.1 172.20.20.50
crypto isakmp policy 1
 encr 3des
 authentication pre-share
 group 2
crypto isakmp client configuration group EZVPN_GROUP_1
 key (REMOVED)
 dns 10.105.0.10
 pool SDM_POOL_1
 acl 100
 save-password
 max-users 10
crypto isakmp profile sdm-ike-profile-1
   match identity group EZVPN_GROUP_1
   client authentication list Foxtrot_sdm_easyvpn_xauth_ml_1
   isakmp authorization list Foxtrot_sdm_easyvpn_group_ml_1
   client configuration address respond
   virtual-template 9
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto ipsec profile SDM_Profile1
 set transform-set ESP-3DES-SHA

ACL 100:
Code: 
UC540#sh run | sec access-list 100
access-list 100 remark SDM_ACL Category=4
access-list 100 permit ip 10.105.0.0 0.0.0.255 any
access-list 100 permit ip 10.1.10.0 0.0.0.255 any
access-list 100 permit ip 10.1.1.0 0.0.0.255 any

NAT:
Code: 
ip nat inside source list 1 interface FastEthernet0/0 overload

ACL 1:
Code: 
access-list 1 remark SDM_ACL Category=2
access-list 1 permit 10.105.0.0 0.0.0.255
access-list 1 permit 10.1.1.0 0.0.0.255
access-list 1 permit 10.1.10.0 0.0.0.3

NAT problem? Route problem? I'm not sure, any help is appreciated. Please let me know if more config info is needed and I will provide it.
 
I haven't played with EZVPN much since I do a lot more site-to-site ipsec VPNs but based on the config excerpt above I don't see any glaring errors. Since you are specifying a server on the data vlan as the DNS server under the client config have you verified they can resolve DNS names using this server when they are tunneled in?

Check the routing table on the client side to see if the proper routes are interjected so the client knows which side of the "split tunnel" to use.

Which "local network resources" are they unable to reach?

My only other thought is the NAT overload is NATing the internal host addresses before they are tunneled... But if connectivity is working on the voice vlans already I don't think that's the problem...
 
I guess my explanation of the problem is a little lacking. To answer your question about DNS, it does not work at all. I can't hit that IP from the VPN. I can only ping/connect to IP addresses that are on the UC540. So I can get to 10.1.10.1 and I can get to 10.105.0.254(data VLAN IP for the UC). If I run a trace from my VPN to, say, 10.105.0.10, I see the traffic hit the UC and then drop.

I want the VPN traffic to be able to access anything on the 10.105.0.x subnet. Getting DNS from that 10.105.0.10 address would be a great bonus.
 
Then if I remember my NAT order of operations properly your return traffic is being NAT'd before the crypto map is being applied. You might need something like this:

Code: 
ip nat inside source route-map nonat int fa0/0 overload

access-list 199 deny   ip 10.105.0.0 0.0.0.255 172.20.20.0 0.0.0.255
access-list 199 deny   ip 10.1.10.0 0.0.0.255 172.20.20.0 0.0.0.255
access-list 199 deny   ip 10.1.1.0 0.0.0.255 172.20.20.0 0.0.0.255
access-list 199 permit ip any any

route-map nonat permit 10
 match ip address 199

I use something like this at work on a router with an IPSEC tunnel which we don't NAT through and two separate Internet connections to different providers that have distinct paths, i.e. one through a private SONET ring via Ethernet and the other through a normal T1...
 
So I would create that NAT statement in addition to the current NAT statement? This wouldn't effect any of the current traffic flow, right?
 
You'd have to remove the existing NAT overload statement. You could put in the new one first, then remove the old one... but it will still interrupt the flow for a brief moment.

If I was implementing it, we would have to do it after hours or in a change window.
 
I went ahead and did that. Luckily its not a mission-critical network and I can make fast changes like this on-the-fly. Unfortunately still a no-go. Any additional ideas? :(
 
Hmmm... Are the client computers getting a route to all the 10.x.x.x networks when they connect via the VPN?

Add an ip any any to the top of ACL 100 for fun...

I'm not used to these "EZ" configs lol.
 
The client has routes pointed to 10.105.0.0/24, 10.1.1.0/24, and 10.1.10.1/32. The packets do make it to the UC540, but then they drop.

Wouldn't adding the ip any any to the top of ACL 100 kill my split tunneling? I'm not sure, just checking before I go for it.
 
The router shouldn't drop the packets unless it didn't have a route to the network or something else in the config not shown here is causing it.

What does the routing table look like on the router? Routers don't randomly drop packets.
 
I'll get you the routing table tomorrow when I'm at the office. I'm not sure if you're familiar with these SMB class UC500 series phone systems, but they don't support any routing protocols. I have a feeling that may be something to do with this mess.
 
Well, I used one of my spare routers and created an EZVPN split tunnel config that was very close to what was listed above. Starting with a blank router and the EZVPN server wizard via SDM the config seemed to work fine.

I was able to create a loopback address on my spare router that was not normally reachable via my home network since I was not advertising the route in my EIGRP AS. I then used the Cisco VPN client to tunnel to the spare router and the loopback network (which I was making available via ACL 100) became reachable. To simulate the WAN portion of the connectivity for the VPN I used a 2 Mbit point-to-point frame relay link.

Based on all of this I'm going to assume there is nothing wrong with the UC500. I've never used one of those (I know very little about VoIP actually) but routing and VPNs are pretty universal.
 
Here's the relevant config sections on the EZVPN head-end router if anyone is interested... Clearly I don't have enough to do at work today...
Code: 
aaa new-model
!
!
aaa authentication login default local
aaa authentication login sdm_vpn_xauth_ml_1 local
aaa authorization exec default local
aaa authorization network sdm_vpn_group_ml_1 local
!
crypto isakmp policy 1
 encr 3des
 authentication pre-share
 group 2
crypto isakmp xauth timeout 15

!
crypto isakmp client configuration group GROUP1
 key cisco
 dns 68.87.85.102 68.87.69.150
 pool SDM_POOL_1
 acl 100
!
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
!
crypto dynamic-map SDM_DYNMAP_1 1
 set transform-set ESP-3DES-SHA
 reverse-route
!
!
crypto map SDM_CMAP_1 client authentication list sdm_vpn_xauth_ml_1
crypto map SDM_CMAP_1 isakmp authorization list sdm_vpn_group_ml_1
crypto map SDM_CMAP_1 client configuration address respond
crypto map SDM_CMAP_1 65535 ipsec-isakmp dynamic SDM_DYNMAP_1
!
interface Loopback1
 ip address 10.99.99.99 255.255.255.255
!
interface Serial1/0
 description $FW_INSIDE$
 bandwidth 2048
 ip address 172.30.0.2 255.255.255.252
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 encapsulation frame-relay
 ip route-cache flow
 frame-relay interface-dlci 201
 crypto map SDM_CMAP_1
!
ip local pool SDM_POOL_1 172.29.0.10 172.29.0.20
!
access-list 100 remark SDM_ACL Category=4
access-list 100 permit ip host 10.99.99.99 any
 
Hmm, doesn't sound much different than what I can reach. I can reach the IP's on the router which are in the permitted subnets under ACL 100. I can't reach the IP's in those subnets on the rest of the network.

Code: 
Gateway of last resort is <SNIP> to network 0.0.0.0

     64.0.0.0/29 is subnetted, 1 subnets
C       <SNIP> is directly connected, FastEthernet0/0
     172.20.0.0/32 is subnetted, 2 subnets
S       172.20.20.16 [1/0] via 0.0.0.0, Virtual-Access3
S       172.20.20.17 [1/0] via <SNIP>, Virtual-Access2
     10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
S       10.1.10.1/32 is directly connected, Integrated-Service-Engine0/0
C       10.1.10.0/30 is directly connected, Loopback0
C       10.1.1.0/24 is directly connected, BVI100
C       10.105.0.0/24 is directly connected, BVI1
S*   0.0.0.0/0 [1/0] via <SNIP>
 
Nope, think that's it! I tried this on a different, but similar, network that I actually have access to the gateway firewall: Added a route from 172.20.20.0/24 to the UC's IP. Did the trick! I've requested that the client add the route to their gateway. Time will tell. :)
 
You must log in or register to reply here.
Back
Top