Using TShark Filter for Packet Capture on Vyatta 5600

Vyatta 5600 provides Tshark as the packet capture tool. To capture your interested traffic and remove unnessary nosiy traffic, you need to use the capture filter when you perform the packet capture. Here I show you a few real world example for tshark capture filter, which hope can save you a bit of time.

  • Capture packet based on source or destination IP

tshark -f “host 10.42.131.120” -i dp0p224p1 -w /tmp/capture.pcap

  • Capture packets based on Protocol/Port

tshark -f “tcp port 1401” -i  dp0p224p1 -w /tmp/capture.pcap

tshark -f “udp port 53” -i  dp0p224p1 -w /tmp/capture.pcap

  • Capture packets based on IP and Protocol/Port

tshark -f “tcp port 1401 and host 10.15.72.34” -i  dp0p224p1 -w /tmp/capture.pcap

  • Capture packets based on multilpe IPs and Protocol/Port

tshark -f “tcp port 1401 and host 10.15.72.34 or host 10.15.72.36” -i  dp0p224p1 -w /tmp/capture.pcap

You can use tshark to read your packet capture:

  • tshark -r capture.pcap

Note1: dp0p224p1 is the interface on which we capture the traffic.

Note2: In some cases (GRE tunnel traffic, VXLAN traffic), the above filter possibly won’t really work for you as the filter can only apply the source/destination of tunnel IP.

Another way to control the size of capture file is stopping the packet capture when captures a specfici number of the packet.

  • Capture 50000 Packets and save them to a trace file called 1000test.pcap

tshark -c 50000  -i dp0p192p1 -w /tmp/1000test.pcap

or

tshark -f “host 10.42.131.120”  -c 50000  -i dp0p192p1 -w /tmp/1000test.pcap

Run scripts on Vyatta

Recently, I met an “issue” with running scripts on Vyatta.

In one of my Softlayer solutions, I define “backup” and “master” run-transition-scripts to control the routing path selection for HA when Vyatta change VRRP role from “master” to “backup” or “backup” to “master”

set interfaces ethernet eth1 vrrp vrrp-group 1 run-transition-scripts backup ‘/config/scripts/vrrpbackup’ 

set interfaces ethernet eth1 vrrp vrrp-group 1 run-transition-scripts master ‘/config/scripts/vrrpmaster’

The backup and master scripts work as expected.

However, after the above configuration, i found i cant  change the Vyatta configuration any more even after reboot/power off and on.

vyatta@ha1# set system host-name ha

Set failed

[edit]

vyatta@ha1# 

vyatta@ha1# delete interfaces ethernet eth1 vrrp vrrp-group 1

Failed to delete specified config path

Delete failed

[edit]

vyatta@ha1# set protocols bgp 100 neighbor 172.16.100.2 remote-as 103

Set failed

[edit]

vyatta@ha1# set firewall name vyattafire

[edit]

vyatta@ha1# commit

Aborted

[edit]

vyatta@ha1# discard 

Discard failed

[edit] 

In addition, I tried to restore to factory default but no lucky either. The error message suggest something is wrong at line 47 but i cant see line 47 in the config.boot.default

vyatta@ha1# load /opt/vyatta/etc/config.boot.default

Loading configuration from ‘/config.boot.default’…

Invalid config file (syntax error): error at line 47, text []

Failed to parse specified config file

No configuration changes to commit

[edit] 

