<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><font face="DejaVu Serif">Hi Paul,<br>
      </font></p>
    <p><font face="DejaVu Serif">Attach the full log in boxB when
        connecting the remote endpoint (boxA). I've dynamic ip from
        BoxA, so i change the conf to %any in the right parameter. <br>
      </font></p>
    <p><font face="DejaVu Serif">Also from boxB to boxA i cannot start
        the connection because of firewall/NAT issue.</font></p>
    <p><font face="DejaVu Serif"><br>
      </font></p>
    <p><font face="DejaVu Serif">From the log i see.</font></p>
    <p><font face="DejaVu Serif">When remote is dialing </font><font
        face="DejaVu Serif"><font face="DejaVu Serif"><font face="DejaVu
            Serif">convxlanout</font></font>:<br>
      </font></p>
    <p><font face="DejaVu Serif">May 14 13:29:44.205380: | peer client
        is 10.136.31.107<br>
        May 14 13:29:44.205421: | peer client protocol/port is 17/0<br>
        May 14 13:29:44.205441: | our client is 90.175.130.18<br>
        May 14 13:29:44.205464: | our client protocol/port is 17/4789<br>
        May 14 13:29:44.205490: "ipsec9convxlanin"[1] 84.79.21.145 #1:
        the peer proposed: 90.175.130.18/32:17/4789 ->
        10.136.31.107/32:17/0<br>
        <br>
      </font><br>
      <font face="DejaVu Serif"><font face="DejaVu Serif"><font
            face="DejaVu Serif">When remote is dialing </font><font
            face="DejaVu Serif"><font face="DejaVu Serif"><font
                face="DejaVu Serif">convxlanin</font></font></font>:</font></font></p>
    <p><font face="DejaVu Serif">May 14 13:29:44.217021: | peer client
        is 10.136.31.107<br>
        May 14 13:29:44.217041: | peer client protocol/port is 17/4789<br>
        May 14 13:29:44.217060: | our client is 90.175.130.18<br>
        May 14 13:29:44.217080: | our client protocol/port is 17/0<br>
        May 14 13:29:44.217104: "ipsec9convxlanin"[1] 84.79.21.145 #1:
        the peer proposed: 90.175.130.18/32:17/4789 ->
        10.136.31.107/32:17/0</font></p>
    <p><font face="DejaVu Serif">Here should it print:</font></p>
    <p><font face="DejaVu Serif"><font face="DejaVu Serif">May 14
          13:29:44.217104: "ipsec9convxlanin"[1] 84.79.21.145 #1: the
          peer proposed: 90.175.130.18/32:17/<b>0</b> ->
          10.136.31.107/32:17/</font></font><b><font face="DejaVu Serif">4789</font></b></p>
    <p><font face="DejaVu Serif"><br>
      </font></p>
    <p><font face="DejaVu Serif"><br>
      </font></p>
    <p><font face="DejaVu Serif">As for the counters to 0, that's
        another issue...but i think is related to the fact i'm not able
        to establish the convxlanout in the boxB. <br>
      </font></p>
    <p><font face="DejaVu Serif">Although i see the policy rules:</font></p>
    <p><font face="DejaVu Serif">src 10.136.31.107/32 dst
        90.175.130.18/32 proto udp dport 4789 <br>
            dir out priority 2016 ptype main <br>
            tmpl src 0.0.0.0 dst 0.0.0.0<br>
                proto esp reqid 16393 mode transport<br>
      </font></p>
    <p><font face="DejaVu Serif"><br>
      </font></p>
    <p><font face="DejaVu Serif">and the traffic is well generated:<br>
      </font></p>
    <p><font face="DejaVu Serif">14:05:42.664684 Out fa:16:31:3b:f6:45
        ethertype IPv4 (0x0800), length 112: (tos 0x0, ttl 64, id 64205,
        offset 0, flags [none], proto UDP (17), length 96)<br>
            10.136.31.107.40204 > 90.175.130.18.4789: VXLAN, flags
        [I] (0x08), vni 20<br>
      </font></p>
    <p><font face="DejaVu Serif"><br>
      </font></p>
    <p><font face="DejaVu Serif">No traffic is encrypted. <br>
      </font></p>
    <p><font face="DejaVu Serif"><br>
      </font></p>
    <br>
    <div class="moz-cite-prefix">On 05/13/2018 01:16 AM, Paul Wouters
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:alpine.LRH.2.21.1805121913260.6720@bofh.nohats.ca">On
      Sat, 12 May 2018, antonio wrote: <br>
      <br>
      <blockquote type="cite">Thanks Paul, this work defined but i think
        i found a issue, the left/right protocol are not respected...
        and <br>
        so the tunnels are partial up and i cannot send vxlan traffic
        through the vpn. <br>
        <br>
        My current conf is (boxA and boxB - reverted left/right params):
        <br>
        <br>
        conn ipsec9convxlanout <br>
                also=ipsec9convxlan <br>
                leftprotoport=17/0 <br>
                rightprotoport=17/4789 <br>
                auto=start <br>
        <br>
        conn ipsec9convxlanin <br>
                also=ipsec9convxlan <br>
                leftprotoport=17/4789 <br>
                rightprotoport=17/0 <br>
                auto=start <br>
        <br>
        conn ipsec9convxlan <br>
                type=transport <br>
                leftrsasigkey=%cert <br>
                leftcert=LabVxLANandDemoVxLAN <br>
                rightrsasigkey=%cert <br>
                leftid=@LabVxLAN <br>
                left=192.168.1.108 <br>
                right=20.20.10.4 <br>
                rightid=@DemoVxLAN <br>
                dpddelay=30 <br>
                dpdtimeout=60 <br>
                dpdaction=restart <br>
      </blockquote>
      <br>
      That should work. <br>
      <br>
      <blockquote type="cite"> <br>
        My left side is behind NAT and i cannot force port 500 or 4500
        to libreswan box, so i end up with partial <br>
        tunnels up. <br>
      </blockquote>
      <br>
      The NAT should not matter as long as one end is not behind NAT (or
      <br>
      behind a port forward) <br>
      <br>
      <blockquote type="cite">left both conns are up: <br>
        <br>
        ipsec whack --trafficstatus <br>
        006 #3: "ipsec1convxlanin", type=ESP, add_time=1526136419,
        inBytes=0, outBytes=0, id='@LabVxLAN' <br>
        006 #2: "ipsec1convxlanout", type=ESP, add_time=1526136418,
        inBytes=0, outBytes=0, id='@LabVxLAN' <br>
      </blockquote>
      <br>
      Although no traffic has ever matched these tunnels as the byte
      counters <br>
      are all zero. <br>
      <br>
      <blockquote type="cite"> <br>
        right side is wrong: <br>
        ipsec whack --trafficstatus <br>
        006 #6: "ipsec9convxlanin", type=ESP, add_time=1526136418,
        inBytes=0, outBytes=0, id='@DemoVxLAN' <br>
        006 #7: "ipsec9convxlanin", type=ESP, add_time=0, inBytes=0,
        outBytes=0, id='@DemoVxLAN' <br>
      </blockquote>
      <br>
      That's odd. you should check the logs what happened. It looks like
      one <br>
      might have replaced the other. <br>
      <br>
      <blockquote type="cite">When connecting the  ipsec1convxlanout
        from left side it detects the connection as ipsec9convxlanin....
        <br>
      </blockquote>
      <br>
      During the IKE negotiation, pluto cannot yet tell which of the two
      will <br>
      match. It is perfectly normal for it to "switch" from one conn to
      the <br>
      other once it learns the phase2/ipsec selectors. <br>
      <br>
      <blockquote type="cite">Can i do this with my current
        configuration? Or i should defined two different connections
        (different ids)? <br>
      </blockquote>
      <br>
      You can do that but it should not be needed. <br>
      <br>
      Paul <br>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Saludos / Regards / Cumprimentos
Anónio Silva</pre>
  </body>
</html>