<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000066" bgcolor="#FFFFFF">
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 03/18/2018 10:16 AM, Info wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:841a1a3f-86c1-7168-72e6-1b9b28561081@quantum-equities.com">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      On 03/18/2018 06:03 AM, Noel Kuntze wrote:<br>
      <blockquote type="cite"
        cite="mid:9ea18b26-1503-d1a6-d27b-5d8e293883cc@thermi.consulting"><br>
        <blockquote type="cite">
          <pre wrap="">I've given up on my complete LAN using VPN as some devices can not do IPSec, and I can't figure out how to make them interoperate with machines running IPSec.
</pre>
        </blockquote>
        <pre wrap="">Use passthrough policies for those hosts.</pre>
      </blockquote>
      My goal though was complete encryption, even within the LAN, to
      combat potential malefactors already inside using port mirroring
      in a switch, et al.  However this process has been difficult for
      me and anyway, several of my LAN devices can not do IPSec.
      (printers, Z-wave bridges, etc)  I am sure there is a way to
      connect them in without IPSec, but after over a month of study I'm
      just backing down to the basics - remote IPSec.<br>
      <br>
      <blockquote type="cite"
        cite="mid:9ea18b26-1503-d1a6-d27b-5d8e293883cc@thermi.consulting">
        <blockquote type="cite">
          <pre wrap="">ikev2-pubkey {
        version = 2
#        proposals = aes192gcm16-aes128gcm16-aes192-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
        rekey_time = 0s
        pools = primary-pool-ipv4 #, primary-pool-ipv6
        fragmentation = yes
        dpd_delay = 30s
        # dpd_timeout doesn't do anything for IKEv2. The general IKEv2 packet timeouts are used.
        local-1 {
            cert = cygnus-Cert.pem
            id = cygnus.darkmatter.org
        }
        remote-1 {
            # defaults are fine.
        }
        children {
            ikev2-pubkey {
                local_ts = 0.0.0.0/0 #,::/0
                rekey_time = 0s
                dpd_action = clear
#                esp_proposals = aes192gcm16-aes128gcm16-aes192-ecp256,aes192-sha256-modp3072,default
            }
        }
    }
</pre>
        </blockquote>
        <pre wrap="">Why would you want to propose the local_ts to be all hosts in your use case? That makes no sense.</pre>
      </blockquote>
      <blockquote type="cite"
        cite="mid:9ea18b26-1503-d1a6-d27b-5d8e293883cc@thermi.consulting">
        <blockquote type="cite">
          <pre wrap="">The local_ts determines what traffic is to go in to IPSec, but that would be all of it.

</pre>
        </blockquote>
        <pre wrap="">No. The local_ts configures the proposed local part of the traffic selector. That is/are, for traffic coming from you side over the tunnel, the subnet(s) which are allowed to appear in the source IP field.
For packets coming from the other peer over the tunnel, that is/are the subnet(s) which are allowed to appear in the destination IP field.</pre>
      </blockquote>
      I want all hosts in the LAN to be able to communicate with the
      remote machines.  So in this case maybe local_ts = 192.168.1.0/24
      ?<br>
      <br>
      Each member of the LAN has its own firewall treating the rest of
      the LAN as untrusted, so I guess that routing traffic to say, a
      remote mailserver would require firewall SNAT rule(s) in each LAN
      member.<br>
      <br>
      <br>
      <blockquote type="cite"
        cite="mid:9ea18b26-1503-d1a6-d27b-5d8e293883cc@thermi.consulting">
        <pre wrap="">The remote_ts configures proposed remote part of the traffic selector. That is/are , for traffic coming from your side over the tunnel, the subnet(s) which are allowed to appear in the destination IP field.
For packets coming from the other peer over the tunnel, that is/are the subnet(s) which are allowed to appear in the source IP field. That is applied vice-versa for the other peer (your local_ts is their remote_ts).</pre>
      </blockquote>
      There will be one (unpredictable) remote IP for the mailserver.
      (because it's an OpenStack instance.  It will be relatively
      stable, but I don't want to change Strongswan config every time
      the mailserver IP changes, so I count that as unpredictable)<br>
      <br>
      There are other (unpredictable) remote IPs for phones and tablets,
      and I infer that each one will form a point-to-point IPSec
      connection with the IPSec gateway, but I don't understand how to
      translate this into the swanctl.conf.  And how to reach those
      individual remotes from a given machine in the LAN is a mystery. 
      <br>
      <br>
      As the remote defaults are Ok for config in the IPSec gateway,
      that must mean that remote_ts = 0.0.0.0/0 ?<br>
      <br>
      <blockquote type="cite"
        cite="mid:9ea18b26-1503-d1a6-d27b-5d8e293883cc@thermi.consulting">
        <pre wrap="">The proposed traffic selectors are narrowed by the two sides to a biggest common set. That is called traffic selector narrowing. strongSwna implements it for IKEv1 and IKEv2, but it is only part of the standard for IKEv2. It allows greater flexibility with peers that implement it for IKEv1, too.

A negotiated(!) traffic selector is always symmetric for the two peers. Meaning that the negotiated local_ts is the remote's remote_ts and vice-versa. The particualr exception on Linux is the mark field of a policy or state. The idea is that the local configured mark can be used to determin which traffic exactly is to be tunneled and be able to use the full flexibility of netfilter for that. The mark is not transmitted to the other peer.</pre>
      </blockquote>
      Understand, thanks.<br>
      <br>
      So it seems that the mark field would be how I segregate email
      ports on the mailserver, when I want all other traffic to go
      through the VPN to the IPSec gateway?<br>
      <br>
      <blockquote type="cite"
        cite="mid:9ea18b26-1503-d1a6-d27b-5d8e293883cc@thermi.consulting">
        <blockquote type="cite">
          <pre wrap="">So from another machine in the LAN I aim at the mailserver outside at 72.251.232.108, if I can somehow make the LAN direct traffic to the IPSec gateway (which is different from the LAN gateway), the IPSec gateway should somehow aim it at the mailserver rather than the remote phone or tablet.

And somehow the IPSec gateway should be able to carry on simultaneous conversations with the mailserver and phone/tablet, but surely that means two point-to-point connections..
</pre>
        </blockquote>
        <pre wrap="">Yes.</pre>
      </blockquote>
      I was meaning to ask, how does the IPSec gate way aim mailserver
      traffic to the mailserver, and phone/tablet traffic to them?<br>
      <br>
      <br>
      <blockquote type="cite"
        cite="mid:9ea18b26-1503-d1a6-d27b-5d8e293883cc@thermi.consulting">
        <blockquote type="cite">
          <pre wrap="">The IPSec gateway is a virtual machine dedicated to being the IPSec gateway for the LAN.  All port 500 and 4500 traffic is directed to it by the LAN gateway using DNAT, and the LAN gateway has a public IP.  No special measures have been taken on the LAN gateway for routing ESP.

</pre>
        </blockquote>
        <pre wrap="">ESP shouldn't really matter for your peers, because every one of them is supposed to switch to UDP encapsulation as soon as the NAT on your router is detected.</pre>
      </blockquote>
      I now understand that automatic NAT traversal is inherent in IKE2,
      thanks, so no need for me to worry about that.<br>
       <br>
      <blockquote type="cite"
        cite="mid:9ea18b26-1503-d1a6-d27b-5d8e293883cc@thermi.consulting"><br>
        <blockquote type="cite">
          <pre wrap="">On the remote phone, which runs the Strongswan app and has a public IP, an attempt to connect results in my old friend "NO_PROPOSAL_CHOSEN".

In the IPSec gateway's log is:

Mar 16 17:57:08 12[ENC] <1> parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Mar 16 17:57:08 12[CFG] <1> looking for an ike config for 192.168.1.16...192.168.1.6
Mar 16 17:57:08 12[IKE] <1> no IKE config found for 192.168.1.16...192.168.1.6, sending NO_PROPOSAL_CHOSEN

