Skip to content

Conversation

@Tontonjo
Copy link

This bug appears when you let the openvpn server in "multihome" configuration, preventing the connexion to be established.

Related to and fixed by user hashiz in openvpn community but not yet implemented.

https://community.openvpn.net/openvpn/attachment/ticket/874/patch-src-openvpn-socket.c

Tested this fix on my setup with success

Thank you for your contribution

You are welcome to open PR, but they are used for discussion only. All
patches must eventually go to the openvpn-devel mailing list for review:

Please send your patch using git-send-email. For example to send your latest commit to the list:

$ git send-email --to=openvpn-devel@lists.sourceforge.net HEAD~1

For details, see these Wiki articles:

This bug appears when you let the openvpn server in "multihome" configuration, preventing the connexion to be established.

Related to and fixed by user hashiz in openvpn community but not yet implemented.

https://community.openvpn.net/openvpn/attachment/ticket/874/patch-src-openvpn-socket.c

Tested this fix on my setup with success
@schwabe
Copy link
Contributor

schwabe commented May 16, 2024

We assume that you can reply on the same interface (ifindex) that you get message in. You are removing that assumption. I think your change will break talking to clients that connect via link local addresses as for those you need to specify the ifindex to be able to reply.

So it would be good to have a better understanding of your environment and why this is happening. Do you have some assymetric routing setup?

@Tontonjo
Copy link
Author

Tontonjo commented May 16, 2024

We assume that you can reply on the same interface (ifindex) that you get message in. You are removing that assumption. I think your change will break talking to clients that connect via link local addresses as for those you need to specify the ifindex to be able to reply.

So it would be good to have a better understanding of your environment and why this is happening. Do you have some assymetric routing setup?

As far as i know i dont have an asymetric setup.

Let me clarify a bit:
This fixed my problem where i was unable to correctly establish connexion over ipv6 in "multihome" mode.

My VPN would correctly be established if i'd set the "local" address to my ipv6 interface address, but this would imply to lose ipv4 connectivity, which i dont want to.

This fix is not mine but as far as the bug seems to have been stalled and this indeed fixed it in my case, i though it would be cool to contribute.

Regards

@cron2
Copy link
Contributor

cron2 commented Nov 17, 2025

Mmmh, this seems to be a duplicate of #856 which has a much more helpful subject line...

And no, this hasn't been fixed, because the "simple fix" breaks other scenarios.

@Tontonjo
Copy link
Author

Mmmh, this seems to be a duplicate of #856 which has a much more helpful subject line...

And no, this hasn't been fixed, because the "simple fix" breaks other scenarios.

What brought you there, my dear, after all this time?

@cron2
Copy link
Contributor

cron2 commented Nov 17, 2025

Mmmh, this seems to be a duplicate of #856 which has a much more helpful subject line...
And no, this hasn't been fixed, because the "simple fix" breaks other scenarios.

What brought you there, my dear, after all this time?

Cleaning up GH PRs. Since we never merge PRs, and discourage them for everything except initial review, these are by definition all stale - but there are over 40 open PRs, which is not how things should be.

@Tontonjo
Copy link
Author

Mmmh, this seems to be a duplicate of #856 which has a much more helpful subject line...
And no, this hasn't been fixed, because the "simple fix" breaks other scenarios.

What brought you there, my dear, after all this time?

Cleaning up GH PRs. Since we never merge PRs, and discourage them for everything except initial review, these are by definition all stale - but there are over 40 open PRs, which is not how things should be.

For sure it should have been closed by the time.

@Tontonjo Tontonjo closed this Nov 17, 2025
cron2 added a commit that referenced this pull request Nov 26, 2025
Traditional OpenVPN ``--multihome`` behaviour is to send packets out the
same interface that they were received on (copy ipi_ifindex from ingress
to egress packet info).  For some scenarios this makes sense, for other
scenarios it is breaking connectivity when there are no routes pointing
out the ingress interface (intentionally asymmetric traffic).

For 2.7.0, change the default(!) to always send out packets with
ipi_ifindex = 0, to follow normal system interface selection rules.

Add a flag ``--multihome same-interface`` to restore the pre-2.7 behavior
of copying ipi_ifindex from ingress to egress packets.  There are use
cases for this, and we want to give users a chance to read the release
notes and adjust their setups to "not break after upgrading to 2.7.0".

Github: #855
Github: #554

v2: fix whitespace
v3: turn logic around - new default is "egress ifindex 0" now
v4: typo fixed in commit message
v5: fix invalid rst in Changes.rst

Change-Id: Id429241e1b17a8ff51d9019efc357c910f3bde4c
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Frank Lichtenheld <frank@lichtenheld.com>
Gerrit URL: https://gerrit.openvpn.net/c/openvpn/+/1383
Message-Id: <20251126130410.19091-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg34709.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
@cron2
Copy link
Contributor

cron2 commented Nov 26, 2025

So, the behaviour will change in 2.7_rc3 and subsequently in 2.7.0 - see the linked commit, which has been merged just now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants