0

I'm trying to figure out exactly what is happening when I create a GRE tunnel.

My network looks like this (-> means directly connected):

  • Computer A (eth0: 10.0.1.1) ->
  • (eth0: 10.0.1.2) Router B (eth1: 10.0.2.1) ->
  • (eth0: 10.0.2.2) Router C (eth1: 10.0.3.1) ->
  • (eth0: 10.0.3.2) Router D (eth1: 10.0.4.1) ->
  • (eth-: 10.0.4.2) Computer E

I've run the following commands on Router B: 

ip tunnel add Tunnel5 mode gre local 10.0.2.1 remote 10.0.3.2
ifconfig Tunnel5 192.168.33.2 netmask 255.255.255.0 up
ip route add 10.0.4.2/32 via 192.168.33.3

with the following connection information:

conn routerD_eth0
    type=tunnel
    authby=secret
    left=10.0.2.1
    leftsubnet=10.0.2.1/32
    right=10.0.3.2
    rightsubnet=10.0.3.2/32
    auto=start

And the equivalent on Router D:

ip tunnel add Tunnel5 mode gre local 10.0.3.2 remote 10.0.2.1
ifconfig Tunnel5 192.168.33.3 netmask 255.255.255.0 up
ip route add 10.0.1.1/32 via 192.168.33.2

with

conn routerb_eth1
    type=tunnel
    authby=secret
    left=10.0.3.2
    leftsubnet=10.0.3.2/32
    right=10.0.2.1
    rightsubnet=10.0.2.1/32
    auto=start

This is what I can observe at Router A if I ping from Computer A to Computer B:

  1. Traffic enters eth0 with the destination of 10.0.4.2.

  2. Traffic is routed to the new Tunnel5 interface: Caused by the routing rule I added (ip route add 10.0.4.2/32 via 192.168.33.3)

  3. ??? Magic ??? Somehow the traffic is encapsulated and routed back to the router with the new destination address of 10.0.3.2

  4. Normal OSPF routing rules cause the traffic to go out eth1 and on to its destination.

What happens at step 3?

Additional Information

Some commands and their output, all run at Router A:

$ ip tunnel show
Tunnel5: gre/ip remote 10.0.3.2 local 10.0.2.1

$ setkey -DP
10.0.3.2[any] 10.0.2.1[any] 255
    ...
    /esp/tunnel/10.0.3.2-10.0.2.1/unique:3
    ...

10.0.2.1[any] 10.0.3.2[any] 255
    ...
    /esp/tunnel/10.0.2.1-10.0.3.2/unique:3
    ...

Theory

The router just knows, based on the information in "ip tunnel show", that traffic routed to Tunnel5 should be encapsulated with the new source and destination addresses.

The encapsulated packet should just be routed like normal. In this case, the IPSec Policies match up and encrypt the packet, preserving the source and destination addresses.

The packet is then routed, based on the routing table, to Router C.

Just a guess.

exxodus7
  • 95
  • 1
  • 8
  • Maybe you want to move this to http://networkengineering.stackexchange.com/ – ETL Feb 26 '14 at 20:26
  • Didn't know that existed! I don't know how to move or close things, don't think I can. I reposted it on the other website. If someone wants to close this that'd be awesome! -Thanks – exxodus7 Feb 26 '14 at 21:20

1 Answers1

1

When the packet enters the router, it is routed out the tunnel interface because of your static route. the router encapsulates the packet in a GRE packet, with the destination 10.0.3.2. The router then routes this packet according to the routing table (i.e. out eth 1). When it gets to router D, the packet is decapsulated and then routed normally.

Mike Pennington
  • 8,266
  • 9
  • 41
  • 86
Ron Trunk
  • 2,149
  • 1
  • 10
  • 19
  • So (logically speaking) the packet goes from router -> tunnel interface where it is encapsulated in a gre tunnel -> back to router -> encapsulated in an ipsec tunnel (where encapsulation has same source, destination as gre tunnel) and routed out eth1 based on the routing table? – exxodus7 Feb 27 '14 at 15:01
  • Another way to word that... are there two tunnels here? A GRE tunnel and an IPSec tunnel which then encapsulates the GRE tunnel? – exxodus7 Feb 27 '14 at 15:07
  • I didn't see the IPSEC part but yes, the GRE packets are then encapsulated in an IPSEC ESP packet. So, receive the packet , encapsuate, encapsulate again and then forward. – Ron Trunk Feb 27 '14 at 22:51
  • Awesome, thanks! And after I run my tunnel-creation bit, I see new IPSec policies appear (think its from the "conn..." configuration). – exxodus7 Feb 28 '14 at 14:17