Configure GRE Tunnel and Only Use Routes from Destination

[mjscott90]

I have RTR1 connected to RTR2 over a GRE Tunnel.  The two RTRs are geographically separated.  I would like all traffic from RTR1 to go to RTR2 and ignore the routes between RTR1 and RTR2.  Is this possible over a GRE Tunnel or should I be using a VPN between RTR1 and RTR2 vise a GRE Tunnel?

[AndreaTornaghi]

You can do it by OSPF, after that the GRE tunnel is up and running.

You can use the default information originate on RTR2 so all traffic from RTR1 will be tunnel towards RTR2.

Something like these:

R2
!
interface Tunnel0
ip address 172.18.2.1 255.255.255.0
tunnel source Loopback0
tunnel destination 3.3.3.3
!
!
router ospf 10
network 172.18.2.0 0.0.0.255 area 0

default-information originate
!

interface Loopback0
ip address 2.2.2.2 255.255.255.255

! 

ip route 3.3.3.3 255.255.255.255 <next hop interface>

R1
!
interface Tunnel0
ip address 172.18.2.2 255.255.255.0
tunnel source Loopback0
tunnel destination 2.2.2.2
!
!
router ospf 10
network 172.18.2.0 0.0.0.255 area 0
!

interface Loopback0
ip address 3.3.3.3 255.255.255.255

!

ip route 2.2.2.2 255.255.255.255 <next hop interface>

[Deepak Kumar]

Hi,

You can go with GRE tunnel and PBR. It is easy to understand and no need for some extra cost of Dynamic routing. It will also help you to maintain a failover case:

PRT1 Configuration:

!

interface Tunnel1
ip address 172.16.16.2 255.255.255.0
tunnel source FastEthernet0/0
tunnel destination 192.168.1.1
!
interface FastEthernet0/0
Description WAN Interface
ip address 1.10.9.2 255.255.255.0
duplex full
!
interface FastEthernet1/0
Description LAN Interface
ip address 10.10.10.1 255.255.255.0
ip policy route-map PBR
!
!

ip route 0.0.0.0 0.0.0.0 1.10.9.1
!
ip access-list extended PBR
permit ip 10.10.10.0 0.0.0.255 any
!
ip sla 1
icmp-echo 172.16.16.1 source-ip 10.10.10.1
ip sla schedule 1 life forever start-time now
!
track 1 ip sla 1 reachability
!
route-map PBR permit 10
match ip address PBR
set ip next-hop verify-availability 172.16.16.1 1 track 1

RTR2 Configuration:
!
interface FastEthernet0/0
 ip address 10.10.11.1 255.255.255.0
description LAN Connection
IP NAT Inside
!
interface Tunnel1
 ip address 172.16.16.1 255.255.255.0
 ip nat inside
 tunnel source FastEthernet0/0
 tunnel destination 1.10.9.2
!
interface FastEthernet0/0
description WAN Connection
 ip address 192.168.1.1 255.255.255.0
 ip nat outside
!
ip nat inside source list NAT interface FastEthernet0/0 overload
!

ip route 0.0.0.0 0.0.0.0 192.168.1.2
ip route 10.10.10.0 255.255.255.0 172.16.16.2
!
!
ip access-list extended NAT
deny ip 10.10.10.0 0.0.0.255 10.10.11.0 0.0.0.255
deny ip 10.10.11.0 0.0.0.255 10.10.10.0 0.0.0.255
permit ip 10.10.10.0 0.0.0.255 any
permit ip 10.10.11.0 0.0.0.255 any

Regards,

Deepak Kumar

[Georg Pauwen]

Hello,

actually, a VPN is recommended, the config is very simple. You are using the public Internet, so just a GRE tunnel is vulnerable. Here is an example of an SVTI:

R1

interface GigabitEthernet0/0

description Link to ISP

ip address 1.1.1.1 255.255.255.0
!
interface Loopback1
ip address 192.168.1.1 255.255.255.0
!
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key cisco123 address 1.1.1.2
!
crypto ipsec transform-set TS esp-3des esp-sha-hmac
!
crypto ipsec profile IPSEC_PROFILE
set transform-set TS
!
interface Tunnel0
ip address 172.16.0.1 255.255.255.0
tunnel source 1.1.1.1
tunnel destination 1.1.1.2
tunnel mode ipsec ipv4
tunnel protection ipsec profile IPSEC_PROFILE
!
router eigrp 1
network 172.16.0.0
network 192.168.1.0

R2

interface GigabitEthernet0/0

description Link to ISP
ip address 1.1.1.2 255.255.255.0
!
interface Loopback1
ip address 192.168.2.2 255.255.255.0
!
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key cisco123 address 1.1.1.1
!
crypto ipsec transform-set TS esp-3des esp-sha-hmac
!
crypto ipsec profile IPSEC_PROFILE
set transform-set TS
!
interface Tunnel0
ip address 172.16.0.2 255.255.255.0
tunnel source 1.1.1.2
tunnel destination 1.1.1.1
tunnel mode ipsec ipv4
tunnel protection ipsec profile IPSEC_PROFILE
!
router eigrp 1
network 172.16.0.0
network 192.168.2.0

[Deepak Kumar]

Hi,

As I am getting his point that he " I would like all traffic from RTR1 to go to RTR2" means as a full tunnel so is it correct? and will get the same with EIGRP?

Why am I asking this question becuase he would need a default route on his PRT1 to get connected with his ISP and GRE tunnel so eigp will not replace to default route do to AD value?  Here, if we will convert default to floating default route than GRE will go down.

Is there any solution without PBR? Yes, he can configure a static route instead of default route but it is not recommended in case of tunnel fail.

Regards,

Deepak Kumar

[Richard Burts]

