Posts tagged ‘GRE’

When doing some network engineering, it’s sometimes necessary to tunnel across IP-clouds. There are multiple reasons why one would use a tunnel:

  • Security: You don’t want the carrier-network to see your data
  • IP conflicts and/or routing issues: You want to carry private IP addresses (eg 10.0.0.0/8 in IPv4) across a public segment (eg the Internet)
  • Workarounds: for whatever reason you whised that there was a connection between A and B

Technically, a tunnel consists of taking a bunch of bytes and re-packaging it. The well knows GRE-tunnel takes IP packets and encapsulates them in another IP packet. The outer IP-layer is used to carry the packet across to the other endpoint, where the inner IP-layer reappears. Other tunnels operate at different layers. SSH for example encapsulates TCP segments inside its TCP-connection; SSL-based VPN encapsulate IP packets inside their TLS-session.

Especially in the third case, workarounds, it would be very practical to be able to build a layer 2 tunnel: transport raw ethernet frames, including IEEE802.1q VLAN tags. This is called the L2TP, Layer 2 tunneling protocol. The current version (3) is defined in RFC 3931.

Continue reading ‘Ethernet over IP (L2TP) on Cisco’ »

Recently I had to configure a router serving as an IPsec-GRE endpoint. So far, nothing special. The interesting part is that the terminating router is behind a NAT-device which changes the outer IP-header of the IPsec tunnel. Of course, the GRE-header is NOT affected by the NAT (since it is encrypted).

To summarize, the device needs to:

  • terminate an IPsec tunnel between 172.16.2.2 <-> 10.0.0.4 (its own IP); but authenticate as 172.16.2.4
  • terminate a GRE tunnel between 172.16.1.1 <-> 172.16.2.4 (a public IP that is NATed towards it)

The diagram is shown below:

172.16.x.x addresses are “public”; 10.x.x.x are private.

Continue reading ‘Terminating an IPsec-GRE tunnel behind NAT’ »