IPSEC tunnel and GRE

[ajike ola]

I need your help understanding this configuration:

I was trying out GRE over IPSEC in my home lab, using the following configuration:

R1==>R3==>R2

My GRE and IPSEC originate at R1 and terminate on R2, and I verified that the tunnel is up and running on both R1 and R2. I also verified the packets are being encapsulated and encrypted, using "show crypto ipsec sa".

However, when I connected a PC to R3, I was able to ping both R1 and R2.

I didn't think I should be able to do this, given this is supposed to be a secured tunnel.

Someone please help me understand

Thanks

[lgijssel]

Hi,

Using a secure tunnel does not exclude other traffic on a network.

In this case, the ICMP requests (ping) are not sent via the tunnel but directly to R1/R2.

When you want a proper simulation of how tunnels work on the Internet, exclude the interfaces that are not connected to R3 from the routing protocol. In other words: R3 should only see the connected networks towards R1 and R2.

This effectively simulates the inside network (often private ip's) on a site which sends packets through a tunnel to the remote side. If you do this, you will see that R3 is no longer able to send traffic to these networks.

regards,

Leo

[Edison Ortiz]

In addition to Leo's suggestion, can you post the ACL being used for the IPSec?

If the src/dst is not included in the IPSec ACL, the traffic to/from will be unencrypted.

[ajike ola]

Thanks for your help guys.

If I really want my PC traffic to go through the tunnel, what do I need to do?

Edison,

Below is my ACL for R2 - as you know, it is the reverse for R1:

ip access-list extended myipsec

remark VPN traffic

permit gre host 173.45.56.67 host 172.123.124.125

Thanks for your help

[Edison Ortiz]

Have a static route (the PC IP Address) pointing to the tunnel at both end-points.

For instance:

PC connected to R3 is 192.168.1.1

ip route 192.168.1.1 255.255.255.255 tunnelx

Do this on R1 and R2. They will both try to respond to any ICMP packets from the PC via the tunnel and it will fail because the PC will respond back with unencrypted traffic.

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

To do that, R1 and R2 must "know" about each other's far side networks.  Perhaps the easiest way to accomplish that is to run a dynamic routing protocol across the tunnel.

[Alexander Maroukian]

Hi,

Add route to the R1 inside network on R2 and vise-versa. Use "snmp-server host ip_address_of_your_host " "snmp-server enable"to send your traps. Use firewall to block the access from undesired sites like R3 or just some ACLs.

If you are using ipsec and gre over nat you can check this document:

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_configuration_example09186a00800946b8.shtml#table1

regards,

Alex

[ajike ola]

First, I am sorry for the lack of clarity, this is all new to me.

I followed the advice given by Edison, and now when I ping from my PC to networks outside the tunnel (which is between R1 and R2), my ping fails, as Edison suggested it would. However, when I do a "show crypto ipsec sa", I could see the packets incrementing relative to my pings.

I do want the data from my PC to go through the tunnel, because my PC has a management software, that needs to go through the tunnel, in order to manage networks beyond the tunnel.

I think to be able to accomplish this, and I could be wrong, the PC should be able to ping through the tunnel to those services outside the tunnel.

What do I have to do to accomplish this?

Thanks again for your help and patience

[Edison Ortiz]

If you followed my advice, the crypto ipsec output is expected. The router has the PC IP address on its ACL so traffic will be sent encrypted, however the PC is not sending encrypted traffic hence the failure.

Where exactly you want to place the PC? If the PC is connected to R3, then we need to engineer something different as R3 does not have any IPSec configured.

If the PC is connected to either R1 or R2, the situation would be a lot easier and all you need to do is make sure the ACL matches the interesting traffic and the routing points to the tunnel.

We need more information from you like subnets you want to encrypt and a network diagram would help as well.

Regards,

Edison

[ajike ola]

Thanks for taking the time again. I am not sure if what I am about to describe could be done, but here it is.

USING MY INITIAL diagram:

                                                ……R1 ••è R3 ••è R2…..

                                                                     ^

                                                                     |

                                                                NMS PC

• With my NMS PC connected to R3
  
• A tunnel should be setup from R1 to R3
  
• Another tunnel from R2 to R3
  
• There are several devices connected to the other side of R1 and R2, forming a ring configuration. This is depicted by the dotted lines. Imagine the other interface of R1 as being connected directly to the other interface of R2 (although there are several devices in between).
  

I would like the NMS PC to be able to see all the devices connected to R1 and R2 through both tunnels; this way, if I lose my connectivity on one path, I would still be able to manage my devices.

I hope this helps to clarify my objectives, otherwise please let me know.

Thanks

Ajike

[Edison Ortiz · Accepted solution]

Per your network layout, we should treat R3 as the hub and R1 and R2 being the spokes.

You can either setup DMVPN or create multiple GRE tunnels on R3. One GRE tunnel will points towards R1 and another one to R2.

The routing can be configured with OSPF. Enabled OSPF on the LAN interfaces and the GRE interfaces.

On the IPSec ACL just match on gre from the src/dst tunnel IP.

Routing devices sitting behind R1 and R2 should also run OSPF so they can learn subnet reachability to the remote connection.

Clear enough for you?

Please remember to rate helpful posts.

Regards,

Edison

[ajike ola]

Thanks for all your help.The configuration to use two different tunnels; both originating from R3 and terminating on R1 and R2 respectivel appeals to me, so this what I am going with. I have already given it a shot, but couldn't get either tunnel to stay up. I would review the configuration one more time; I am sure I missed something.

Thanks again.

[Edison Ortiz]

You can post your configuration if you need additional help.

[ajike ola]

Let me explain what I did; I might be violating some configuration rule here. Given that all my routers only have 2 interfaces, what I tried to do is connect router 3 to a switch. On the switch, I created two VLANs (100 and 200), and a trunk port. I then created two sub-interfaces in R3. Therefore, I am originating my tunnels from the sub-interfaces on R3; one tunnel pointing to R1 and another pointing to R2.

Could this be a problem?

[Edison Ortiz]

It should work - I put a little lab here to validate....

Hub Router:

crypto isakmp policy 10

encr aes 256

authentication pre-share

crypto isakmp key cisco123 address 192.168.100.2

crypto isakmp key cisco123 address 192.168.200.2

!

!

crypto ipsec transform-set aesset esp-aes 256 esp-sha-hmac

!

crypto map aesmap 10 ipsec-isakmp

set peer 192.168.100.2

set transform-set aesset

match address acl_vpn_r2

crypto map aesmap 20 ipsec-isakmp

set peer 192.168.200.2

set transform-set aesset

match address acl_vpn_r3

!

!

!

!

!

!

!

interface Loopback0

ip address 150.1.1.1 255.255.255.255

!

interface Tunnel1

ip address 192.168.12.1 255.255.255.0

tunnel source 192.168.100.1

tunnel destination 192.168.100.2

!

interface Tunnel2

ip address 192.168.13.1 255.255.255.0

tunnel source 192.168.200.1

tunnel destination 192.168.200.2

!

interface FastEthernet0/0

no ip address

duplex auto

speed auto

!

interface FastEthernet0/0.1

encapsulation dot1Q 100

ip address 192.168.100.1 255.255.255.0

crypto map aesmap

!

interface FastEthernet0/0.2

encapsulation dot1Q 200

ip address 192.168.200.1 255.255.255.0

crypto map aesmap

ip route 150.1.2.2 255.255.255.255 Tunnel1

ip route 150.1.3.3 255.255.255.255 Tunnel2

no ip http server

no ip http secure-server

!

!

!

ip access-list extended acl_vpn_r2

permit gre host 192.168.100.1 host 192.168.100.2

ip access-list extended acl_vpn_r3

permit gre host 192.168.200.1 host 192.168.200.2

Spoke Router R2:

crypto isakmp policy 10

encr aes 256

authentication pre-share

crypto isakmp key cisco123 address 192.168.100.1

!        

!

crypto ipsec transform-set aesset esp-aes 256 esp-sha-hmac

!

crypto map aesmap 10 ipsec-isakmp

set peer 192.168.100.1

set transform-set aesset

match address acl_vpn_r1

!

!

!

!

!

!

!

interface Loopback0

ip address 150.1.2.2 255.255.255.255

!

interface Tunnel1

ip address 192.168.12.2 255.255.255.0

tunnel source 192.168.100.2

tunnel destination 192.168.100.1

!

interface FastEthernet0/0

ip address 192.168.100.2 255.255.255.0

duplex auto

speed auto

crypto map aesmap

!

ip route 0.0.0.0 0.0.0.0 Tunnel1

!

!

!

ip access-list extended acl_vpn_r1

permit gre host 192.168.100.2 host 192.168.100.1

Spoke Router R3:

crypto isakmp policy 10

encr aes 256

authentication pre-share

crypto isakmp key cisco123 address 192.168.200.1

!        

!

crypto ipsec transform-set aesset esp-aes 256 esp-sha-hmac

!

crypto map aesmap 10 ipsec-isakmp

set peer 192.168.200.1

set transform-set aesset

match address acl_vpn_r1

!

!

!

!

!

!

!

interface Loopback0

ip address 150.1.3.3 255.255.255.0

!

interface Tunnel1

ip address 192.168.13.2 255.255.255.0

tunnel source 192.168.200.2

tunnel destination 192.168.200.1

!

interface FastEthernet0/0

ip address 192.168.200.2 255.255.255.0

duplex auto

speed auto

crypto map aesmap

!

ip route 0.0.0.0 0.0.0.0 Tunnel1

!

!

!

ip access-list extended acl_vpn_r1

permit gre host 192.168.200.2 host 192.168.200.1

Verification:

R1#ping 150.1.2.2 so lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 150.1.2.2, timeout is 2 seconds:

Packet sent with a source address of 150.1.1.1

.!!!!

Success rate is 80 percent (4/5), round-trip min/avg/max = 180/218/240 ms

R1#ping 150.1.3.3 so lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 150.1.3.3, timeout is 2 seconds:

Packet sent with a source address of 150.1.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 204/222/244 ms

local  ident (addr/mask/prot/port): (192.168.100.1/255.255.255.255/47/0)

   remote ident (addr/mask/prot/port): (192.168.100.2/255.255.255.255/47/0)

   current_peer 192.168.100.2 port 500

     PERMIT, flags={origin_is_acl,}

    #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4

    #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4

protected vrf: (none)

   local  ident (addr/mask/prot/port): (192.168.200.1/255.255.255.255/47/0)

   remote ident (addr/mask/prot/port): (192.168.200.2/255.255.255.255/47/0)

   current_peer 192.168.200.2 port 500

     PERMIT, flags={origin_is_acl,}

    #pkts encaps: 9, #pkts encrypt: 9, #pkts digest: 9

    #pkts decaps: 9, #pkts decrypt: 9, #pkts verify: 9