</pre>
        </blockquote>
        <pre wrap="">What did you configure there?</pre>
      </blockquote>
      <br>
      > Your logging configuration is too verbose and the problem is
      that there is no matching IKE SA configuration found for what the
      peer wants. What is configured on it?<br>
      ><br>
      <br>
      Yes, my mistake.  I had the phone on wifi as a member of my LAN.<br>
      <br>
      Below is the error when it's not.  On the phone is the Android Ss
      app.  My understanding is it has to have Advanced|ServerIdentity
      set to the resolvable IPSec gateway, which it is.  Although in the
      phone's cert I don't know whether SAN and CN should be set in some
      special way?  I have them set to the phone's resolvable
      name.domain.tld when it is a member of the LAN only.  Same
      question with the IPSec gateway's cert?<br>
      <br>
      I have logging set high because I'm trying to get an idea -why-
      there is NO PROPOSAL CHOSEN, and it is still not giving me a hint
      other than "no IKE config found".  But what aspect of the config
      is wrong?  No idea.  Logging is supposed to bail me out in this
      case.<br>
      <br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      received packet: from 172.56.42.91[55000] to 192.168.1.16[500]
      (704 bytes)<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET] received packet => 704 bytes @ 0x7f3f4597e450<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]    0: D8 5A 08 C0 67 A9 C6 EE 00 00 00 00 00 00 00 00 
      .Z..g...........<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]   16: 21 20 22 08 00 00 00 00 00 00 02 C0 22 00 01 E0  !
      "........."...<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]   32: 02 00 00 DC 01 01 00 19 03 00 00 0C 01 00 00 0C 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]   48: 80 0E 00 80 03 00 00 0C 01 00 00 0C 80 0E 00 C0 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]   64: 03 00 00 0C 01 00 00 0C 80 0E 01 00 03 00 00 08 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]   80: 01 00 00 03 03 00 00 08 03 00 00 0C 03 00 00 08 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]   96: 03 00 00 0D 03 00 00 08 03 00 00 0E 03 00 00 08 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  112: 03 00 00 02 03 00 00 08 03 00 00 05 03 00 00 08 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  128: 02 00 00 05 03 00 00 08 02 00 00 06 03 00 00 08 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  144: 02 00 00 07 03 00 00 08 02 00 00 04 03 00 00 08 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  160: 02 00 00 02 03 00 00 08 04 00 00 13 03 00 00 08 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  176: 04 00 00 14 03 00 00 08 04 00 00 15 03 00 00 08 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  192: 04 00 00 1C 03 00 00 08 04 00 00 1D 03 00 00 08 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  208: 04 00 00 1E 03 00 00 08 04 00 00 1F 03 00 00 08 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  224: 04 00 00 0F 03 00 00 08 04 00 00 10 03 00 00 08 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  240: 04 00 00 12 00 00 00 08 04 00 00 0E 00 00 01 00 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  256: 02 01 00 1A 03 00 00 0C 01 00 00 14 80 0E 00 80 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  272: 03 00 00 0C 01 00 00 14 80 0E 00 C0 03 00 00 0C 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  288: 01 00 00 14 80 0E 01 00 03 00 00 0C 01 00 00 1C 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  304: 80 0E 01 00 03 00 00 0C 01 00 00 13 80 0E 00 80 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  320: 03 00 00 0C 01 00 00 13 80 0E 00 C0 03 00 00 0C 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  336: 01 00 00 13 80 0E 01 00 03 00 00 0C 01 00 00 12 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  352: 80 0E 00 80 03 00 00 0C 01 00 00 12 80 0E 00 C0 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  368: 03 00 00 0C 01 00 00 12 80 0E 01 00 03 00 00 08 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP)
      N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  384: 02 00 00 05 03 00 00 08 02 00 00 06 03 00 00 08 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  400: 02 00 00 07 03 00 00 08 02 00 00 04 03 00 00 08 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  416: 02 00 00 02 03 00 00 08 04 00 00 13 03 00 00 08 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  432: 04 00 00 14 03 00 00 08 04 00 00 15 03 00 00 08 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  448: 04 00 00 1C 03 00 00 08 04 00 00 1D 03 00 00 08 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  464: 04 00 00 1E 03 00 00 08 04 00 00 1F 03 00 00 08 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  480: 04 00 00 0F 03 00 00 08 04 00 00 10 03 00 00 08 
      ................<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  496: 04 00 00 12 00 00 00 08 04 00 00 0E 28 00 00 48 
      ............(..H<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  512: 00 13 00 00 11 A9 40 1A 9E E5 A1 20 2A CF 83 E3 
      ......@.... *...<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  528: 6D 73 D6 5E 66 55 F7 22 6B BA 16 7D A2 34 9C 12 
      ms.^fU."k..}.4..<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  544: 46 26 00 4E 24 00 1E AE 84 FF 9C 24 19 41 79 DE 
      F&.N$......$.Ay.<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  560: 66 BC BA 28 0E EB EC 01 8A E0 0F 4B 76 F8 0E EF 
      f..(.......Kv...<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  576: D0 C2 14 44 29 00 00 24 B1 3B 3F 44 6B 85 60 5A 
      ...D)..$.;?Dk.`Z<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  592: 6A A6 7F E1 04 E7 C1 C0 8A D4 F6 9A 56 6F 05 93 
      j...........Vo..<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  608: 1A 1A 81 2D C0 09 84 9C 29 00 00 1C 00 00 40 04 
      ...-....).....@.<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  624: 07 63 25 BC DE 6B 93 C8 45 1B 0E C7 78 42 7A 47 
      .c%..k..E...xBzG<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  640: 39 84 1C FB 29 00 00 1C 00 00 40 05 C2 3E F3 86 
      9...).....@..>..<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  656: BB D5 CE 34 9D 19 C8 B5 C5 94 9E 61 B6 8F FE E9 
      ...4.......a....<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  672: 29 00 00 08 00 00 40 2E 29 00 00 10 00 00 40 2F 
      ).....@.).....@/<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET]  688: 00 02 00 03 00 04 00 05 00 00 00 08 00 00 40 16 
      ..............@.<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET] received packet: from 172.56.42.91[55000] to
      192.168.1.16[500]<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      03[NET] waiting for data on sockets<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      15[MGR] checkout IKEv2 SA by message with SPIs d85a08c067a9c6ee_i
      0000000000000000_r<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      15[MGR] created IKE_SA (unnamed)[2]<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      15[NET] received packet: from 172.56.42.91[55000] to
      192.168.1.16[500] (704 bytes)<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      15[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP)
      N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]: no
      IKE config found for 192.168.1.16...172.56.42.91, sending
      NO_PROPOSAL_CHOSEN<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      15[CFG] looking for an ike config for 192.168.1.16...172.56.42.91<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      15[IKE] no IKE config found for 192.168.1.16...172.56.42.91,
      sending NO_PROPOSAL_CHOSEN<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      15[ENC] generating IKE_SA_INIT response 0 [ N(NO_PROP) ]<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      15[NET] sending packet: from 192.168.1.16[500] to
      172.56.42.91[55000] (36 bytes)<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      15[MGR] checkin and destroy IKE_SA (unnamed)[2]<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      15[IKE] IKE_SA (unnamed)[2] state change: CREATED => DESTROYING<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      15[MGR] checkin and destroy of IKE_SA successful<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      04[NET] sending packet: from 192.168.1.16[500] to
      172.56.42.91[55000]<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      generating IKE_SA_INIT response 0 [ N(NO_PROP) ]<br>
      Mar 18 09:49:15 cygnus.darkmatter.org charon-systemd[11604]:
      sending packet: from 192.168.1.16[500] to 172.56.42.91[55000] (36
      bytes)<br>
      <br>
    </blockquote>
    <br>
    <br>
    Stripped down to the bare minimum, trying to connect with the
    phone.  Unbelievable.  No hints in the log.<br>
    <br>
    swanctl.conf:<br>
    ikev2-pubkey {<br>
            version = 2<br>
            rekey_time = 0s<br>
            local {<br>
                    cert = cygnus-Cert.pem<br>
                    id = cygnus.darkmatter.org<br>
            }<br>
            remote {<br>
                    # defaults are fine.<br>
            }<br>
            children {<br>
                    ikev2-pubkey {<br>
                        local_ts = 192.168.1.0/24<br>
                        mode = transport<br>
                    }<br>
            }<br>
    }<br>
    <br>
    ...<br>
    Mar 18 12:14:59 12[ENC] <1> parsed IKE_SA_INIT request 0 [ SA
    KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP)
    ]<br>
    Mar 18 12:14:59 12[CFG] <1> looking for an ike config for
    192.168.1.16...172.56.42.178<br>
    Mar 18 12:14:59 12[IKE] <1> no IKE config found for
    192.168.1.16...172.56.42.178, sending NO_PROPOSAL_CHOSEN<br>
    Mar 18 12:14:59 12[ENC] <1> added payload of type NOTIFY to
    message<br>
    Mar 18 12:14:59 12[ENC] <1> order payloads in message<br>
    Mar 18 12:14:59 12[ENC] <1> added payload of type NOTIFY to
    message<br>
    Mar 18 12:14:59 12[ENC] <1> generating IKE_SA_INIT response 0
    [ N(NO_PROP) ]<br>
    Mar 18 12:14:59 12[ENC] <1> not encrypting payloads<br>
    Mar 18 12:14:59 12[ENC] <1> generating payload of type HEADER<br>
    Mar 18 12:14:59 12[ENC] <1>   generating rule 0 IKE_SPI<br>
    Mar 18 12:14:59 12[ENC] <1>   generating rule 1 IKE_SPI<br>
    Mar 18 12:14:59 12[ENC] <1>   generating rule 2 U_INT_8<br>
    Mar 18 12:14:59 12[ENC] <1>   generating rule 3 U_INT_4<br>
    Mar 18 12:14:59 12[ENC] <1>   generating rule 4 U_INT_4<br>
    Mar 18 12:14:59 12[ENC] <1>   generating rule 5 U_INT_8<br>
    Mar 18 12:14:59 12[ENC] <1>   generating rule 6 RESERVED_BIT<br>
    Mar 18 12:14:59 12[ENC] <1>   generating rule 7 RESERVED_BIT<br>
    ...<br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
  </body>
</html>