From svogl at vodata.de  Sat Jun 20 08:05:14 2020
From: svogl at vodata.de (Siegfried Vogl)
Date: Sat, 20 Jun 2020 14:05:14 +0200
Subject: [Openswan Users] Openswan road warrior problem
Message-ID: <79e016d9-496f-b357-01e7-12655807a571@vodata.de>

Hello,

i have a road warrior problem.
Data flow: IPSEC-Client (Initiator) <-> IP-Gateway <-> 
Ipsec-Gateway(Responder) <-> Web-Server

If the client is configured as a "road warrior" on the Ipsec gateway, 
the rekeying of the ISAKMP SA does not work on the responder side.
The gateway receives the first negotiation packet itself (see log: 
"RZNV87 / Log.txt" (search:)-> "##$$ Pluto sends packet to himself ...")


Attachments - a TGZ extracting as folder "Data":
  - Networkplan.pdf: a sheme of the test bed
  - RZNV87: Ipsec-Gateway (responder) data (search for comments in 
Log.txt: "##$$")
  - R2_Testclient: Ipsec-Client (Initiator) data.

Notes:
  - "IpsecStatusCmd.txt" in both directories is the output of "ipsec 
status" after the tunnel was established and after the fist try of the 
responder to rekey the ISAKMP SA.
  - After the tunnel is established, data transfer is successfull.
  - All data files were filtered against readable DN's an FQDN's 
(although it's only a test bed anyway).
  - RZNV89, RZNV87 and RZNV82 are VM's on a virtualbox host (RZN161).
  - The test bed is simplified a little.
    In production, the initiator (which has a static ip here to simplify 
things) is a DHCP client. Therefore i need the roadwarrior setup.
    I shortened the timers for ikelifetime, salifetime and rekeymargin 
to get shorter test intervalls. But it is the same problem with default 
values.
  - I did some debugging:
    It seems that "st->st_remoteaddr" of the new created state element 
is not copied, although the "orient()" seems to find the correct assignment.
    But because I don't know details of the implementation, this is only 
an assumption.

Thanks in advance,
Siegfried

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Data.tar.gz
Type: application/gzip
Size: 210980 bytes
Desc: not available
URL: <http://lists.openswan.org/pipermail/users/attachments/20200620/d0852f5f/attachment-0001.gz>

From svogl at vodata.de  Sat Jun 20 08:25:37 2020
From: svogl at vodata.de (Siegfried Vogl)
Date: Sat, 20 Jun 2020 14:25:37 +0200
Subject: [Openswan Users] Openswan road warrior problem
Message-ID: <5ecdc684-18d1-c2d3-8da1-4bda8b0e4ce6@vodata.de>

Hello,


sorry, I've made a mistake. The "R2_Testclient/IpsecBarf.txt" is from a 
wrong device.


I've packed the whole data once again, now with the corrected 
"IpsecBarfCorrected.txt"


Sorry,


Siegfried


    -----Ursprüngliche Nachricht-----
    *Von:* Siegfried Vogl <svogl at vodata.de>
    *Gesendet:* Samstag 20 Juni 2020 14:05
    *An:* users at lists.openswan.org
    *Betreff:* Openswan road warrior problem

    Hello,

    i have a road warrior problem.
    Data flow: IPSEC-Client (Initiator) <-> IP-Gateway <->
    Ipsec-Gateway(Responder) <-> Web-Server

    If the client is configured as a "road warrior" on the Ipsec gateway,
    the rekeying of the ISAKMP SA does not work on the responder side.
    The gateway receives the first negotiation packet itself (see log:
    "RZNV87 / Log.txt" (search:)-> "##$$ Pluto sends packet to himself ...")


    Attachments - a TGZ extracting as folder "Data":
       - Networkplan.pdf: a sheme of the test bed
       - RZNV87: Ipsec-Gateway (responder) data (search for comments in
    Log.txt: "##$$")
       - R2_Testclient: Ipsec-Client (Initiator) data.

    Notes:
       - "IpsecStatusCmd.txt" in both directories is the output of "ipsec
    status" after the tunnel was established and after the fist try of the
    responder to rekey the ISAKMP SA.
       - After the tunnel is established, data transfer is successfull.
       - All data files were filtered against readable DN's an FQDN's
    (although it's only a test bed anyway).
       - RZNV89, RZNV87 and RZNV82 are VM's on a virtualbox host (RZN161).
       - The test bed is simplified a little.
         In production, the initiator (which has a static ip here to simplify
    things) is a DHCP client. Therefore i need the roadwarrior setup.
         I shortened the timers for ikelifetime, salifetime and rekeymargin
    to get shorter test intervalls. But it is the same problem with default
    values.
       - I did some debugging:
         It seems that "st->st_remoteaddr" of the new created state element
    is not copied, although the "orient()" seems to find the correct assignment.
         But because I don't know details of the implementation, this is only
    an assumption.

    Thanks in advance,
    Siegfried

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Data_corrected.tar.gz
Type: application/gzip
Size: 203208 bytes
Desc: not available
URL: <http://lists.openswan.org/pipermail/users/attachments/20200620/7aed343c/attachment-0001.gz>