-
Notifications
You must be signed in to change notification settings - Fork 3.2k
fix error "UDPv6: Can't assign requested address (code=49)" #554
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
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
|
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: 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 |
|
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. |
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>
|
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. |
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:
For details, see these Wiki articles: