Thanks Paul for looking into this issue and your valuable suggestion. We can see that the same IP is getting retained after reboot as well. Let us check our boot scripts.
Thanks, Gayathri On Wed, Feb 8, 2023 at 9:44 PM Paul Wouters <[email protected]> wrote: > On Wed, 8 Feb 2023, Gayathri Manoj wrote: > > > We have enabled Pre-shared key based IPSec connection between our > application which running on linux environment and Router. But when our > system goes > > for a reboot, we have to configure the policy again to work. Please let > us know the reason for the same. Pasting the snippet of the secure log. > > > Feb 2 15:53:42.572620: added connection description "71528943210_psk" > > Feb 2 15:53:42.572633: | > 134.61.36.39<134.61.36.39>...134.61.36.55<134.61.36.55> > > > Feb 2 15:53:42.583178: "71528943210_psk": We cannot identify ourselves > with either end of this connection. 134.61.36.39 or 134.61.36.55 are not > usable > > Odd. and you have the same IPs after a reboot? > > Looks like the network isn't full up yet when libreswan starts ? > > The linux distribution is responsible for ensuring the network is up > before libreswan starts. A workaround might be to issue "ipsec whack > --listen", > assuming you do have auto=start for the connection, but how or where to > add that to your startup service is up to you. > > The best thing is to fix that libreswan is started only after the IP > is funcitonal at boot. Usually, this is systemd's responsibility and > the /lib/systemd/system/ipsec.service file has an explicit: > > [Unit] > Wants=network-online.target > After=network-online.target > > That should only make it start after the network is fully online. > > Paul >
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
