NAT-Problem when reconnecting a tunnel

[poldi871]

Problem (see attached files and network diagram): The router is connected to the Internet via an OTA modem and should establish a tunnel to the RZN253. The RZN253 is located behind a FritzBox, which has an official IP address. Both sides are natting. The first tunnel setup is successful and data can be transferred. The tunnel is then terminated. After the tunnel has ended, the OTA connection is also terminated and re-established. If the tunnel is to be reestablished (without restarting Pluto), it will fail. It looks as if Pluto is remembering "something" from the "old" tunnel on the router side.

Reproduction:

• Establish the OTA connection on the router
• Restart of ipsec on both sides
• Initiate tunnel from router
• End the tunnel on the router again
• Terminate the OTA connection on the router
• Restart the OTA connection on the router
• Call "ipsec auto --ready" (Pluto deletes the "old" address information and creates the "new" address configuration of the wwan0)
• Start tunnel again -> fails

Openswan-Versions:

• Router: root@VdLrp2:~# ipsec --version Linux Openswan U2.6.52.3/K4.14.214__LRP_ST_20210112 (netkey)

• RZN253: root@RZN253:~# ipsec --version Linux Openswan U2.6.52.3/K4.14.221 (netkey)

Remarks:

• Logs on the router side are commented (search for "##$$")
• IP addresses are just from a temporary test bed.

Files in the attachment:

• LogRouter.Simple.txt: Log without debugging as an overview (issuer) from a previous run.
• ipsec.RZN253.conf: Configuration of the server
• ipsec.Router.conf: configuration of the issuer
• LogRouter.Details.txt: full debugging log (issuer)
• LogRzn253.Details.txt: full debugging log (server)
• NetworkDiagram.pdf: Network structure

Thanks in advance, Poldi ToXelerance.tar.gz

[poldi871]

Nobody seems interested.

After doing some research, I can answer my question myself and post the answer here in case someone has the same problem. In my opinion it is a workaround, because I think that Pluto would have to recognize the change of the IP address itself after an "ipsec auto --ready". You can follow the problem very nicely with "ipsec whack --listpairs". It turns out that after a restart of the transport level and an "ipsec auto - ready" the changed IP is recognized, but in "listpairs" you can see that the address assignment remains on the "old" IP.

Workaround:

• After reconnecting the transport level, call "ipsec auto --ready".
• Call up the following program before starting the tunnel: "/ usr / libexec / ipsec / addconn --defaultroute "new IP of the interface" --defaultroutenexthop "new gateway IP address" "conn name"".
• As a result, the "conn" is deleted and added again. However, the side effect of the call is that the IP addresses are now correctly set. This does not work with an "ipsec auto --delete / --add", not even after an "ipsec auto --ready"

I'm surprised I haven't received a response for 26 days. An insider could have answered the question right away. And I am amazed that no one else has apparently had this problem, as I have not found any information about it anywhere.

[letoams]

There are no insiders left, the project continued as libreswan a decade ago. Libreswan has proper support for mobike and changing IPs automatically

Sent from my iPhone

On Mar 27, 2021, at 05:56, poldi871 @.***> wrote:

 Nobody seems interested.

After doing some research, I can answer my question myself and post the answer here in case someone has the same problem. In my opinion it is a workaround, because I think that Pluto would have to recognize the change of the IP address itself after an "ipsec auto --ready". You can follow the problem very nicely with "ipsec whack --listpairs". It turns out that after a restart of the transport level and an "ipsec auto - ready" the changed IP is recognized, but in "listpairs" you can see that the address assignment remains on the "old" IP.

Workaround:

After reconnecting the transport level, call "ipsec auto --ready". Call up the following program before starting the tunnel: "/ usr / libexec / ipsec / addconn --defaultroute "new IP of the interface" --defaultroutenexthop "new gateway IP address" "conn name"". As a result, the "conn" is deleted and added again. However, the side effect of the call is that the IP addresses are now correctly set. This does not work with an "ipsec auto --delete / --add", not even after an "ipsec auto --ready" I'm surprised I haven't received a response for 26 days. An insider could have answered the question right away. And I am amazed that no one else has apparently had this problem, as I have not found any information about it anywhere.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.