Backup GRE Tunnel using a Seconadary IP Address

[apietrosan]

  Is it possible to setup a Backup GRE Tunnel using a Seconadary IP Address on the WAN interface.  The router is a

Cisco 871.  Any help would be greatly appreciated. 

Thanks.

[Richard Burts · Accepted solution]

Nicholas

I am not sure that it would work to use a secondary address on the WAN interface for a GRE tunnel. Perhaps if you tell us more about what you are attempting to do we might be able to help find alternatives that would work.

Two tunnels from the same interface (even if one could use a secondary address) to another router would not provide backup - if they would work at all. Two tunnels from the same router interface (and both using the primary address) work quite well if they go to different remote routers, and this is a common way to provide backup for GRE tunnels.

HTH

Rick

[apietrosan]

Would something like this be possible on a Cisco 871 Router usind a secondary ip as the source for the backup tunnel?

[apietrosan]

Wireless Private Network Requirements:

The IPSec tunnel endpoint and GRE tunnel endpoints must both reside on the same physical customer device.

BGP peering relationship between each Private Network connecting via VPN.

GRE is required because:

Allows for passing non-IP traffic (including Multicast, etc)

Creates a logical WAN Interface (with a /30 customer provided network).

Allows the Enterprise to extend their internal private network to the Wireless Private Network router.

Allows for simple EBGP peering at the GRE tunnel endpoints.

The Enterprise can make changes to their IP addressing without needing to notify Wireless Vendor.

The configuration needs to be similiar to this Configuration Template but will need a second tunnel included for backup.

crypto isakmp policy 1

encryption [ENCRYPTION TYPE]

hash [HASH TYPE]

authentication pre-share

group 2

crypto isakmp key [SECRET] address [REMOTE IP]

!

crypto ipsec transform-set [NAME] [TRANSFORM 1]

mode transport

!

crypto map [MAP NAME] 10 ipsec-isakmp

set peer peer [REMOTE IP ADDRESS]

set transform-set [TRANSFORM-SET NAME]

match address [ACCESS-LIST NUMBER OR NAME]

!

access-list [ACL NUMBER OR NAME] permit gre host

[LOCAL IP] host [REMOTE IP]

!

interface [INTERFACE NAME/NUMBER]

ip address [LOCAL IP]

crypto map [MAP NAME]

!

interface Tunnel0

ip address [LOCAL TUNNEL IP] 255.255.255.252

tunnel source [LOCAL INTERFACE IP]

tunnel destination [REMOTE IP]

!

router bgp [LOCAL AS NUMBER]

neighbor [VZW TUNNEL IP] remote-as 22394

network [INTERNAL NETWORK] mask [MASK]

[Richard Burts]

Nicholas

I have set up many routers with GRE and IPSec tunnels similar to what is described here. It is easy to set up a redundant tunnel, and you do not need secondary addressing to do it. What you do need is a second head end router. A Cisco router (and I am confident that this includes the 871) can easily support a second tunnel (and both tunnels can use the same source address) as long as the destination address of each tunnel is unique.

As I understand it, the problem with trying to do two tunnels from a single source router to a single destination router is not so much a problem with GRE as it is a problem with IPSec. The way that IPSec negotiates Security Associations will not actively use two separate tunnels from a single device to a single device.

HTH

Rick

[apietrosan]

For the actual real config we will indeed be using to seperate destination ip addresses.  But we also want to use to unique source addresses as well.  I think this is where the issue is.   The 871 we have , only has 1 x WAN.  We would need 2 x WAN ports to accomplish this right ?  If so is there a cisco router that you would recommend that wont break the bank.  I was looking into the 891.  If you have any ideas please let me know.  Thanks again for your help ad input.  It is greatly appreciated.  Also are you familiar with bgp.  I am new to bgp and have some questions concerning the setup of neighbors and advertised routes.    Would you have a sample config or something you could supply for bgp setup?

Thanks again.

Nick

[apietrosan]

Do you think I can accomplish the secondary tunnel by creating a Sub-Interface on FastEthernet4.  So I would create something like FastEthernet4.1 and assign a WAN ip to it, and use that as the source of Tunnel2.  Would this be feasible?

