X

Best Practices from Oracle Development's A‑Team

BGP using Quagga over IPSEC

Catalin Andrei
Cloud Networking Solutions Architect

In the world, today the Internet can’t function without self-adapting networks. I am talking about the routing decisions that now are made by protocols and everything is changed dynamically. Remember the days when everything was static? Well, I do… hundreds of static routes configured on each server and again on each router. It was a nightmare to add something to the network.

Now think about the same in the IPSEC context: I know few customers who are not willing to route 0.0.0.0/0 to a vpn tunnel, so in this scenario maintaining static route entries for hundreds of subnets will be a challenge.

In order to make this self-adapting, a routing protocol is used. From the routing protocols list, one stands out: BGP. It is very flexible and it works on unicast.

BGP is the protocol of choice in the cloud providers because multicast and broadcast are not supported by them.

 

In this article, I will focus on getting the BGP working on a Linux VM that is using Libreswan for connecting to the DRG in OCI. The VM provisioning and the configuration of the Libreswan are not in the scope of this article. For more information on how to build a VPN connection between Libreswan and OCI you can follow the official documentation:

https://docs.cloud.oracle.com/iaas/Content/Network/Concepts/libreswan.htm

 

A prerequisite for going further is a functional IPSEC tunnel.

The topology that I will create is depicted in the following picture:

 

Install Quagga. I used a VM with OEL7:

yum install quagga

Modify the libreswan config in order to add an IP address to the vti:

 rightvti=10.10.10.1/30

The config for the tunnel looks like this:

config setup
    plutoopts="--perpeerlog"
    protostack=auto
conn oracle-tunnel-1
     keyexchange=ike
     pfs=yes
     ikev2=no
     ike=aes256-sha2_384;modp1536
     phase2alg=aes256-sha1;modp1536
     left=129.213.7.53
     right=192.168.12.4
     rightid=192.168.12.4
     authby=secret
     leftsubnet=0.0.0.0/0
     rightsubnet=0.0.0.0/0
     ikelifetime=28800
     salifetime=3600
     auto=start
     mark=5/0xffffff # Needs to be unique across all tunnels
     vti-interface=vti1
     vti-routing=no
     rightvti=10.10.10.1/30
     encapsulation=yes

Edit the zebra configuration:

zebra.conf
!
! Zebra configuration saved from vty
!   2019/07/30 13:18:58
!
hostname caandrei-vpn2-fra
password zebra
enable password zebra
log file /var/log/quagga/quagga.log
!
interface ens3
 ipv6 nd suppress-ra
!
interface ens5
 ipv6 nd suppress-ra
!
interface ip_vti0
 ipv6 nd suppress-ra
!
interface lo
!
interface vti1
 ip address 10.10.10.1/30
 ipv6 nd suppress-ra
!
interface vti2
 ipv6 nd suppress-ra
!
ip forwarding
!
!
line vty
!

Modify the bgpd config:

[root@caandrei-vpn2-fra quagga]# cat bgpd.conf
hostname caandrei-vpn2-fra
password zebra
enable password zebra1
router bgp 64555
 bgp router-id 10.10.10.1
 network 10.10.1.0/24
 neighbor 10.10.10.2 remote-as 31898
 neighbor 10.10.10.2 ebgp-multihop
 neighbor 10.10.10.2 next-hop-self
 
log file bgpd.log
log stdout

Enable service and start it for zebra and bgpd:

systemctl start zebra
systemctl enable zebra
systemctl start bgpd
systemctl enable bgpd

Restart the ipsec service:

service ipsec restart

Navigate to the OCI web Console and open the ipsec tunnel page that you created in the beginning and edit the tunnel. You will change the configuration from static routing to BGP and add the ASN and the ip addresses:

 

After a while it will look like this:

From libreswan ping the other side of the tunnel:

Enter in the vtysh and see the bgp summary:

It can the observed that the bgp adjacency is UP and bellow you can see the routes:

 

 

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha