BGP multipath load sharing on Vyatta

The BGP Multipath Load Sharing for eBGP and iBGP feature allows you to configure multipath load balancing with both external BGP (eBGP) and internal BGP (iBGP) paths.

Vyatta OS supports both iBGP and eBGP Multipath.

Regarding the load sharing, traffic load is shared across them on a per session basis. That is, each new session is routed across the path that has the fewest active sessions. To achieve this, the route is advertised with the nexthop address being the interface address rather than the address of the best path. Once traffic is routed to the interface, it can select the path based on current traffic loads.

FYI: The behavior for Cisco IOS device for BGP multipath:

Load balancing over the multi BGP paths is performed by CEF. CEF load balancing is configured on a per-packet round robin or on a per session (source and destination pair) basis. The default load balancing mode of CEF is per-destination.

Remote OpenVPN on Softlayer Vyatta

OpenVPN is an advanced open source VPN solution backed by ‘OpenVPN technologies’ and which is now the de-facto standard in the open source networking space. Uses the proven SSL/TLS encryption protocol.

Today, i will show you how to configure remote OpenVPN on Softlayer Vyatta gateway. This will give you secure access to your computing resource on Softlayer from anywhere on any device (Android, iphone, ipad, PC) at any time.

 

The configuration is quite straightforward. Below is configuration example of OpenVPN.

In this configuration,

1. OpenVPN client will be allocated one IP from subnet 192.168.100.0/24 and will use OpenVPN as their new default gateway;

2. NATing is used to provide the Internet connectivity for OpenVPN clients.

3. Certificate based authentication is used

4. OpenVPN is listening to TCP port 443. (Yes, same port as SSL/TLS)

set interfaces openvpn vtun0 local-port ‘443’

set interfaces openvpn vtun0 mode ‘server’

set interfaces openvpn vtun0 protocol ‘tcp-passive’

set interfaces openvpn vtun0 ‘replace-default-route’

set interfaces openvpn vtun0 server name-server ‘8.8.8.8’

set interfaces openvpn vtun0 server subnet ‘192.168.100.0/24’

set interfaces openvpn vtun0 server topology ‘subnet’

set interfaces openvpn vtun0 tls ca-cert-file ‘/config/auth/ca.crt’

set interfaces openvpn vtun0 tls cert-file ‘/config/auth/longbowkey.crt’

set interfaces openvpn vtun0 tls crl-file ‘/config/auth/ca_crl.pem’

set interfaces openvpn vtun0 tls dh-file ‘/config/auth/dh1024.pem’

set interfaces openvpn vtun0 tls key-file ‘/config/auth/longbowkey.key’

set nat source rule 10 outbound-interface ‘eth1’

set nat source rule 10 source address ‘192.168.100.0/24’

set nat source rule 10 translation address ‘masquerade’

Client end Softlayer recommendation:

iphone and ipad users: OpenVPN

Android: OpenVPN for Android (I recommend this software due to its richer configuration options)

OpenVPN for Android

If you are not really comfortable about PKI (CA, private key, certificate), you can use username/password for authentication.

BTW X Certifcate and Key Management is a good start point if you want to learn and have handson expereience about PKI. http://sourceforge.net/projects/xca/

X Certifcate and Key Management

Change the default syslog setting on Vyatta

By default, the logging information generated by Vyatta will be written to the main log file on Vyatta. Vyatta uses standard UNIX log rotation to prevent the file system from filling up with log files. When log messages are written to a file, the system will write up to 500 KB of log messages into the log file, where the log file is either the main log file or a name you have assigned to a user-defined file. When logfile reaches its maximum size, the system closes it and save as an archive file. The archive file is named message.x.The system archives log files in this way until a maximum number of log files exists.

By default, the maximum number of archived files is 5.The default setting won’t meet your requirement especially when you enables the firewall logging.

To change the above default setting, use the CLI below:

set system syslog global archive files ’30’

set system syslog global archive size ‘10000’

Here we change the log file maximum size to 10000KBytes and save up to 30 log files at Vyatta local disk. The above configuration will consume about 300Mbytes disk.

For Softlayer Vyatta gateway appliance, it offers 500G disk by default. Using 300M for logging files won’t bring any operation risk.

Of course, you should use central syslog system as much as possible.

set system syslog host 10.1.1.177 facility all level ‘warning’

Brocade SSL-VPN Client Bundler on Vyatta

In Brocade Vyatta version VSE6.7R6, Brocade introduce a new feature called SSL VPN Client Bundler. This SSL VPN feature is based on OpenVPN.

Brocade SSL-VPN Client Bundler enables the Vyatta system to generate image bundles that facilitate the setup of SSL-VPN client connections. Bundles include the up-to-date SSL-VPN client configuration that is required to connect to the server, including the required Transport Layer Security (TLS) certificate authority (CA) certificate that is used by the server.

The bundle can be found in the folder:

  • For Windows: /config/auth/vpn/ssl-vpn/client-bundle/vtunX/windows
  • For Linux: /config/auth/vpn/ssl-vpn/client-bundle/vtunX/linux

Note: vtunX is openVPN tunnel interface.

Today, i will show you how to make use of this feature on Softlayer Vyatta gateway step by step.

Step 0

Create the certificate for the SSL VPN using your CA and upload the CA certificate, DH file, SSL VPN certificate and private key to /config/auth/

vyatta@vyatta01:/config/auth$ ls -al

total 32

drwxrwsr-x 1 root   vyattacfg 4096 May 26 11:47 .

drwxrwsr-x 1 root   vyattacfg 4096 May 12 07:57 ..

-rw-r–r– 1 vyatta vyattacfg 1216 May 26 11:06 ca.crt

-rw-r–r– 1 vyatta vyattacfg  245 May 26 11:07 dh1024.pem

-rw-r–r– 1 vyatta vyattacfg 3885 May 26 11:46 sslvpn.crt

-rw-r–r– 1 vyatta vyattacfg  891 May 26 11:46 sslvpn.key

Step 1 (optional)

Service-User Web Portal allows end users to obtain the SSL-VPN client bundles by themselves. The portal is available by default from the following public-interface address of the Vyatta system:

https://<VyattaIP>/service

You can enable Service-User Web Portal the CLI below:

vyatta@vyatta01# set services https service-user

Of course you can distribute the bundle to your end users if you prefer to do that. In this case, you don’t need to enable this Service-User Web Portal.

Step 2: Generate the Client Bundle.

In our configuration exampe, we use the following parameters for our VPN configuration:

Hash: sha256

Encryption: aes128

Transport protocol: TCP

Transport port: 8443

SSL VPN Client IP: 172.16.10.0/24

We create the client bundle for windows, linux systems plus generic (this generic option will only create an OVPN file for you. You have to get the client by youself.)

set interfaces openvpn vtun10 client-bundle ‘generic’

set interfaces openvpn vtun10 client-bundle ‘linux’

set interfaces openvpn vtun10 client-bundle ‘windows’

set interfaces openvpn vtun10 ‘client-cert-not-required’

set interfaces openvpn vtun10 description ‘SSLVPN-test’

set interfaces openvpn vtun10 encryption ‘aes128’

set interfaces openvpn vtun10 hash ‘sha256’

set interfaces openvpn vtun10 local-host ‘x.x.x.x’

set interfaces openvpn vtun10 local-port ‘8443’

set interfaces openvpn vtun10 mode ‘server’

set interfaces openvpn vtun10 protocol ‘tcp-passive’

set interfaces openvpn vtun10 server subnet ‘172.16.10.0/24’

set interfaces openvpn vtun10 tls ca-cert-file ‘/config/auth/ca.crt’

set interfaces openvpn vtun10 tls cert-file ‘/config/auth/sslvpn.crt’

set interfaces openvpn vtun10 tls dh-file ‘/config/auth/dh1024.pem’

set interfaces openvpn vtun10 tls key-file ‘/config/auth/sslvpn.key’

Note: The client-cert-not-required variable must be set to allow SSL-VPN clients to connect using username and password without a TLS client certificate that is specific to an end user. Even if client certificates were created, they are not included in any SSL-VPN client bundles.

Step 3: Define SSL VPN users

Here I define a user call jojo

set resources service-users local user jojo auth plaintext-password xxxxxx

Step 4: Associate the user with the OpenVPN

set interfaces openvpn vtun10 auth local user ‘jojo’