Nick

[Richard Burts]

Nick

Whether a subinterface with a separate IP address is feasible depends entirely on how the provider has set up the connection to your router. If the provider has set up the connection as a trunk with 2 VLANs and separate IP addressing in each VLAN then yes a subinterface is feasible. But it is very unusual for a provider to set up a connection that way. So ultimately I do not think that this would be a very feasible solution.

I am puzzled at the continuing insistence on a separate source address for the second tunnel. Is there a reason for this? Two tunnels, to two separate destination routers, using a single source address works very well. And trying to get two separate IP addresses is liekly to be fairly expensive (since you are in effect asking the provider to set up two connections).

HTH

Rick

[apietrosan]

Using a separate source address for the second tunnel is not my choice.  I am setting up a VPN IPSec Gre connection to utilize the Verizon Wireless Private Network which will be used for car mobile computers such as panasonic toughbooks.  Verizon requires 2 separate sources for the primary and secondary tunnels.  For my first tunnel I am using something like the following config:

crypto keyring vzwvpn

pre-shared-key address *.*.*.* key thisisasecret#

!

crypto isakmp policy 1

encr 3des

hash md5

authentication pre-share

group 2

crypto isakmp profile VZW-Crypto-Profile

   keyring vzwvpn

   self-identity address

   match identity address *.*.*.* 255.255.255.255

!

!

crypto ipsec transform-set VZW_TSET esp-3des esp-md5-hmac

mode transport

!

crypto map VZW_VPNTUNNEL 1 ipsec-isakmp

description Verizon Wireless Tunnel 1

set peer *.*.*.*

set transform-set VZW_TSET

set isakmp-profile VZW-Crypto-Profile

match address VZW_VPN

!

interface Tunnel1

description GRE Tunnel1 to VZW

ip address 192.168.70.2 255.255.255.252

ip mtu 1480

tunnel source *.*.*.*

tunnel destination *.*.*.*

tunnel path-mtu-discovery

crypto map VZW_VPNTUNNEL

crypto ipsec df-bit clear

!

interface FastEthernet0

!

interface FastEthernet4

description outside link to VZW VPN$ETH-WAN$

ip address *.*.*.* 255.255.255.248

duplex auto

speed auto

crypto map VZW_VPNTUNNEL

crypto ipsec df-bit clear

!

interface Vlan1

description LAN

ip address 192.168.12.199 255.255.255.0

ip access-group 100 in

ip tcp adjust-mss 1452

!

router bgp 65505

bgp log-neighbor-changes

neighbor 192.168.70.1 remote-as 6167

!

address-family ipv4

  neighbor 192.168.70.1 activate

  neighbor 192.168.70.1 default-originate

  no auto-summary

  no synchronization

  network 192.168.12.0

exit-address-family

!

no ip forward-protocol nd

ip route 0.0.0.0 0.0.0.0 *.*.*.*

!

!

ip access-list extended VZW_VPN

permit gre host *.*.*.* host *.*.*.*

permit icmp host *.*.*.* host *.*.*.*

permit udp host *.*.*.* host *.**.* eq isakmp

permit esp host *.*.*.* host *.*.*.*

permit gre host *.*.*.* host *.*.*.*

permit icmp host *.*.*.* host *.*.*.*

permit udp host *.*.*.* host *.*.*.* eq isakmp

permit esp host *.*.*.* host *.*.*.*

--------------------------------------------------------------------------------------------------------

Would you have any recommendations that might improve performance? 

Or do you notice anything that might be problematic in the config?

Thanks for your help.

Regards,

Nick

[Richard Burts]

Nick

The explanation that the second source address is a requirement from Verizon is somewhat helpful. If the router had some other type of connection as its primary connection and the wireless using VPN was a backup then it makes a lot of sense - and provides the answer to your question since the wireless would provide a second source address. But if this is for a car computer then it seems logical that the wireless may be the only connection and then the requirement for a second separate source address makes no sense to me at all.

HTH

Rick

[apietrosan]