vyatta@ha1# cat -n /opt/vyatta/etc/config.boot.default

  1  system {

  2      login {

  3          user vyatta {

  4              authentication {

  5                  encrypted-password “$1$4XHPj9eT$G3ww9B/pYDLSXC8YVvazP0”

  6              }

  7          }

  8      }

  9      syslog {

 10          global {

 11              facility all {

 12                  level notice

 13              }

 14              facility protocols {

 15                  level debug

 16              }

 17          }

 18          user all {

 19              facility all {

 20                  level emerg

 21          }

 22      }

 23      ntp {

 24          server “0.vyatta.pool.ntp.org”

 25          server “1.vyatta.pool.ntp.org”

 26          server “2.vyatta.pool.ntp.org”

 27      }

 28      console {

 29          device ttyS0 {

 30              speed 9600

 31          }

 32      }

 33      config-management {

 34          commit-revisions 20

 35      }

 36  }

 37

 38  interfaces {

 39      loopback lo {

 40      }

 41  }

 42

 43

 44  /* Warning: Do not remove the following line. */

 45  /* === vyatta-config-version: “zone-policy@1:ipsec@4:config-management@1:wanloadbalance@3:dhcp-relay@1:nat@4:quagga@3:qos@1:entitlement@1:pim@1:conntrack@1:conntrack-sync@1:system@7:vrrp@1:firewall@5:webgui@1:dhcp-server@4″ === */

46  /* Release version: VSE6.7R5S1 */

I spent 10+ hours to dig into the “issue”. Finally, I found the below:

It looks like that Vyatta uses “root” account to run scripts although I use “vyatta” account to do my entire configuration.  Once the scripts are implemented and change the Vyatta active configuration, the Vyatta configuration will be locked by the “root” account.

Although the “vyatta” is admin level user which is same as the “root”, the “vyatta” account will be locked out of the active configuration until after a reboot. This is the reason why I cant perform any configuration change after the scripts is implemented.

set system login user root level ‘admin’

set system login user vyatta level ‘admin’

In addition, my scripts will run immediately once the Vyatta is powered on.  So the “vyatta” account will always be locked out of the configuration even after reboot.

The work around/solution which I just found is:

Log in the Vyatta OS CLI by “root” account and perform & commit another change. After that “unlock”, the “vyatta” account will be able to edit the vyatta configuration again.

I have not seen any vyatta doc which talks about my finding. I reported this usability issue to Brocade and hope they can fix this asap.

Update: looks like that the issue is still there in version 6.7 R9

One of my colleague suggest another fix:

Hey. Had a similar problem and found out it’s a problem with the permissions. This solved the issue for me.
sudo chown -R root:vyattacfg /opt/vyatta/config/active/

(what it does, is it changes the owner of the active configuration. With that, it probably resets the permissions to the files and therefore works around the bug that prevents “vyatta” user to do changes)

eBGP running over GRE on Brocade Vyatta OS

On Softlayer, Vyatta 6.x Subscription Edition (64 bit) is offered. This subscription version Vyatta OS is provided by Brocade.

The latest version of Brocade Vyatta OS is VSE6.7R5S1.

Today, I just met another “difference” between Vyatta OS and other traditional vendors like Cisco and Juniper. The difference is on eBGP over GRE tunnel.

Like Cisco and Juniper, eBGP session is established between two GRE end points on Vyatta OS.

Vvyatta@vyatta:~$ show ip bgp summary 

BGP router identifier 172.16.100.2, local AS number 103

BGP table version is 73

3 BGP AS-PATH entries

0 BGP community entries

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

172.16.100.1    4   100     143     141       73    0    0 00:52:33        0

172.16.100.5    4   100     148     147       73    0    0 01:11:53        0

However, i cant see any BGP routing in the routing table.

vyatta@vyatta:~$ show ip route 

Codes: K – kernel, C – connected, S – static, R – RIP, B – BGP

       O – OSPF, IA – OSPF inter area

       N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2

       E1 – OSPF external type 1, E2 – OSPF external type 2

       i – IS-IS, L1 – IS-IS level-1, L2 – IS-IS level-2, ia – IS-IS inter area

       > – selected route, * – FIB route, p – stale info

C    *> 10.1.1.0/24 is directly connected, eth0

C    *> 127.0.0.0/8 is directly connected, lo

C    *> 172.16.32.0/24 is directly connected, lo

C    *> 172.16.100.0/30 is directly connected, tun1

C    *> 172.16.100.4/30 is directly connected, tun2

C    *> 192.168.56.0/24 is directly connected, eth1

C    *> 192.168.100.0/24 is directly connected, lo

I can see the BGP routing has been advertised by remote BGP peer and received by the local BGP router.

vyatta@vyatta:~$ show ip bgp neighbors 172.16.100.5 received-routes 

BGP table version is 70, local router ID is 172.16.100.2

Status codes: s suppressed, d damped, h history, * valid, > best, i – internal

Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*> 172.16.31.0/24   172.16.100.5                           0 100 i

*> 192.168.107.0    172.16.100.5                           0 100 i

*> 192.168.108.0    172.16.100.5                           0 100 100 100 100 i

After performed a BGP debug, I see the below:

Mar  6 03:13:53 vyatta BGP[2472]: BGP: 172.16.100.1-Outgoing [RIB] Update: Prefix 172.16.31.0/24 denied due to non-connected next-hop;

Mar  6 03:13:53 vyatta BGP[2472]: BGP: 172.16.100.1-Outgoing [RIB] Update: Prefix 192.168.107.0/24 denied due to non-connected next-hop;

Interesting, Vyatta OS consider GRE tunnel as non-connected network which is different from Cisco/Juniper. More interestingly, the BGP neighbor session is allowed to be established but it denies the BGP routing injection.

Anyway, I add the following in my eBGP configuration. Then everything is OK! Job Done!

set protocols bgp 103 neighbor 172.16.100.1 ebgp-multihop ‘2’

set protocols bgp 103 neighbor 172.16.100.5 ebgp-multihop ‘2’

Tips: how to perform BGP debug on Vyatta

#monitor protocol bgp enable events 

#monitor protocol bgp enable updates

Update: Brocade just confirmed the above BGP issue which i met is a Bug. They will fix it ASAP.

OpenVPN on Vyatta Gateway

Have used IPSec VPN for 10+ yrs. Recently, I put OpenVPN into one customer’s Softlayer environment. OpenVPN looks quite nice to me: design and implementation is quite easy.

Here I show a site-to-site OpenVPN example.

As normal, topology first

openVPN

Step 1: create a PSK

generate openvpn key /config/auth/openvpn1.key

Make sure that the PSK in the proper folder: /config/auth/. If you put the key into different folder, you will see a warning message as below:

Warning: ‘openvpn1.key’ lies outside of /config/auth directory. It will not get preserved during image upgrade.

NOTE: you must make sure that the PSK is shared with your peering OpenVPN gateway securely.

 

Step 2: add the OpenVPN configuration. On Vyatta, OpenVPN is configured as OpenVPN tunnel interface. In my example, OpenVPN is configured as “vtunn0”

Vyatta-OpenVPN1

set interfaces openvpn vtun0 local-address ‘192.168.200.1’  

set interfaces openvpn vtun0 mode ‘site-to-site’

set interfaces openvpn vtun0 remote-address ‘192.168.200.2’

set interfaces openvpn vtun0 remote-host ‘192.168.100.2’

set interfaces openvpn vtun0 shared-secret-key-file ‘/config/auth/openvpn1.key’

 Vyatta-OpenVPN2

set interfaces openvpn vtun0 local-address ‘192.168.200.2’

set interfaces openvpn vtun0 mode ‘site-to-site’

set interfaces openvpn vtun0 remote-address ‘192.168.200.1’

set interfaces openvpn vtun0 remote-host ‘192.168.100.1’

set interfaces openvpn vtun0 shared-secret-key-file ‘/config/auth/openvpn1.key’

 

Step 3: add the static interface-route routing to use OpenVPN tunnel interface as next-hop

Vyatta-OpenVPN1

set protocols static interface-route 172.16.32.0/24 next-hop-interface ‘vtun0

 Vyatta-OpenVPN2

set protocols static interface-route 172.16.31.0/24 next-hop-interface ‘vtun0’

 

Quick test:

vyatta@openvpn2:/config/auth$ ping 172.16.31.1 interface 172.16.32.1

PING 172.16.31.1 (172.16.31.1) from 172.16.32.1 : 56(84) bytes of data.

64 bytes from 172.16.31.1: icmp_req=1 ttl=64 time=0.549 ms

64 bytes from 172.16.31.1: icmp_req=2 ttl=64 time=0.755 ms

^C

— 172.16.31.1 ping statistics —

2 packets transmitted, 2 received, 0% packet loss, time 1001ms

rtt min/avg/max/mdev = 0.549/0.652/0.755/0.103 ms

 

vyatta@openvpn2:/config/auth$ show openvpn site-to-site status 

OpenVPN client status on vtun0 [] 

 

Remote CN       Remote IP       Tunnel IP       TX byte RX byte Connected Since

————— ————— ————— ——- ——- ————————

None (PSK)      192.168.100.1   192.168.200.1    726.8K  726.7K N/A

 

You see the OpenVPN just works.

FYI: OpenVPN use UDP (port 1194) as transport protocol by default.

Vyatta VTI IPSec to Juniper SRX Firewall

Today, I will show how to build site to site IPSec VPN between Vyatta and Juniper SRX firewall by use of Vyatta Virtual tunnel interface.

Below is the network topology for our configuration. NOTE: we will use router-based VPN on Juniper SRX end.

Vyatta VTI IPSec

yatta Juniper SRX
Ethernet Interface

set interfaces ethernet eth0 address ‘192.168.107.88/24’

set interfaces ethernet eth1 address ‘10.1.1.53/24’

Ethernet Interface

set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.52/24

set interfaces ge-0/0/1 unit 0 family inet address 10.10.91.52/24

Virtual Tunnel Interface

set interfaces vti vti0 address ‘172.16.31.1/30’

Virtual Tunnel Interface

set interfaces st0 unit 0 family inet

set security zones security-zone vpn interfaces st0.0

IPSec

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 ‘enable’

set vpn ipsec esp-group ESP-1W proposal 1 encryption ‘3des’

set vpn ipsec esp-group ESP-1W proposal 1 hash ‘md5’

set vpn ipsec ike-group IKE-1W lifetime ‘14400’

set vpn ipsec ike-group IKE-1W proposal 1 dh-group ‘2’

set vpn ipsec ike-group IKE-1W proposal 1 encryption ‘3des’

set vpn ipsec ike-group IKE-1W proposal 1 hash ‘md5’

set vpn ipsec ipsec-interfaces interface ‘eth1’

set vpn ipsec site-to-site peer 10.1.1.52 authentication mode ‘pre-shared-secret’

set vpn ipsec site-to-site peer 10.1.1.52 authentication pre-shared-secret ‘test_key_1’

set vpn ipsec site-to-site peer 10.1.1.52 connection-type ‘initiate’

set vpn ipsec site-to-site peer 10.1.1.52 ike-group ‘IKE-1W’

set vpn ipsec site-to-site peer 10.1.1.52 local-address ‘10.1.1.53’

set vpn ipsec site-to-site peer 10.1.1.52 vti bind ‘vti0’

set vpn ipsec site-to-site peer 10.1.1.52 vti esp-group ‘ESP-1W’

IPSec

set security ike proposal ike-phase1-proposal authentication-method pre-shared-keys

set security ike proposal ike-phase1-proposal dh-group group2

set security ike proposal ike-phase1-proposal authentication-algorithm md5

set security ike proposal ike-phase1-proposal encryption-algorithm 3des-cbc

set security ike proposal ike-phase1-proposal lifetime-seconds 14400

set security ike policy sandpit-p1 mode main

set security ike policy sandpit-p1 proposals ike-phase1-proposal

set security ike policy sandpit-p1 pre-shared-key ascii-text “$9$uONO0EyMWxdwgX7F6AuEhevWLVY.PTzn/”

set security ike gateway VTI ike-policy sandpit-p1

set security ike gateway VTI address 10.1.1.53

set security ike gateway VTI external-interface ge-0/0/0.0

set security ipsec proposal ipsec-phase2-proposal authentication-algorithm hmac-md5-96

set security ipsec proposal ipsec-phase2-proposal encryption-algorithm 3des-cbc

set security ipsec policy ipsec-phase2-policy perfect-forward-secrecy keys group2

set security ipsec policy ipsec-phase2-policy proposals ipsec-phase2-proposal

set security ipsec vpn VTI bind-interface st0.0

set security ipsec vpn VTI ike gateway VTI

set security ipsec vpn VTI ike ipsec-policy ipsec-phase2-policy

Routing

set protocols static interface-route 10.10.91.0/24 next-hop-interface vti0

Routing

set routing-options static route 192.168.107.0/24 next-hop st0.0

IPSec Status

vyatta@vyatta:~$ show vpn ike sa

Peer ID / IP                            Local ID / IP

————                            ————-

10.1.1.52                               10.1.1.53

 

State  Encrypt  Hash  D-H Grp  NAT-T  A-Time  L-Time

—–  ——-  —-  ——-  —–  ——  ——

 

up     3des     md5   2        no     2042    14400

vyatta@vyatta:~$ show vpn ipsec sa detail

——————————————————————

Peer IP:                10.1.1.52

Peer ID:                10.1.1.52

Local IP:               10.1.1.53

Local ID:               10.1.1.53

NAT Traversal:          no

NAT Source Port:        n/a

NAT Dest Port:          n/a

Tunnel vti:

State:                  up

Inbound SPI:            c5ae54df

Outbound SPI:           b9222e

Encryption:             3des

Hash:                   md5

PFS Group:              <Phase1>

Local Net:              0.0.0.0/0

Local Protocol:         all

Local Port:             all

Remote Net:             0.0.0.0/0

Remote Protocol:        all

Remote Port:            all

Inbound Bytes:          0.0

Outbound Bytes:         0.0

Active Time (s):        1088

Lifetime (s):           3600

 

vyatta@vyatta:~$ show vpn ipsec sa statistics

Peer ID / IP                            Local ID / IP

————                            ————-

10.1.1.52                               10.1.1.53

 

Tunnel Dir Source Network               Destination Network          Bytes

—— — ————–               ——————-          —–

vti    in  0.0.0.0/0                    0.0.0.0/0                    2016

 

vti    out 0.0.0.0/0                    0.0.0.0/0                    2016

 

IPSec Status

root@srx2> show security ike sa

Index   State  Initiator cookie  Responder cookie  Mode           Remote Address

6447227 UP     8b6a396203c2986b  a9386fb0329d418a  Main           10.1.1.53

 

root@srx2> show security ipsec sa

Total active tunnels: 1

ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway

<131073 ESP:3des/md5  dde7cc0b 2694/ unlim   –   root 500   10.1.1.53

>131073 ESP:3des/md5  c4b99e4d 2694/ unlim   –   root 500   10.1.1.53

root@srx2> show security ipsec statistics

ESP Statistics:

Encrypted bytes:             1632

Decrypted bytes:             1120

Encrypted packets:             12

Decrypted packets:             12

AH Statistics:

Input bytes:                    0

Output bytes:                   0

Input packets:                  0

Output packets:                 0

Errors:

AH authentication failures: 0, Replay errors: 0

ESP authentication failures: 0, ESP decryption failures: 0

Bad headers: 0, Bad trailers: 0

root@srx2> show security ipsec security-associations detail | no-more

ID: 131073 Virtual-system: root, VPN Name: VTI

Local Gateway: 10.1.1.52, Remote Gateway: 10.1.1.53

Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)

Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)

Version: IKEv1

DF-bit: clear

Bind-interface: st0.0

Port: 500, Nego#: 1, Fail#: 0, Def-Del#: 0 Flag: 600a29

Tunnel Down Reason: SA not initiated

Direction: inbound, SPI: dde7cc0b, AUX-SPI: 0

, VPN Monitoring: –

Hard lifetime: Expires in 2609 seconds

Lifesize Remaining:  Unlimited

Soft lifetime: Expires in 2032 seconds

Mode: Tunnel(0 0), Type: dynamic, State: installed

Protocol: ESP, Authentication: hmac-md5-96, Encryption: 3des-cbc

Anti-replay service: counter-based enabled, Replay window size: 64

Direction: outbound, SPI: c4b99e4d, AUX-SPI: 0

, VPN Monitoring: –

Hard lifetime: Expires in 2609 seconds

Lifesize Remaining:  Unlimited

Soft lifetime: Expires in 2032 seconds

Mode: Tunnel(0 0), Type: dynamic, State: installed

Protocol: ESP, Authentication: hmac-md5-96, Encryption: 3des-cbc

Anti-replay service: counter-based enabled, Replay window size: 64

NOTE: VTI will show as “Admin Down A/D” before VPN is up.

vyatta@vyatta:~$    show interfaces

