This repository has been archived by the owner on Mar 29, 2024. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Until now, the original sender's source IP was always reused for
outgoing packets. Recipients sometimes don't know a route to that
IP (remote LAN), but they know how to reach the sender's VPN IP.
So this option allows to cover the following scenario:
host1 and host2 are connected via an OpenVPN server.
Each host has its own LAN (lan1, lan2) and they do not have static
routes to the remote LAN.
The game software on host1 sends its broadcasts to lan1 instead to
the VPN interface. A router in lan1 uses udp-broadcast-relay and his
own OpenVPN tunnel to the same OpenVPN server to forward
broadcasts into the VPN. These are received on host2, but hosts2's
replies never make it to host1, as there is no routing for the LAN
addresses of lan1 on host2 (the replies follow the default route and get lost).
Using -s with the VPN IP of host1, the replies of host2 will be
directed to the VPN interface and therefore reach their destination.