I am confused myself.  I have another question.  If I have a router with Fastethernet8(WAN-BACKUP) and GigabitEthernet0(WAN-PRIMARY).  And I have Tunnel1 using tunnel source GigabitEthernet0 and Tunnel2 using tunnel source FastEthernet8.  If Fast Ethernet8 is set to down, then if GigabitEthernet0 fails for some reason, will FastEthernet8 automatically come up and do a no shutdown therefore activating Tunnel2. And will GigabitEthernet0 automatically do a shutdown when this happens therefore deactivating Tunnel1.

[Richard Burts]

Nick

I have never seen an implementation of redundant GRE/IPSec tunnels where the primary would become shutdown when it fails and where the backup becomes no shutdown. I will not say that it could not be done, but it would be very complex and I have not seen it down anywhere like that.

There are several choices of how to implement redundancy which might be available to you.

- some platforms (especially IOS routers) can put two peer addresses into the peer address in the crypto map and the router will attempt to negotiate crypto and bring up the tunnel with the first peer. And if the negotiation fails with the first peer then the router will attempt negotiation with the second peer.

- you can configure two separate and independent tunnels and have both tunnels up and active at the same time. You use a dynamic routing protocol to determine which of the tunnels to use, and if the primary tunnel stops working then the routing protocol converges and begins to send traffic through the second tunel.

- you can configure two separate and independent tunnels. You designate one tunnel and primary and the other tunnel as backup. You have something (usually a dynamic routing protocol)  that attempts to send interesting traffic through the primary tunnel which brings up and maintains the tunnel as active. If the primary tunnel fails then you direct the interesting traffic to the second tunnel which then brings up the second tunnel.

HTH

Rick

[apietrosan]

The problem I am having is when I try to bring up interface FastEthernet8 I get the following:

config-if)#no shutdown

% 65.51.250.136 overlaps with GigabitEthernet0

FastEthernet8: incorrect IP address assignment

I do not know what the problem is.  Any Ideas?  Any help would be greatly appreciated.  The config I am working on now looks something like this:

crypto keyring vzwvpn

  pre-shared-key address *(destination ip of primary tunnel)* key thisisasecret#

  pre-shared-key address *(destination ip of backup tunnel)* key thisisasecret#

!

crypto isakmp policy 1

encr 3des

hash md5

authentication pre-share

group 2

crypto isakmp profile VZW-Crypto-Profile   <----------------Crypto Profile for Primary

   keyring vzwvpn

   self-identity address

   match identity address *(destination ip of primary tunnel)* 255.255.255.255

crypto isakmp profile VZW-Crypto-Profile-Backup   <----------------Crypto Profile for Backup

   keyring vzwvpn

   self-identity address

   match identity address *(destination ip of backup tunnel)* 255.255.255.255

!        

!

crypto ipsec transform-set VZW_TSET esp-3des esp-md5-hmac

mode transport

!

crypto map VZW_VPNTUNNEL 1 ipsec-isakmp

description Verizon Wireless Primary Tunnel

set peer *(destination ip of primary tunnel)*

set transform-set VZW_TSET

set isakmp-profile VZW-Crypto-Profile

match address VZW_VPN_PRIMARY

crypto map VZW_VPNTUNNEL 2 ipsec-isakmp

description Verizon Wireless Tunnel Backup

set peer *(destination ip of backup tunnel)*

set transform-set VZW_TSET

set isakmp-profile VZW-Crypto-Profile-Backup

match address VZW_VPN_BACKUP

!

!

interface Tunnel1

description Primary GRE Tunnel to VZW

ip address 192.168.70.2 255.255.255.252

tunnel source GigabitEthernet0

tunnel destination *(destination ip of primary tunnel)*

tunnel path-mtu-discovery

crypto ipsec df-bit clear

crypto map VZW_VPNTUNNEL

!

!

interface Tunnel2

description Backup GRE Tunnel to VZW

ip address 192.168.40.1 255.255.255.252

tunnel source FastEthernet8

tunnel destination *(destination ip of backup tunnel)*

tunnel path-mtu-discovery

crypto ipsec df-bit clear

crypto map VZW_VPNTUNNEL

!

!

interface FastEthernet0

!

!

interface FastEthernet8    <--------------will not let me bring it up with no shutdown

description outside backup link to VZW

