How to read status output

The libreswan status output is very verbose and confusing. Work is being done to make this a lot more userfriendly.

There are currently two status commands that can be used. Note all status commands prefix their output using "FTP status codes" in the form of three digits (eg 000 or 2xx or 5xx)

ipsec trafficstatus

The "ipsec whack --trafficstattus" command shows the tunnels that are currently established. An example output:

006 #48971: "redhat", username=pwouters, type=ESP, add_time=1480687195, inBytes=12295525, outBytes=673668
006 #50578: "supo.libreswan.org", type=ESP, add_time=1480701786, inBytes=0, outBytes=0, id='@melto.foobar.fi'
006 #50206: "vault.libreswan.org", type=ESP, add_time=1480698400, inBytes=1008, outBytes=1008, id='@foo-gw.foobar.fi'

This output shows that there are currently three connections established. The first connection is named "redhat". It has a username (XAUTH or IKEv2 CP) associated with it of "pwouters". It shows when the connection became active (add_time is the number of seconds since Unix Epoch) and a traffic count for incoming and outgoing traffic. The other two tunnels show simiar information, except that since these connections specified a remote ID to connect to, these IDs are also listed.

This short output does not reveal any details of the connection. It does not show if IKEv1 or IKEv2 was used.

ipsec status

The "ipsec status" command shows a more verbose but not very userfriendly output. This command is extremely verbose and was originally a developer-only tool for debugging. It is not really designed for administrators. Work is underway to replace this output with something more human readable.

The output consists of a few sections seperated by blanc lines:

• Network interfaces used
• Global configuration (from ipsec.conf's "config setup"
• Supported kernel algorithms for ESP/AH
• Supported userland algorithms for IKE
• Connection list (loaded connections - not neccessarilly active)
• State Information (including count of IKE and IPsec states)
• A list of all active IKE and IPsec states
• Bare shunts (packet-triggered policies for which no loaded connection matched)

We are interested in the connection list and the state list. Connection parameters are those parameters loaded from the configuration. State parameters are those parameters that are being or were negotiated for this particular negotiation of that connection.

Connection listing example

The following example output is the "redhat" connection as taken from the connection list section:

000 "redhat": 10.3.228.119/32===192.168.10.124[@OURREMOTEID,+MC+XC+S=C]---192.168.10.1...209.XXX.XXX.XXX<XXX.XXX.redhat.com>[MS+XS+S=C]===0.0.0.0/0; erouted; eroute owner: #2
000 "redhat":     oriented; my_ip=10.3.228.119; their_ip=unset
000 "redhat":   xauth us:client, xauth them:server,  my_username=pwouters; their_username=[any]
000 "redhat":   our auth:secret, their auth:secret
000 "redhat":   modecfg info: us:client, them:server, modecfg policy:push, dns1:unset, dns2:unset, domain:redhat.com, cat:unset;
000 "redhat": banner:Unauthorized Access to this or any other Red Hat Inc. device is strictly prohibited. Violators will be prosecuted. ;
000 "redhat":   labeled_ipsec:no;
000 "redhat":   policy_label:unset;
000 "redhat": 10.3.228.119/32===192.168.10.124[@,+MC+XC+S=C]---192.168.10.1...209.XXX.XXX.XXX[MS+XS+S=C]===10.0.0.0/8; erouted; eroute owner: #2
000 "redhat":     oriented; my_ip=10.3.228.119; their_ip=unset
000 "redhat":   xauth us:client, xauth them:server,  my_username=pwouters; their_username=[any]
000 "redhat":   our auth:secret, their auth:secret
000 "redhat":   modecfg info: us:client, them:server, modecfg policy:push, dns1:unset, dns2:unset, domain:redhat.com, cat:unset;
000 "redhat": banner:Unauthorized Access to this or any other Red Hat Inc. device is strictly prohibited. Violators will be prosecuted. ;
000 "redhat":   labeled_ipsec:no;
000 "redhat":   policy_label:unset;
000 "redhat":   ike_life: 86400s; ipsec_life: 86400s; replay_window: 32; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0;
000 "redhat":   retransmit-interval: 500ms; retransmit-timeout: 60s;
000 "redhat":   sha2-truncbug:yes; initial-contact:yes; cisco-unity:no; fake-strongswan:no; send-vendorid:yes; send-no-esp-tfc:no;
000 "redhat":   policy: PSK+ENCRYPT+TUNNEL+PFS+DONT_REKEY+UP+XAUTH+AGGRESSIVE+IKEV1_ALLOW+IKEV2_ALLOW+IKE_FRAG_ALLOW+NO_IKEPAD+ESN_NO;
000 "redhat":   conn_prio: 32,32; interface: wlp4s0; metric: 0; mtu: unset; sa_prio:666; sa_tfc:none;
000 "redhat":   nflog-group: unset; mark: 6/0xffffffff, 6/0xffffffff; vti-iface:ipsec0; vti-routing:yes; vti-shared:no;
000 "redhat":   dpd: action:hold; delay:30; timeout:60; nat-t: force_encaps:no; nat_keepalive:yes; ikev1_natt:both
000 "redhat":   newest ISAKMP SA: #3; newest IPsec SA: #2;
000 "redhat":   IKE algorithms wanted: AES_CBC(7)_128-SHA1(2)-MODP1024(2)
000 "redhat":   IKE algorithms found:  AES_CBC(7)_128-SHA1(2)-MODP1024(2)
000 "redhat":   IKE algorithm newest: AES_CBC_128-SHA1-MODP1024
000 "redhat":   ESP algorithms wanted: AES(12)_000-SHA1(2); pfsgroup=MODP1024(2)
000 "redhat":   ESP algorithms loaded: AES(12)_000-SHA1(2)
000 "redhat":   ESP algorithm newest: AES_256-HMAC_SHA1; pfsgroup=MODP1024

The most interesting bit is the first line that describes the IP ranges of both ends of the tunnel. The bulk of the output displays the various connection options that are set or unset. The last bit shows the interpretation of the algorithms specified in the connection's ike= and esp= line.

Note this part of the output does not state anything about whether this tunnel is up or down or being negotiatied. That information is visible in the State List:

State Listing example

000 Total IPsec connections: loaded 6, active 1
000
000 State Information: DDoS cookies not required, Accepting new IKE connections
000 IKE SAs: total(1), half-open(0), open(0), authenticated(1), anonymous(0)
000 IPsec SAs: total(1), authenticated(1), anonymous(0)
000
000 #2: "redhat":4500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE_IF_USED in 28039s; newest IPSEC; eroute owner; isakmp#1; idle; import:admin initiate
000 #2: "redhat" esp.9c01f20f@209.132.183.55 esp.e12dd706@192.168.10.124 tun.0@209.132.183.55 tun.0@192.168.10.124 ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=4194303B username=pwouters
000 #1: "redhat":4500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_EXPIRE in 86390s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; import:admin initiate
000

In this case there is one connection named "redhat". It has an established IKE SA (also called phase1 or Parent SA) numbered #1 and it has one IPsec SA (also called phase2 or Child SA) numbered #2. Every IPsec SA will list its IKE SA state number as "isakmp#XXX".

If the state claims "established", it means that it is fully up and running.

A Parent SA (phase1) state that is still negotiating has no Child SA (phase2) state. For example:

000 #51231: "private-or-clear#193.110.157.0/24"[1] ...193.110.157.102:500 STATE_PARENT_I1 (sent v2I1, expected v2R1); EVENT_v2_RETRANSMIT in 8s; idle; import:local rekey

In this case, we initiated a connection named "private-or-clear" to the remote IP 193.110.157.102, but the remote endpoint never responded to us. It shows the connection will retry in 8 seconds.

Next, an example of an IKEv2 tunnel that is established:

000 #50578: "supo.libreswan.org":500 STATE_PARENT_R2 (received v2I2, PARENT SA established); EVENT_SA_REPLACE in 22484s; newest IPSEC; eroute owner; isakmp#50577; idle; import:respond to stranger 000 #50578: "supo.libreswan.org" esp.9a8c024f@188.127.201.217 esp.8758b394@76.10.157.69 tun.0@188.127.201.217 tun.0@76.10.157.69 ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=0B 000 #50577: "supo.libreswan.org":500 STATE_PARENT_R2 (received v2I2, PARENT SA established); EVENT_SA_REPLACE in 22484s; newest ISAKMP; isakmp#0; idle; import:respond to stranger 000 #50577: "supo.libreswan.org" ref=0 refhim=0 Traffic: