1 INTRODUCTION

OSPF with GRE over IPsec on Linux

Content
1 2 3 4 5 Introduction.......................................................................................................... 1 The example network............................................................................................2 IPsec...................................................................................................................... 2 GRE....................................................................................................................... 4 OSPF..................................................................................................................... 5

Introduction

IPsec an abbreviation of IP security is a widely used technology to build VPN connections on IP-based networks. It is implemented on many network operating systems and powered by a lot of hardware appliances. Open Shortest Path First (OSPF) is a link-state, hierarchical Interior Gateway Protocol routing algorithm. It distinguishes them by a scalable network support and fast convergence time. OSPF is widely used in large networks such as ISP backbone and enterprise networks. To find his routing neighbours in the network OSPF sends messages to a multicast address. But IPsec natively does not support multicast routing. In the case two sites, connected by IPsec and should use OSPF as dynamic routing also over the VPN, it is an easy way to lay a Generic Routing Encapsulation (GRE) tunnel over the IPsec and transport the OSPF through the GRE.

2005-06-20

-1-

Lipa Systemy www.lipasys.de

2 THE EXAMPLE NETWORK

The example network

10.0.0.1/32 gre1 10.1.1.1/24 eth1 GW1 IPsec ESP IPsec SA GRE 217.18.45.113 eth0 internet 146.128.15.3 eth0 GW2 gre1 10.0.0.2/32 10.2.2.2/24 eth1

To demonstrate the configuration, in this documentation is used an example network shown in the diagram. Two gateways, GW1 and GW2, are connected together over an untrusted network the internet. The private LAN communication between the sites is protected by IPsec. To propagate the connected local networks to the corresponding peer, on the gateways is running an OSPF process.

IPsec

This example uses the recommended cryptographic functionality of the Linux 2.6 kernel, the IKE is powered by the racoon daemon from the IPSec-Tools. The communication is carried in tunnel mode, authenticated with a preshared key. Here are the sample configuration files: /etc/racoon/racoon.conf
path include "/etc/racoon"; path pre_shared_key "/etc/racoon/psk.txt"; remote anonymous { exchange_mode main,aggressive; my_identifier address; peers_identifier address; generate_policy on; initial_contact on; proposal_check obey; # obey, strict or claim lifetime time 600 min; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2; }

2005-06-20

-2-

Lipa Systemy www.lipasys.de

3 IPSEC

sainfo anonymous { pfs_group 2; lifetime time 60 min; encryption_algorithm 3des, blowfish, aes; authentication_algorithm hmac_sha1, hmac_md5; compression_algorithm deflate; }

The key word anonymous in the sections remote and sainfo declares a default peer, the proposals are used on every connection not specially defined. /etc/racoon/psk.txt on GW1
146.128.15.3 PRE_SHARED_KEY

and on GW2
217.18.45.113 PRE_SHARED_KEY

/etc/racoon/setkey.conf In the file setkey.conf are defined the IPsec security policies of both directions separate. on GW1
spdflush; spdadd 10.1.1.0/24 10.2.2.0/24 any -P out ipsec esp/tunnel/217.18.45.113-146.128.15.3/require; spdadd 10.2.2.0/24 10.1.1.0/24 any -P in ipsec esp/tunnel/146.128.15.3-217.18.45.113/require;

on GW2
spdflush; spdadd 10.2.2.0/24 10.1.1.0/24 any -P out ipsec esp/tunnel/146.128.15.3-217.18.45.113/require; spdadd 10.1.1.0/24 10.2.2.0/24 any -P in ipsec esp/tunnel/217.18.45.113-146.128.15.3/require;

To start the IPsec connection, type in a root shell

2005-06-20

-3-

Lipa Systemy www.lipasys.de

3 IPSEC

/etc/init.d/racoon start

Following the successful establishing of the IPsec the route to the peers local network has to be defined. It is sufficient to configure a host route, the complete network will be propagated later by the OSPF process. On GW1 you get the route by the shell command
ip route add 10.2.2.2/32 dev eth1

and on GW2 by
ip route add 10.1.1.1/32 dev eth1

To verify the correct function you can ping the peers external and internal interface. Because of the encryption, the round trip time has to be longer in case of the internal one.

GRE

The GRE tunnel is configured between the local interfaces eth1 on the gateways, so all tunnel traffic will be matched by the IPsec SA and encrypted. The new created virtual interface gre1 gets an own IP address. The commands to create the tunnel are on GW1
ip tunnel add gre1 mode gre local 10.1.1.1 remote 10.2.2.2 ttl 255 ip link set gre1 up multicast on mtu 1420 ip addr add 10.0.0.1 peer 10.0.0.2 dev gre1

and on GW2
ip tunnel add gre1 mode gre local 10.2.2.2 remote 10.1.1.1 ttl 255 ip link set gre1 up multicast on mtu 1420 ip addr add 10.0.0.2 peer 10.0.0.1 dev gre1

Note: because of the additional IPsec header the MTU size has to be reduced to 1420 Octets. To check the route the peers gre1 interface can be pinged. The multicast transport can be verified too by pinging the multicast address 224.0.0.1 over the gre1 interface directly.
ping -r -I gre1 224.0.0.1

2005-06-20

-4-

Lipa Systemy www.lipasys.de

4 GRE

Attention: Be sure the Linux boxes answers on multicast pings. One answer has to come from the local machine. In case of failure, check the global ICMP configuration. To switch the multicast and broadcast answering on, type
echo "0" > /proc/sys/net/ipv4/icmp_echo_ignore_all echo "0" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

OSPF

The current modern implementation of routing software on Unix platforms is Quagga, the successor of the Zebra project. The Quagga architecture consists of two layers: 1. the core daemon zebra, which acts as an abstraction layer to the underlying Unix kernel and presents the Zserv API 2. the Zserv client ospfd, implementing OSPFv2 Beside the configuration by a config file, Quagga supports a vty console interface similar to Cisco IOS router. These interface can be reached by terminal connection to TCP Port 2601 for zebra and TCP Port 2604 for ospfd. On GW1 the appropriate config files shown below. /etc/quagga/zebra.conf
! hostname gw1-zebra password root enable password root log syslog ! line vty !

/etc/quagga/ospfd.conf
! hostname gw1-ospf password root enable password root log syslog ! router ospf network 10.1.1.0/24 area 0 network 10.0.0.0/24 area 0 ! line vty !

2005-06-20

-5-

Lipa Systemy www.lipasys.de

5 OSPF

The GW2 propagates accordingly the own local networks.

! hostname gw2-ospf password root enable password root log syslog ! ! router ospf network 10.2.2.0/24 area 0 network 10.0.0.0/24 area 0 ! line vty !

To start the OSPF process, type in a root shell

/etc/init.d/zebra start /etc/init.d/ospfd start

By using the vty interface, it is possible to display the status and routing data of the OSPF daemon. The easiest way is to connect with a telnet client to the corresponding TCP Port.
telnet localhost 2604 gw1-ospf> sh ip ospf neighbour gw1-ospf> sh ip ospf route

2005-06-20

-6-

Lipa Systemy www.lipasys.de