[Openswan Users] Openswan road warrior problem

[Siegfried Vogl]

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>