<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    Hi Paul,<br>
    <br>
    If you have a conn:<br>
    conn njh<br>
     type=tunnel<br>
     authby=secret<br>
     auto=ignore<br>
     #auto=start<br>
     left=12345.example.com<br>
     leftsourceip=172.17.2.1<br>
     leftsubnet=172.17.2.0/24<br>
     right=159.203.19.178<br>
     rightsourceip=10.137.48.60<br>
     rightsubnet=10.137.48.60/16<br>
     dpdaction=restart<br>
     dpdtimeout=120<br>
     dpddelay=30<br>
    <br>
    Then load it with "ipsec auto --add njh" you get the following:<br>
    [root@server ~]#  ipsec auto --add njh<br>
    000 failed to convert '12345.example.com' at load time: not a
    numeric IPv4 address and name lookup failed (no validation
    performed)<br>
    002 added connection description "njh"<br>
    <br>
    It seems to be because the first subdomain is numeric. It seems to
    assume that if the first part of the FQDN is numeric then the
    parameter is going to be an IP address and not an FQDN. In this case
    12345 can never be an FQDN, but you get the same issue 123. I have a
    feeling some cleverer interpretation is needed of this type of
    parameter.<br>
    <br>
    I have tested this with a valid FQDN like this but can't publish it,
    unfortunately. You can test it on *.poweredbyclear.com as it has
    wildcard resolution back to the primary A record.<br>
    <br>
    This is with libreswan-3.25-9.1.el7_8.x86_64.<br>
    <br>
    Regards,<br>
    <br>
    Nick<br>
  </body>
</html>