Codes: S – State, L – Link, u – Up, D – Down, A – Admin Down

Interface        IP Address                        S/L  Description

———        ———-                        —  ———–

eth1             10.1.1.53/24                      u/u

eth2             192.168.107.88/24                 u/u

lo               127.0.0.1/8                       u/u

::1/128

vti0             172.16.31.1/30                    A/D  

Vyatta VTI IPSec to Cisco IOS router

Today, I will show how to build site to site IPSec VPN between Vyatta and Cisco IOS router by use of Vyatta Virtual tunnel interface.

Below is the network topology for our configuration. NOTE: we will use VTI IPSec on Cisco IOS router.

Vyatta VTI IPSec Cisco IOS

Vyatta Cisco IOS Routter
Ethernet Interface

set interfaces ethernet eth0 address ‘192.168.107.88/24’

set interfaces ethernet eth1 address ‘10.1.1.53/24’

Ethernet Interface

interface FastEthernet0/0

ip address 10.1.1.52 255.255.255.0

interface Loopback0

ip address 10.10.91.52 255.255.255.0

Virtual Tunnel Interface

set interfaces vti vti0 address ‘172.16.31.1/30’

Virtual Tunnel Interface

interface Tunnel1

ip address 172.16.31.2 255.255.255.252

tunnel source 10.1.1.52

tunnel destination 10.1.1.53

tunnel mode ipsec ipv4

tunnel protection ipsec profile VTI

IPSec

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 ‘enable’

set vpn ipsec esp-group ESP-1W proposal 1 encryption ‘3des’

set vpn ipsec esp-group ESP-1W proposal 1 hash ‘md5’

set vpn ipsec ike-group IKE-1W lifetime ‘14400’

set vpn ipsec ike-group IKE-1W proposal 1 dh-group ‘2’

set vpn ipsec ike-group IKE-1W proposal 1 encryption ‘3des’

set vpn ipsec ike-group IKE-1W proposal 1 hash ‘md5’

set vpn ipsec ipsec-interfaces interface ‘eth1’

set vpn ipsec site-to-site peer 10.1.1.52 authentication mode ‘pre-shared-secret’

set vpn ipsec site-to-site peer 10.1.1.52 authentication pre-shared-secret ‘test_key_1’

set vpn ipsec site-to-site peer 10.1.1.52 connection-type ‘initiate’

set vpn ipsec site-to-site peer 10.1.1.52 ike-group ‘IKE-1W’

set vpn ipsec site-to-site peer 10.1.1.52 local-address ‘10.1.1.53’

set vpn ipsec site-to-site peer 10.1.1.52 vti bind ‘vti0’

set vpn ipsec site-to-site peer 10.1.1.52 vti esp-group ‘ESP-1W’

IPSec

crypto isakmp policy 1

 encr 3des

 hash md5

 authentication pre-share

 group 2

 lifetime 14400

crypto isakmp key test_key_1 address 10.1.1.53

!

!

crypto ipsec transform-set TS esp-3des esp-md5-hmac

!

crypto ipsec profile VTI

 set transform-set TS

 set pfs group2

Routing

set protocols static interface-route 10.10.91.0/24 next-hop-interface vti0

Routing

ip route 192.168.107.0 255.255.255.0 Tunnel1

IPSec Status

 

vyatta@vyatta:~$ show vpn ike sa

Peer ID / IP                            Local ID / IP

————                            ————-

10.1.1.52                               10.1.1.53

 

State  Encrypt  Hash  D-H Grp  NAT-T  A-Time  L-Time

—–  ——-  —-  ——-  —–  ——  ——

up     3des     md5   2        no     1055    14400

vyatta@vyatta:~$ show vpn ipsec sa

Peer ID / IP                            Local ID / IP

————                            ————-

10.1.1.52                               10.1.1.53

 

Tunnel  State  Bytes Out/In   Encrypt  Hash  NAT-T  A-Time  L-Time  Proto

——  —–  ————-  ——-  —-  —–  ——  ——  —–

vti     up     500.0/500.0    3des     md5   no     847     3600    all

 

 

vyatta@vyatta:~$ show vpn ipsec sa statistics

Peer ID / IP                            Local ID / IP

————                            ————-

10.1.1.52                               10.1.1.53

 

Tunnel Dir Source Network               Destination Network          Bytes

—— — ————–               ——————-          —–

vti    in  0.0.0.0/0                    0.0.0.0/0                    500

 

vti    out 0.0.0.0/0                    0.0.0.0/0                    500

 

 

IPSec Status

IPSec#show crypto isakmp sa

dst             src             state          conn-id slot status

10.1.1.52       10.1.1.53       QM_IDLE              1    0 ACTIVE

10.1.1.53       10.1.1.52       MM_NO_STATE          2    0 ACTIVE (deleted)

IPSec#show crypto ipsec sa

interface: Tunnel1

Crypto map tag: Tunnel1-head-0, local addr 10.1.1.52

protected vrf: (none)

local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

current_peer 10.1.1.53 port 500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5

#pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 0, #recv errors 0

 

local crypto endpt.: 10.1.1.52, remote crypto endpt.: 10.1.1.53

path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0

current outbound spi: 0xC0F3B01C(3237195804)

inbound esp sas:

spi: 0x9A510884(2589001860)

transform: esp-3des esp-md5-hmac ,

in use settings ={Tunnel, }

conn id: 2001, flow_id: SW:1, crypto map: Tunnel1-head-0

sa timing: remaining key lifetime (k/sec): (4570194/3556)

IV size: 8 bytes

replay detection support: Y

Status: ACTIVE

 

inbound ah sas:

inbound pcp sas:

outbound esp sas:

spi: 0xC0F3B01C(3237195804)

transform: esp-3des esp-md5-hmac ,

in use settings ={Tunnel, }

conn id: 2002, flow_id: SW:2, crypto map: Tunnel1-head-0

sa timing: remaining key lifetime (k/sec): (4570194/3555)

IV size: 8 bytes

replay detection support: Y

Status: ACTIVE

outbound ah sas:

NOTE: VTI will show as “Admin Down A/D” before VPN is up.

vyatta@vyatta:~$    show interfaces

Codes: S – State, L – Link, u – Up, D – Down, A – Admin Down

Interface        IP Address                        S/L  Description

———        ———-                        —  ———–

eth1             10.1.1.53/24                      u/u

eth2             192.168.107.88/24                 u/u

lo               127.0.0.1/8                       u/u

::1/128

vti0             172.16.31.1/30                    A/D  

Update: we should use static interface-route instead of static route

Vyatta Virtuanl Tunnel Interface for Site to Site IPSec

In the newer version of Vyatta like 6.x, a new Virtuanl Tunnel Interface (VTI) is introduced for Site to Site IPSec.

A virtual tunnel interface provides a termination point for a site-to-site IPsec VPN tunnel and allows it to behave like other routable interfaces. In addition to simplifying the IPsec configuration, it enables many common capabilities to be used because the endpoint is associated with an actual interface.

Traffic being routed to a virtual tunnel interface is encrypted prior to being sent through the tunnel. Traffic arriving from a virtual tunnel interface is decrypted prior to its exposure to the routing system.

The virtual tunnel interface has the following restrictions and limitations:

1. It is only supported with IPv4, and not IPv6.

2. Only unicast and multicast IP traffic is allowed.

3. The Vyatta system uses fwmark in the kernel sk_buff to uniquely identify virtual tunnel interfaces (as well as entities associated with other features). Vyatta uses fwmark greater than or equal to 0x7FFF FFFF for this purpose. If you intend to use fwmark directly for another purpose, you should not use values greater than or equal to 0x7FFF FFFF.

4. Because the virtual tunnel interface and IP-in-IP tunnels use the same IP protocol type, it is not possible to use both of these tunnel types between the same tunnel endpoints.

5. The virtual tunnel interface does not support Time to Live (TTL) and Type of Service (ToS).

6.The IPsec mode must be configured as tunnel. See security vpn ipsec esp-group <name> mode <mode>.

7. Unlike other site-to-site IPsec VPN tunnels, the local and remote proxies are implicitly 0.0.0.0/0 so the remote and local subnets do not need to be specified explicitly.

8. IPSec peer 0.0.0.0 is not supported by VTI, which means VTI cant be used when the IPSec peer is behind of a NAT device.

VTI is highly recommended for Softlayer Vyatta Site to site IPSec due to the flexibility.

Note: not all Vendors IPSec VPN gateways are compatible with Vyatta VTI.

List of VPN device compatible with Vyatta VTI:

Cisco IOS router Virtual Tunnel Interface (VTI)

Vyatta VTI IPSec to Cisco IOS router

Juniper SRX Firewall Route-based VPN

Vyatta VTI IPSec to Juniper SRX Firewall