search

xelerance / Openswan

Openswan
Other
849 stars 214 forks source link

NAT-Problem when reconnecting a tunnel #467

Closed poldi871 closed 3 years ago

poldi871 commented 3 years ago

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:

Openswan-Versions:

Remarks:

Files in the attachment:

Thanks in advance, Poldi ToXelerance.tar.gz

poldi871 commented 3 years ago

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:

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 commented 3 years ago

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.