Now you are able to begin to get your SSL VPN bundle and use SSL VPN.laugh

You can go to the Service-User Web Portal (https://vyattaip/service).  Login in the service-User Web Portal with your username and password

sslbundle1

Download your bundle: here click windows in the download tab.

sslbundle2

After the download is completed, accept the Securtiy warning and run the app

sslbundle3

Install SSL VPN client (next then next)

sslbundle4

After the client installtion is finised, Open SSL VPN client and type in your username/password

sslbundle5

After youclick OK, you will be connected to the SSL VPN in a few of seconds like the below.

sslbundle7

You can check the SSL VPN log of your SSL connection if you see any issue.

sslbundle6

Intermittent IPSEC tunnel connectivity issues on Vyatta

I just experienced an Intermittent IPSEC tunnel connectivity issues on Vyatta. Customer suggested they intermittently lose the connectivity to their Softlayer VMs via IPSec between their corporate VPN gateway and Softlayer Vyatta gateway.

Finally, I found out the issue is due to a Vyatta underlying Linux OS Debian system kernel network setting:xfrm4_gc_thresh.

The xfrm_gc_thresh controls the size of the IPSEC connection routing table which contains a list of the source and target systems. When the thresh value is reached the table is cleaned up very aggressively which inadvertently removes information related to active connections containing the Syn. Since the Syn entry for the active location can no longer be found the second part of the tcp handshake which contains the Syn-Ack ( Syn,Ack) response is silently drop.

On Vyatta OS version 6.7, the vaule of xfrm4_gc_thresh is set too low:1024, which bring intermittent IPSEC tunnel connectivity issues to customer if customer has a “big number” of sessions (like a few of hundred sessions. I know it is not big number at all). You can verify your system setting by using CLI:

vyatta@vyatta:~$ cat /proc/sys/net/ipv4/xfrm4_gc_thresh
1024

In addition, you can use CLI below to verify if you are experiencing this issue or not.
vyatta@vyatta:~$ cat /proc/net/xfrm_stat | grep BundleGen
XfrmOutBundleGenError 164671

Increasing the size of this threshold means that active connections will no longer be removed from the IPSEC connection routing table when the xfrm4_gc_thresh value is reached.

Recommended value for xfrm4_gc_thresh is 32768.

To fix the issue on the fly, you can do the following on Vyatta gateway:

sudo sysctl -w net.ipv4.xfrm4_gc_thresh=32768
sudo sysctl -p

The above change to the kernel network setting will lost after next reboot. To avoid that, you need to add the setting “net.ipv4.xfrm4_gc_thresh=32768” into /etc/sysctl.conf.

Note: the above issue is confirmed as Vyatta firmware bug by Brocade and will be fixed in the upcoming release 6.7R9.

In addition, another symptom for the issue is as below:

vyatta@vyatta:~$ ping 10.2.128.81
connect: No buffer space available

Update:

Version 6.7R9 has been released by Brocade. The bug is fixed in this version.

Version:      VSE6.7R9
Description:  Brocade Vyatta 5415 vRouter 6.7 R9
Copyright:    2006-2015 Vyatta, Inc.
Last login: Fri Oct  2 14:17:02 2015 from 60-242-58-167.static.tpgi.com.au
vyatta@vyatta:~$  cat /proc/sys/net/ipv4/xfrm4_gc_thresh
32768

Vyatta Gateway contextualization and customization

Vyatta gateway has provided a lot of cool network features but sometimes the default behaviour of Vyatta gateway do bring troubles in specific scenario.
One real world example is about IPSec. On Vyatta gateway, IPSec function is offered by strongSwan. StrongSwan IPSec implementation will place a priority route which destination is the IPSec remote-prefix into Vyatta’s kernel. This priority route will take precedence over all existing routes so long as the destination is covered by the IPSec remote-prefix. In simple word, this means all traffic covered by remote-prefix will send out via IPSec tunnel although you have more specific route defined in routing table. This behaviour is different from Cisco or Juniper router. However, you will see some unpleasant result when you (sometimes have to) define your IPSec remote-prefix as 0.0.0.0/0: all your traffic are sent to IPSec tunnel no matter what kind of routes you have configured in Vyatta routing table.

 

Some very smart guys have worked out a workaround to change Vyatta’s default behaviour by manually updating the Vyatta IPsec.conf file (/etc/ipsec.conf).  But the customized version of ipsec.conf will be replaced by system auto-generated ipsec.conf once the Vyatta is rebooted.
To overcome the gap, we need to perform Vyatta gateway contextualization or customization. After some research, I find the contextualization or customization can be achieved by a script “vyatta-postconfig-bootup.script” under directory /config/script/.

 

vyatta@vyatta:/config/scripts$ more vyatta-postconfig-bootup.script
#!/bin/sh
# This script is called from /etc/rc.local on boot after the Vyatta
# configuration is fully applied. Any modifications done to work around
# unfixed bugs and implement enhancements which are not complete in the Vyatta
# system can be placed here.

As the script description suggests it will be called when Vyatta is booted.
I write down a very simple script to overwrite the system auto-generated ipsec.conf file with customized ipsec.conf and restart the IPSec process to apply the new ipsec.conf. Then vyatta-postconfig-bootup.script is set to call the new script so that customized ipsec.conf will be kept after each reboot.

vyatta@vyatta:/config/scripts$ more runafterreboot
cp /etc/ipsec.conf.bak /etc/ipsec.conf
/etc/init.d/ipsec restart

vyatta@vyatta:/config/scripts$ more vyatta-postconfig-bootup.script
#!/bin/sh
# This script is called from /etc/rc.local on boot after the Vyatta
# configuration is fully applied. Any modifications done to work around
# unfixed bugs and implement enhancements which are not complete in the Vyatta
# system can be placed here.
/config/scripts/runafterreboot

 

We test the above solution and it works well. laugh

Vyatta Gateway OpenVPN troubleshooting

Recently we had an intermittent issue with remote OpenVPN. OpenVPN end user complains that they can’t connect to OpenVPN after works well for over a month.

In the system log, we see the below:

Sep 25 13:20:36 vy01 openvpn[25550]: pam_sss(vyatta-openvpn-vtun10.conf:auth): Request to sssd failed. Bad address
Sep 25 13:20:36 vy01 openvpn-vtun10[25557]: 20x.8x.x8.30:56383 PLUGIN_CALL: POST /usr/lib/openvpn/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=1
Sep 25 13:20:36 vy01 openvpn-vtun10[25557]: 20x.8x.x8.30:56383 PLUGIN_CALL: plugin function PLUGIN_AUTH_USER_PASS_VERIFY failed with status 1: /usr/lib/openvpn/openvpn-plugin-auth-pam.so
Sep 25 13:20:36 vy01 openvpn-vtun10[25557]: 20x.8x.x8.30:56383 TLS Auth Error: Auth Username/Password verification failed for peer 

From this log, we can see authentication failure related to SSSD.

We check the status of SSSD and found the service is still running:

vyatta@vy01:~$ sudo service sssd status
sssd is running.

We tried to restart the SSSD service. After restart, issue is fixed.

vyatta@y01:~$ sudo service sssd restart

SSSD stands for System Security Services Daemon. The System Security Services Daemon (SSSD) provides access to different identity and authentication providers.Most system authentication is configured locally, which means that services must check with a local user store to determine users and credentials. What SSSD does is allow a local service to check with a local cache in SSSD, but that cache may be taken from any variety of remote identity providers — an LDAP directory, an Identity Management domain, Active Directory, possibly even a Kerberos realm.SSSD also caches those users and credentials, so if the local system or the identity provider go offline, the user credentials are still available to services to verify.

We are checking with Brocade to verify if the SSSD issue is firmware bug or not. BTW, our Vyatta gateway version is 6.7R7.

How to remotely SSH in Vyatta with root account

When you order a Vyatta gateway appliance from Softlayer, you will see two accounts are created as Vyatta admin in Softlayer customer portal and on the device as well.

The first account is vyatta and the other account is “root” account. Both accounts are admin-level account.

By default, you can’t use root account to remotely SSH in Vyatta gateway. Most of time, it is recommended not to use root account to log in Vyatta gateway due to security concern. However, sometimes you do need to use root account to remotely SSH in Vyatta when you have no console access to the Vyatta gateway.

So how you can change the default behavior to SSH in Vyatta remotely?

It is quite easy!cheeky

Step 0: Backup the sshd_config file under the directory /etc/ssh

cp sshd_config sshd_config.bak

Step 1: change the setting as below in sshd_config file to allow root account remotely log in.

Change: PermitRootLogin no

To: PermitRootLogin yes

Step 2: Restart the SSH dameon

sudo /etc/init.d/ssh restart

Then you can SSH in your Vyatta gateway remotely.

Note: Please perform security risk assessment when you allow root account to SSH in Vyatta remotely. Possibly extra access controls (e.g. only allow specific IPs) need to be in place as risk mitigation.

HA IPSec VPN with VRRP on Vyatta

Vyatta provides the capability to maintain connectivity through one IPsec tunnel by using a pair of Vyatta routers with VRRP. When one Vyatta router fails or is brought down for maintenance, the new VRRP master Vyatta router restores IPsec connectivity between the local and remote networks.

Here I will show you how to configure the Vyatta to provide HA IPSec VPN with VRRP.
The main difference of HA IPSec VPN from the standard IPSec VPN configuration is in the two scripts (ipsec-restart  and ipsec-stop) on Vyatta.The two scripts are in the directory of “/config/scripts”, which are included in the Vyatta firmware.

vyatta@vyatta:/config/scripts$ ls
ipsec-restart  ipsec-stop  vyatta-postconfig-bootup.script

vyatta@vyatta:/config/scripts$ more ipsec-restart 
#!/bin/bash
/etc/init.d/ipsec restart | logger -p info -t $(/usr/bin/basename $0)

vyatta@cvyatta:/config/scripts$ more ipsec-stop
#!/bin/bash
/etc/init.d/ipsec stop | logger -p info -t $(/usr/bin/basename $0)

The ipsec-restart script is to reinitializes the IPsec daemon.

The ipsec-stop scripts is to stop IPSec daemon so that It prevent a Vyatta router from initiating tunnels unless and until it has been elected the VRRP master.

Below is an example of HA IPSec configuration.

Vyatta 1——-VRRP master  Vyatta 2——-VRRP backup                                                      
vyatta@vyatta1:~$ show configuration commands
set interfaces ethernet eth0 address ‘192.168.107.111/24’
set interfaces ethernet eth0 duplex ‘auto’
set interfaces ethernet eth0 hw-id ’00:0c:29:71:68:06′
set interfaces ethernet eth0 smp_affinity ‘auto’
set interfaces ethernet eth0 speed ‘auto’
set interfaces ethernet eth0 vrrp vrrp-group 1 advertise-interval ‘1’
set interfaces ethernet eth0 vrrp vrrp-group 1 preempt ‘false’
set interfaces ethernet eth0 vrrp vrrp-group 1 priority ‘254’
set interfaces ethernet eth0 vrrp vrrp-group 1 run-transition-scripts backup ‘/config/scripts/ipsec-stop’
set interfaces ethernet eth0 vrrp vrrp-group 1 run-transition-scripts fault ‘/config/scripts/ipsec-stop’
set interfaces ethernet eth0 vrrp vrrp-group 1 run-transition-scripts master ‘/config/scripts/ipsec-restart’

set interfaces ethernet eth0 vrrp vrrp-group 1 sync-group ‘vgroup1’
set interfaces ethernet eth0 vrrp vrrp-group 1 virtual-address ‘192.168.107.100/24’
set interfaces ethernet eth1 address ‘192.168.174.111/24’
set interfaces ethernet eth1 duplex ‘auto’
set interfaces ethernet eth1 hw-id ’00:0c:29:71:68:10′
set interfaces ethernet eth1 smp_affinity ‘auto’
set interfaces ethernet eth1 speed ‘auto’
set interfaces ethernet eth1 vrrp vrrp-group 1 advertise-interval ‘1’
set interfaces ethernet eth1 vrrp vrrp-group 1 preempt ‘false’
set interfaces ethernet eth1 vrrp vrrp-group 1 priority ‘254’
set interfaces ethernet eth1 vrrp vrrp-group 1 sync-group ‘vgroup1’
set interfaces ethernet eth1 vrrp vrrp-group 1 virtual-address ‘192.168.174.100/24’
set service https http-redirect ‘enable’
set service ssh port ’22’
set system config-sync remote-router 192.168.174.111 password ‘vyatta’
set system config-sync remote-router 192.168.174.111 sync-map ‘SYNC’
set system config-sync remote-router 192.168.174.111 username ‘vyatta’
set system config-sync remote-router 192.168.174.222 password ‘vyatta’
set system config-sync remote-router 192.168.174.222 sync-map ‘SYNC’
set system config-sync remote-router 192.168.174.222 username ‘vyatta’
set system config-sync sync-map SYNC rule 1 action ‘include’
set system config-sync sync-map SYNC rule 1 location ‘nat’
set system config-sync sync-map SYNC rule 2 action ‘include’
set system config-sync sync-map SYNC rule 2 location ‘firewall’
set system config-sync sync-map SYNC rule 3 action ‘include’
set system config-sync sync-map SYNC rule 3 location ‘vpn’
set system gateway-address ‘192.168.107.17’
set system host-name ‘vyatta1’
set system login user root authentication encrypted-password ‘$1$NiudjUdJ$Zf7AFBBiIdHrpczGE2tuQ/’
set system login user root authentication plaintext-password ”
set system login user root level ‘admin’
set system login user vyatta authentication encrypted-password ‘$1$A/.ZAqyP$uymrdYkk8uBU.kBFMb5F6.’
set system login user vyatta level ‘admin’
set system syslog global facility all level ‘notice’
set system syslog global facility protocols level ‘debug’
set system syslog user all facility all level ’emerg’
set system time-zone ‘Australia/Sydney’
set vpn ipsec esp-group ESP-1W compression ‘disable’
set vpn ipsec esp-group ESP-1W lifetime ‘3600’
set vpn ipsec esp-group ESP-1W mode ‘tunnel’
set vpn ipsec esp-group ESP-1W pfs ‘disable’
set vpn ipsec esp-group ESP-1W proposal 1 encryption ‘aes256’
set vpn ipsec esp-group ESP-1W proposal 1 hash ‘sha1’
set vpn ipsec esp-group ESP-1W proposal 2 encryption ‘3des’
set vpn ipsec esp-group ESP-1W proposal 2 hash ‘md5’
set vpn ipsec ike-group IKE-1W lifetime ‘3600’
set vpn ipsec ike-group IKE-1W proposal 1 encryption ‘aes256’
set vpn ipsec ike-group IKE-1W proposal 1 hash ‘sha1’
set vpn ipsec ike-group IKE-1W proposal 2 encryption ‘aes128’
set vpn ipsec ike-group IKE-1W proposal 2 hash ‘sha1’
set vpn ipsec ipsec-interfaces interface ‘eth0v1’
set vpn ipsec site-to-site peer 192.168.107.17 authentication mode ‘pre-shared-secret’
set vpn ipsec site-to-site peer 192.168.107.17 authentication pre-shared-secret ‘vyatta’
set vpn ipsec site-to-site peer 192.168.107.17 connection-type ‘initiate’
set vpn ipsec site-to-site peer 192.168.107.17 default-esp-group ‘ESP-1W’
set vpn ipsec site-to-site peer 192.168.107.17 ike-group ‘IKE-1W’
set vpn ipsec site-to-site peer 192.168.107.17 local-address ‘192.168.107.100’
set vpn ipsec site-to-site peer 192.168.107.17 tunnel 1 allow-nat-networks ‘disable’
set vpn ipsec site-to-site peer 192.168.107.17 tunnel 1 allow-public-networks ‘disable’
set vpn ipsec site-to-site peer 192.168.107.17 tunnel 1 local prefix ‘192.168.174.0/24’
set vpn ipsec site-to-site peer 192.168.107.17 tunnel 1 remote prefix ‘192.168.217.0/24’
vyatta@vyatta2:~$ show configuration commands
set interfaces ethernet eth0 address ‘192.168.107.222/24’
set interfaces ethernet eth0 duplex ‘auto’
set interfaces ethernet eth0 hw-id ’00:0c:29:1f:a0:4e’
set interfaces ethernet eth0 smp_affinity ‘auto’
set interfaces ethernet eth0 speed ‘auto’
set interfaces ethernet eth0 vrrp vrrp-group 1 advertise-interval ‘1’
set interfaces ethernet eth0 vrrp vrrp-group 1 preempt ‘false’

set interfaces ethernet eth0 vrrp vrrp-group 1 run-transition-scripts backup ‘/config/scripts/ipsec-stop’
set interfaces ethernet eth0 vrrp vrrp-group 1 run-transition-scripts fault ‘/config/scripts/ipsec-stop’
set interfaces ethernet eth0 vrrp vrrp-group 1 run-transition-scripts master ‘/config/scripts/ipsec-restart’

set interfaces ethernet eth0 vrrp vrrp-group 1 sync-group ‘vgroup1’
set interfaces ethernet eth0 vrrp vrrp-group 1 virtual-address ‘192.168.107.100/24’
set interfaces ethernet eth1 address ‘192.168.174.222/24’
set interfaces ethernet eth1 duplex ‘auto’
set interfaces ethernet eth1 hw-id ’00:0c:29:1f:a0:58′
set interfaces ethernet eth1 smp_affinity ‘auto’
set interfaces ethernet eth1 speed ‘auto’
set interfaces ethernet eth1 vrrp vrrp-group 1 advertise-interval ‘1’
set interfaces ethernet eth1 vrrp vrrp-group 1 preempt ‘false’

set interfaces ethernet eth1 vrrp vrrp-group 1 sync-group ‘vgroup1’
set interfaces ethernet eth1 vrrp vrrp-group 1 virtual-address ‘192.168.174.100/24’
set service https http-redirect ‘enable’
set service ssh port ’22’
set system config-sync remote-router 192.168.174.111 password ‘vyatta’
set system config-sync remote-router 192.168.174.111 sync-map ‘SYNC’
set system config-sync remote-router 192.168.174.111 username ‘vyatta’
set system config-sync remote-router 192.168.174.222 password ‘vyatta’
set system config-sync remote-router 192.168.174.222 sync-map ‘SYNC’
set system config-sync remote-router 192.168.174.222 username ‘vyatta’
set system config-sync sync-map SYNC rule 1 action ‘include’
set system config-sync sync-map SYNC rule 1 location ‘nat’
set system config-sync sync-map SYNC rule 2 action ‘include’
set system config-sync sync-map SYNC rule 2 location ‘firewall’
set system config-sync sync-map SYNC rule 3 action ‘include’
set system config-sync sync-map SYNC rule 3 location ‘vpn’
set system gateway-address ‘192.168.107.17’
set system host-name ‘vyatta2’
set system login user root authentication encrypted-password ‘$1$OR3t3Q8v$6CPPvERQ.UTsReP08zDWz0’
set system login user root authentication plaintext-password ”
set system login user root level ‘admin’
set system login user vyatta authentication encrypted-password ‘$1$WRNtOH8I$ZNGhjj20oEbDtF/cZcd4r1’
set system login user vyatta level ‘admin’
set system syslog global facility all level ‘notice’
set system syslog global facility protocols level ‘debug’
set system syslog user all facility all level ’emerg’
set system time-zone ‘Australia/Sydney’
set vpn ipsec esp-group ESP-1W compression ‘disable’
set vpn ipsec esp-group ESP-1W lifetime ‘3600’
set vpn ipsec esp-group ESP-1W mode ‘tunnel’
set vpn ipsec esp-group ESP-1W pfs ‘disable’
set vpn ipsec esp-group ESP-1W proposal 1 encryption ‘aes256’
set vpn ipsec esp-group ESP-1W proposal 1 hash ‘sha1’
set vpn ipsec esp-group ESP-1W proposal 2 encryption ‘3des’
set vpn ipsec esp-group ESP-1W proposal 2 hash ‘md5’
set vpn ipsec ike-group IKE-1W lifetime ‘3600’
set vpn ipsec ike-group IKE-1W proposal 1 encryption ‘aes256’
set vpn ipsec ike-group IKE-1W proposal 1 hash ‘sha1’
set vpn ipsec ike-group IKE-1W proposal 2 encryption ‘aes128’
set vpn ipsec ike-group IKE-1W proposal 2 hash ‘sha1’
set vpn ipsec ipsec-interfaces interface ‘eth0v1’
set vpn ipsec site-to-site peer 192.168.107.17 authentication mode ‘pre-shared-secret’
set vpn ipsec site-to-site peer 192.168.107.17 authentication pre-shared-secret ‘vyatta’
set vpn ipsec site-to-site peer 192.168.107.17 connection-type ‘initiate’
set vpn ipsec site-to-site peer 192.168.107.17 default-esp-group ‘ESP-1W’
set vpn ipsec site-to-site peer 192.168.107.17 ike-group ‘IKE-1W’
set vpn ipsec site-to-site peer 192.168.107.17 local-address ‘192.168.107.100’
set vpn ipsec site-to-site peer 192.168.107.17 tunnel 1 allow-nat-networks ‘disable’
set vpn ipsec site-to-site peer 192.168.107.17 tunnel 1 allow-public-networks ‘disable’
set vpn ipsec site-to-site peer 192.168.107.17 tunnel 1 local prefix ‘192.168.174.0/24’
set vpn ipsec site-to-site peer 192.168.107.17 tunnel 1 remote prefix ‘192.168.217.0/24’

Verify VRRP and IPSec status

vyatta@vyatta1:~$ show vrrp
RFC        Addr   Last        Sync
Interface         Group  State   Compliant  Owner  Transition  Group
———         —–  —–   ———  —–  ———-  —–
eth0              1      MASTER  no         no     33m40s      vgroup1
eth1              1      MASTER  no         no     33m42s      vgroup1

vyatta@vyatta1:~$ show vpn ipsec sa
Peer ID / IP                            Local ID / IP
————                            ————-
192.168.107.17                          192.168.107.100

Tunnel  State  Bytes Out/In   Encrypt  Hash  NAT-T  A-Time  L-Time  Proto
——  —–  ————-  ——-  —-  —–  ——  ——  —–
1       up     0.0/0.0        aes256   sha1  no     2768    3600    all

 

vyatta@vyatta:~$ show vrrp
RFC        Addr   Last        Sync
Interface         Group  State   Compliant  Owner  Transition  Group
———         —–  —–   ———  —–  ———-  —–
eth0              1      BACKUP  no         no     12m2s       vgroup1
eth1              1      BACKUP  no         no     12m2s       vgroup1

vyatta@vyatta:~$ show vpn ipsec sa

Force VRRP master to backup

vyatta@vyatta1:~$ reset vrrp master interface eth0 group 1
vrrp group 1 on eth0 is in sync-group vgroup1
Forcing vyatta-eth1-1 to BACKUP…
Forcing vyatta-eth0-1 to BACKUP…

Verify VRRP and IPSec status

vyatta@vyatta1:~$ show vrrp
RFC        Addr   Last        Sync
Interface         Group  State   Compliant  Owner  Transition  Group
———         —–  —–   ———  —–  ———-  —–
eth0              1      BACKUP  no         no     26s         vgroup1
eth1              1      BACKUP  no         no     26s         vgroup1

vyatta@vyatta1:~$ show vpn ipsec sa

 

vyatta@vyatta:~$ show vrrp
RFC        Addr   Last        Sync
Interface         Group  State   Compliant  Owner  Transition  Group
———         —–  —–   ———  —–  ———-  —–
eth0              1      MASTER  no         no     48s         vgroup1
eth1              1      MASTER  no         no     49s         vgroup1

vyatta@vyatta:~$ show vpn ipsec sa
Peer ID / IP                            Local ID / IP
————                            ————-
192.168.107.17                          192.168.107.100

Tunnel  State  Bytes Out/In   Encrypt  Hash  NAT-T  A-Time  L-Time  Proto
——  —–  ————-  ——-  —-  —–  ——  ——  —–
1       up     0.0/0.0        aes256   sha1  no     805     3600    all

Brocade Vyatta 5600 Performance

Most of Cloud Service Providers including Softlayer are providing Vyatta 5400 in their VPC offering.

Brocade has new generation of Vyatta called Vyatta 5600. Brocade claims that this new generation Vyatta will be able to go past 100 Million Packets Per Second on standard COTS hardware.

This big performance improvement is achieved by architecture change of Vyatta OS.

Vyatta 5400 Architecture

5400

Vyatta 5600 Architecture

5600

Please refer the YouTube video below for more explanation.

https://www.youtube.com/watch?v=DTvnOCzsqg