[Openswan Users] Openswan road warrior problem

[Siegfried Vogl]

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>