EZVPN routing issue between UC520 & SR520

Unanswered Question
Dec 8th, 2009

Hi,

I used CCA 2.1 to initially configure EZVPN connection between remote site SR520 and Main site UC520. (Now using CCA 2.2.)

However, main site cannot access remote site subnets.

Users at the remote site can access the main site data network with no issues.

For example,

  1. a PC at the remote teleworker location can access all main site subnets;

  2. spa525 phone at the remote teleworker location even registers and is able to make calls via the UC520

So I am happy with this functionality.

My issue

A PC at main site, cannot ping the remote teleworker site PC, or other devices on remote subnet.

Using CCA I created a virtual pool for the remote teleworker EZVPN SR520 router clients.

Here is a partial copy of UC520 route table to indicate their virtual addresses:

S       192.168.61.4 [1/0] via 0.0.0.0, Virtual-Access2
S       192.168.61.7 [1/0] via 0.0.0.0, Virtual-Access3
S       192.168.61.2 [1/0] via 0.0.0.0, Virtual-Access5

My UC520 data network vlan has an IP address of 192.168.66.254

My SR520 data network vlan has an IP address of 192.168.77.1

On my UC520 PC on my data network, whenever I try to ping a PC on the remote teleworker network, I get no replies.

So I thought I would try something.

For testing, we added a static route into my  UC520, pointing to the remote teleworker site with next hop of the dynamically assigned VPN IP address from my pool.  Here is the route I added

ip route 192.168.77.0 255.255.255.0 192.168.61.7

This now allowed pings to the remote subnet.  Obviously, this is not a long-term fix since the dynamically assigned VPN address will change if re-negotiated.

question:



Shouldn't the UC520 dynamically learn about the remote teleworker LAN subnets and route automatically?

What is the work around for this issue?

regards

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Steven Smith Tue, 12/08/2009 - 08:58

When doing EZVPN configuration, and doing client mode, the remote subnet will not be routable.  You will have to do network extension mode for the subnet to be routable with EZVPN.  This configuration is done on the UC520.  But, be careful.  If your software clients are using this same EZVPN group, it will no longer work for them.

cndpope Tue, 12/08/2009 - 09:31

Thanks for the response.

I visited this url from another you post you made:

http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a0080809222.shtml

But it wasn't clear to me how I would implement "network extension mode" on my uc520 and sr520.  Is there a better document explaining this?

Also, I assume that if we configure "network extension mode" for the hardware ezvpn clients, we would just have to set up another group for the software ezvpn clients?  Certainly I will have both hardware and software vpn clients.

Thanks again for your time and any additional direction you can provide!

cndpope Wed, 12/09/2009 - 14:22

Also, can you confirm that the network extension mode would be the only way (or the recommended implmentation) for the remote sites to talk with one another?  The remote sites are able to talk to main site, but I guess since the remote subnets don't know about one another - there is no route for the talk path.  (The remote sites can, of course, call the extension and it rings, but no audio once connected).

Thanks in advance.

John Platts Thu, 12/10/2009 - 14:08

You should probably be using Static Virtual Tunnel Interfaces instead of Easy VPN. Static Virtual Tunnel Interfaces cannot be configured in CCA, but they can be configured on the UC520, UC540, UC560, SR520, and all of the Cisco Integrated Services Router models, including the 850 through 890 series, 1800 series, 1900 series, 2800 series, 2900 series, 3800 series, and 3900 series.

VPN capabilities are built in on the UC500 series, SR520-ADSL, SR520-FE, 850 through 890 series ISRs, 1811 ISR, and 1812 ISR. On the 1900, 2900, and 3900 series ISRs, the IOS images contain the VPN capabilities, but you will need to have a security license activated on the router in order to get VPN capabilities. On the SR520-T1 router, you must obtain the SR520-T1 security feature license in order to use this capability. On other ISR models, you will need a license for a feature set that contains VPN capabilities and have an IOS image with VPN capabilities loaded on the ISR.

To configure IPsec Static Virtual Tunnel Interfaces, you will need to have static IP addresses or Dynamic DNS enabled on the routers used for this kind of VPN.