There have been some interesting and useful responses and I would like to address a few points. The suggestion of configuring the GRE tunnel and running OSPF over the tunnel is nice and would certainly work and achieve the goal of the original poster. But the response suggesting keeping the solution simple and suggesting that OSPF might be overkill has some validity. But if we want to really keep it simple then there is no need for Policy Based Routing. If you simply configure the GRE tunnel, configure a static route for the tunnel destination using the provider address as the next hop, and configure a static default route using the tunnel peer address as the next hop should be all that is required. 

One factor to consider in this discussion is whether to use a dynamic routing protocol or to use static routing. To provide good advice we need more information about the environment. Dynamic routing is appropriate for environments that need to react to changes in the routing environment and to be able to select alternate paths if the primary path has problems. When there are not alternate paths then dynamic routing has no advantage and static routing is adequate. So which kind of environment is this?

There is also a question about using GRE (without encryption) or using vpn. To provide good advice we need more information about the environment and the requirements. As mentioned in one of the responses sending IP traffic over a simpleGRE tunnel does not provide any protection for the traffic. If the traffic between sites contains sensitive information that needs protection then certainly vpn is the better choice. But if there is not much concern about protecting the content then a simple GRE tunnel is easier and involves less overhead and would seem to achieve the goal stated in the original post.

HTH

Rick

[Deepak Kumar]

---

@Richard Burts wrote:

 If you simply configure the GRE tunnel, configure a static route for the tunnel destination using the provider address as the next hop, and configure a static default route using the tunnel peer address as the next hop should be all that is required.

---

Thanks for your response and here, My question is still open "Yes, he can configure a static route instead of default route but it is not recommended in case of tunnel fail". 

As per my interest in the design, I will keep internet failover. If my tunnel went down then (at least) the internet must work.  What do you think on this point?

Regards,

Deepak Kumar

[Richard Burts]

Deepak

from your perspective failover and redundancy are important. And most of the customers I have dealt with feel the same. One of the things I have learned is that it is important to understand what the customer wants and to provide that. One of the things I was saying in my response is that we need to understand the original poster and what is their requirements. If they need failover and redundancy then our suggested solution goes in one way. If they don’t need that then the simplicity and low overhead of static routing is appealing. So we need more information from the original poster about what they need. 

HTH

Rick

[mjscott90]

I want to thanks everyone for helping me out on this.  So for some clarification, I do not require any redundancy, I have another solution in place for that.  This solution does not require security, this is a low priority.  If it helps I can provide an example of the current interface configs and ospf and networking statements in the RTRs ina few days when I return back to the lab.  I do not have remote access to these devices from home.

[Deepak Kumar]

Hi,

PRT1 router configuration:

interface Tunnel1
 ip address 172.16.16.2 255.255.255.0
 tunnel source FastEthernet0/0
 tunnel destination <PRT2-Router-WAN-IP>
!
interface FastEthernet0/0

Description WAN Interface
 ip address 1.10.9.2 255.255.255.0
 duplex full
!
interface FastEthernet1/0

Description LAN Interface
 ip address 10.10.10.1 255.255.255.0
!
!
router eigrp 1
 network 10.10.10.0 0.0.0.255
 network 172.16.16.0 0.0.0.255
 passive-interface FastEthernet1/0
!
ip route <PRT2-router-WAN IP> 255.255.255.255 FastEthernet0/0
!

PRT2 Router configuration:

!
interface Tunnel1
 ip address 172.16.16.1 255.255.255.0
 ip nat inside
 tunnel source FastEthernet0/0
 tunnel destination 1.10.9.2
!
interface FastEthernet0/0

Description WAN Interface
 ip address 192.168.1.1 255.255.255.0
 ip nat outside
 duplex full
!

interface FastEthernet1/0

Description LAN Interface
 ip address 10.10.11.1 255.255.255.0
 ip nat inside
 duplex full

!
router eigrp 1
 network 10.10.11.0 0.0.0.255
 network 172.16.16.0 0.0.0.255
 redistribute static metric 100000 1000 255 1 1500
 passive-interface FastEthernet1/0
!
ip nat inside source list NAT interface FastEthernet0/0 overload
!
ip route 0.0.0.0 0.0.0.0 192.168.1.2

!
!ip access-list extended NAT
deny ip 10.10.10.0 0.0.0.255 10.10.11.0 0.0.0.255
deny ip 10.10.11.0 0.0.0.255 10.10.10.0 0.0.0.255
permit ip 10.10.10.0 0.0.0.255 any
permit ip 10.10.11.0 0.0.0.255 any

Please note that there is no Security over the GRE tunnel.

@Richard Burts thanks for find mistake.

Regards,

Deepak Kumar

[Richard Burts]

It is good to have clarification from the original poster that their requirements do not include security for traffic between sites. So there is no justification for vpn or encryption of traffic between sites. There is also clarification that they do not require redundancy. I take that to mean that they do not require a dynamic routing protocol running between sites. The config suggestion from Deepak runs EIGRP on the local subnet and on the tunnel. The original poster can decide whether they want the dynamic routing protocol as part of the solution.

I note from the EIGRP network statements and the ACL for NAT that the intention was to have the LAN subnets be 10.10.10.0 and 10.10.11.0. But the configuration of both LAN interfaces uses 10.10.10.0. I assume that this was a typo.

I believe that we are getting very close to a configuration that the original poster can use.

HTH

Rick

[Richard Burts]

Deepak

You are quite welcome. This kind of mistake is very easy to make (I know this because I have done it several times myself and had it pointed out). One of the advantages of communities like this is that we have multiple people reading the discussion and multiple sets of eyes reading the content makes it possible to find things that we missed when we were writing the response.

HTH

Rick