ip address *.*.*.* 255.255.255.248

shutdown                

duplex auto

speed auto

crypto ipsec df-bit clear

crypto map VZW_VPNTUNNEL

!

!

interface GigabitEthernet0  <---------------------this is up

description outside primary link to VZW

ip address *.*.*.* 255.255.255.248

duplex auto

speed auto

crypto ipsec df-bit clear

crypto map VZW_VPNTUNNEL

!

!

interface Vlan1

description LAN

ip address 192.168.12.199 255.255.255.0

ip access-group 100 in

ip tcp adjust-mss 1452

!

!

router bgp 65505

bgp log-neighbor-changes

neighbor 192.168.40.2 remote-as 6167

neighbor 192.168.70.1 remote-as 6167

!

address-family ipv4

  no synchronization

  network 192.168.12.0

  neighbor 192.168.40.2 activate

  neighbor 192.168.40.2 default-originate

  neighbor 192.168.70.1 activate

  neighbor 192.168.70.1 default-originate

  no auto-summary

exit-address-family

!

ip forward-protocol nd

ip http server

ip http access-class 1

ip http authentication local

ip http secure-server

ip http timeout-policy idle 60 life 86400 requests 10000

!

!

ip route 0.0.0.0 0.0.0.0 *.*.*.*  <-------------------------Default Route

!

ip access-list extended VZW_VPN_PRIMARY    <--------------------------------Access-list for PRIMARY

permit gre host *.*.*.* host *.*.*.*

permit icmp host *.*.*.* host *.*.*.*

permit udp host *.*.*.* host *.*.*.* eq isakmp

permit esp host *.*.*.* host *.*.*.*

permit gre host *.*.*.* host *.*.*.*

permit icmp host *.*.*.* host *.*.*.*

permit udp host *.*.*.* host *.*.*.* eq isakmp

permit esp host *.*.*.* host *.*.*.*

ip access-list extended VZW_VPN_BACKUP   <------------------------------Access-list for BACKUP

permit gre host *.*.*.* host *.*.*.*

permit icmp host *.*.*.* host *.*.*.*

permit udp host *.*.*.* host *.*.*.* eq isakmp

permit esp host *.*.*.* host *.*.*.*

permit gre host *.*.*.* host *.*.*.*

permit icmp host *.*.*.* host *.*.*.*

permit udp host *.*.*.* host *.*.*.* eq isakmp

permit esp host *.*.*.* host *.*.*.*

------------------------------------------------------------------------------------------------------------------------------------------

[Richard Burts]

Nick

You have completely hidden the addresses of the interfaces involved and that makes it diffiicult to be sure about the problem. Based on the error message that you report I would guess that either the address of FastEthernet8 is exaclly the same as the address on Gig0 or that the address is in the same subnet. IOS will not allow 2 LAN interfaces to have addresses in the same subnet (unless one interface is configured as backup-interface for the other - and I do not think that this is what you want to do).

Also I notice that under the tunnel configurations you have included the crypto map command. You should not have this on the tunnel configuration - it should be only on the outbound interface configuration. So Gig0 should have the primary crypto map and Fast8 should have the backup crypto map.

HTH

Rick

[apietrosan]

The  addressing for the interfaces is as follows:  (I am letting you see the addresses in confidence. because you have been a great help and I appreciate it)

interface FastEthernet8

description outside backup link to VZW

ip address 0.0.0.0 255.255.255.248

interface GigabitEthernet0

description outside primary link to VZW

ip address 0.0.0.0 255.255.255.248

These are not LAN interfaces though.  They are WAN interfaces,   Let me know if this helps and if you have any ideas.

Also when I specify the crypto map on only the outbound interfaces do I need to specify only

crypto map VZW_VPNTUNNEL or do I need to include the sequence # as well.  I will remove the crypto maps from the tunnel interfaces like you said.

crypto map VZW_VPNTUNNEL 1 ipsec-isakmp   <-------------- 1 is the sequence # here

description Verizon Wireless Primary Tunnel

crypto map VZW_VPNTUNNEL 2 ipsec-isakmp   <--------------- 2 is the sequence # here

description Verizon Wireless Tunnel Backup