Here is what needs to be done to configure each site-to-site VPN using IPsec Static Virtual Tunnel Interfaces:

  • Configure a crypto keyring for the site-to-site IPsec tunnel
  • Configure one or more crypto isakmp policies
  • Configure a crypto isakmp profile for the site-to-site IPsec tunnel
  • Have at least one tunnel-mode transform set configured for the site-to-site IPsec tunnel
  • Configure a crypto ipsec profile for the site-to-site IPsec tunnel
  • Configure the actual Static Virtual Tunnel Interface for the site-to-site IPsec tunnel. The names of Static Virtual Tunnel Interfaces start with Tunnel, and end with a number. For example, Tunnel0, Tunnel1, Tunnel2, etc. are Static VTI interface names.
  • Add routes to send traffic across the IPsec tunnel

Sample configuration for VPN using an IPsec Static Virtual Tunnel Interface, where the other router has a static IP address:

!
! A crypto keyring must be configured for each IPsec VPN tunnel
! that is configured with a IPsec Static Virtual Tunnel
! Interface.
!
crypto keyring AtoB-Keyring
! You must configure the pre-shared key for this VPN tunnel,
! with the address of the other router specified here.
pre-shared-key address 100.1.1.2 key atobKey1
!
! One or more crypto isakmp policies must be configured if
! IPsec VPN tunnels are used on this router.
!
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
!
! A crypto isakmp profile must be configured for each IPsec VPN
! tunnel that is configured with a IPsec Static Virtual Tunnel
! Interface.
!
crypto isakmp profile AtoB-KeyProfile
keyring AtoB-Keyring
!
! The self-identity fqdn statement must be in the crypto isakmp
! profile if this IPsec VPN tunnel will be configured on the other
! router with the DDNS hostname of this router instead of the static
! IP address of this router.
!
! In this example, this endpoint has a DDNS hostname of
! uc520a.dyndns.org. You need to use the actual DDNS hostname
! of your router in the self-identity fqdn line.
!
! If you are not using dynamic DNS on this router, but using a
! static IP address, you do not need to include a self-identity
! line in your ISAKMP profile.
!
self-identity fqdn uc520a.dyndns.org
!
! A match identity address line must be used, and the IP address
! of the other router must be specified here.
!
match identity address 100.1.1.2 255.255.255.255
!
! At least one crypto ipsec transform-set must be specified if you
! are using VPN tunnels. For IPsec tunnels that are configured with
! a IPsec Static Virtual Tunnel Interface, you must use tunnel mode
! transform sets. Transform sets that do not have mode transport
! configured are tunnel mode transform sets. The ESP-3DES-SHA transform
! set below is a tunnel mode transform set.
!
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
!
!
! You must configure a crypto ipsec profile for each IPsec tunnel
! that is configured with a IPsec Static Virtual Tunnel Interface.
!
crypto ipsec profile AtoB-Tunnel
set transform-set ESP-3DES-SHA
set isakmp-profile AtoB-KeyProfile
!
! A Static Virtual Tunnel Interface is configured below.
!
interface Tunnel0
! An ip unnumbered statement must appear in an IPsec Static Virtual
! Tunnel Interface. It is usually unnumbered to the Data Bridge Virtual
! Interface (BVI), or to the Data VLAN, depending on whether or not
! Bridge Virtual Interfaces are used.
ip unnumbered BVI1
!
! A tunnel source statement must appear in an IPsec Static Virtual
! Tunnel Interface. The tunnel source must be set to your WAN interface.
! In this example, the tunnel source is set to the FastEthernet0/0
! interface.
!
tunnel source FastEthernet0/0
!
! A tunnel destination statement must appear in an IPsec Static Virtual
! Tunnel Interface. The tunnel destination must be set to the IP address
! of the other VPN router.
!
tunnel destination 100.1.1.2
!
! tunnel mode ipsec ipv4 must appear in an IPsec Static Virtual Tunnel
! Interface. This statement tells the router that this tunnel is an
! IPsec tunnel.
!
tunnel mode ipsec ipv4
!
! tunnel protection ipsec profile must be set to the crypto ipsec
! profile that is to be used for this IPsec Static Virtual Tunnel
! Interface.
!
tunnel protection ipsec profile AtoB-Tunnel
!
!
! Static routes must be added to send traffic over the IPsec Static
! Virtual Tunnel Interface.
!
ip route 192.168.11.0 255.255.255.0 Tunnel0

Sample configuration for VPN using an IPsec Static Virtual Tunnel Interface, where the other router has a DDNS hostname:

!
! A crypto keyring must be configured for each IPsec VPN tunnel
! that is configured with a IPsec Static Virtual Tunnel
! Interface.
!
crypto keyring AtoC-Keyring
! You must configure the pre-shared key for this VPN tunnel,
! with the DDNS hostname of the other router specified here.
pre-shared-key hostname uc520a.dyndns.org key atocKey3
!
! One or more crypto isakmp policies must be configured if
! IPsec VPN tunnels are used on this router.
!
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
!
! A crypto isakmp profile must be configured for each IPsec VPN
! tunnel that is configured with a IPsec Static Virtual Tunnel
! Interface.
!
crypto isakmp profile AtoC-KeyProfile
keyring AtoC-Keyring
!
! The self-identity fqdn statement must be in the crypto isakmp
! profile if this IPsec VPN tunnel will be configured on the other
! router with the DDNS hostname of this router instead of the static
! IP address of this router.
!
! In this example, this endpoint has a DDNS hostname of
! sr520c.dyndns.org. You need to use the actual DDNS hostname
! of your router in the self-identity fqdn line.
!
! If you are not using dynamic DNS on this router, but using a
! static IP address, you do not need to include a self-identity
! line in your ISAKMP profile.
!
self-identity fqdn sr520c.dyndns.org
!
! A match identity host line must be used, and the DDNS hostname
! of the other router must be specified here.
!
match identity host uc520a.dyndns.org
!
! At least one crypto ipsec transform-set must be specified if you
! are using VPN tunnels. For IPsec tunnels that are configured with
! a IPsec Static Virtual Tunnel Interface, you must use tunnel mode
! transform sets. Transform sets that do not have mode transport
! configured are tunnel mode transform sets. The ESP-3DES-SHA transform
! set below is a tunnel mode transform set.
!
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
!
!
! You must configure a crypto ipsec profile for each IPsec tunnel
! that is configured with a IPsec Static Virtual Tunnel Interface.
!
crypto ipsec profile AtoC-Tunnel
set transform-set ESP-3DES-SHA
set isakmp-profile AtoC-KeyProfile
!
! A Static Virtual Tunnel Interface is configured below.
!
interface Tunnel0
! An ip unnumbered statement must appear in an IPsec Static Virtual
! Tunnel Interface. It is usually unnumbered to the Data Bridge Virtual
! Interface (BVI), or to the Data VLAN, depending on whether or not
! Bridge Virtual Interfaces are used.
ip unnumbered BVI1
!
! A tunnel source statement must appear in an IPsec Static Virtual
! Tunnel Interface. The tunnel source must be set to your WAN interface.
! In this example, the tunnel source is set to the FastEthernet0/0
! interface.
!
tunnel source FastEthernet0/0
!
! A tunnel destination statement must appear in an IPsec Static Virtual
! Tunnel Interface. The tunnel destination must be set to the DDNS hostname
! of the other VPN router.
!
tunnel destination uc520a.dyndns.org
!
! tunnel mode ipsec ipv4 must appear in an IPsec Static Virtual Tunnel
! Interface. This statement tells the router that this tunnel is an
! IPsec tunnel.
!
tunnel mode ipsec ipv4
!
! tunnel protection ipsec profile must be set to the crypto ipsec
! profile that is to be used for this IPsec Static Virtual Tunnel
! Interface.
!
tunnel protection ipsec profile AtoC-Tunnel
!
!
! Static routes must be added to send traffic over the IPsec Static
! Virtual Tunnel Interface.
!
ip route 192.168.10.0 255.255.255.0 Tunnel0

Be sure to do a wr mem to save your configuration once you have your VPNs configured correctly.

Details about IPsec Virtual Tunnel Interfaces are available at the URL below:

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gtIPSctm.html

John Platts Thu, 12/10/2009 - 14:16

Advantages of using IPsec Static Virtual Tunnel Interfaces over Easy VPN:

  • IPsec Static Virtual Tunnel Interfaces can be configured on UC520, UC540, and UC560 units, but Easy VPN client cannot be configured on UC520, UC540, and UC560 units
  • IPsec Static Virtual Tunnel Interfaces and Easy VPN Server can co-exist on the same router
  • Traffic to be routed over an IPsec Static Virtual Tunnel Interface is determined by ip route statements
  • The inbound ACLs on the WAN interface do not need to have additional entries added to allow traffic coming in on the IPsec Static Virtual Tunnel Interface, even though the inbound ACLs on the WAN interface need to have entries to allow ISAKMP, ESP, and AHP traffic
  • Traffic at the other sites is not forced to travel through the site-to-site VPN tunnel