Immediately forward packets received on the nebula TUN device from self to self #501
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nbrownus
reviewed
Apr 18, 2022
inside.go
Outdated
| if fwPacket.RemoteIP == f.myVpnIp { | ||
| _, err := f.readers[q].Write(packet) |
There was a problem hiding this comment.
In group discussion, we think this should be limited to macos only and leave the old behavior for all other oss
There was a problem hiding this comment.
Wrote it up with a const, in the hopes that a const gives the compiler the best opportunity to optimize the code path as it sees fit. Happy to implement the o/s specific path other ways if desired.
…destination of our Nebula VPN IP right back out that same TUN device.
brad-defined
force-pushed
the
forward-self
branch
from
aaf5f05
to
5987ca4
Compare
|
Also fixes issue #38 |
|
FWIW, I confirmed that on MacOS the conditional is optimized away - I generated the output with the command |
wadey
approved these changes
Jun 27, 2022
johnmaguire
added a commit
to johnmaguire/nebula
that referenced
this pull request
Jan 18, 2023
Fixes slackhq#493. This is borrowing the fix from slackhq#501 which was originally scoped to use this behavior for all OSes. During review, it was scoped down to just macOS which was known to be affected. Lacking support for FreeBSD at the time was an oversight. There may be other OSes which are affected by this bug, but we will wait until we get reports to patch them.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
PR #192 updated Nebula to immediately drop packets read by the Nebula TUN device and destined to the local Nebula VPN IP.
On Linux machines, the local route table will send packets destined to the local nebula VPN IP through the loopback device, bypassing Nebula all together and permitting the packets to flow. On my mac, the route table instead sends these packets through the Nebula TUN device, where they are immediately dropped.
On my linux lighthouse - VPN IP routes to loopback device:
On my mac - VPN IP routes to utun0, which is my Nebula TUN device:
This diff updates Nebula to immediately forward these types of packets right back out the TUN device. This change will make my Mac (and presumably every other machine that routes the way Mac does) behave the same as Linux machines.
I also considered an alternative approach of having the locally destined packet be processed by the rest of the Nebula stack. This alternative approach would ensure the Nebula firewall rules are applied, for instance. However, this alternative approach would not behave the same as Linux (which does not apply the Nebula firewall rules to these local connections, as they bypass Nebula entirely), and would also require Nebula to handshake with itself locally - something which is not permitted elsewhere in the code for different reasons.
I also tried to address the issue by manually adding a route for my Nebula IP to route through the loopback device. This approach didn't reliably fix the issue for me - sometimes it worked, sometimes my manual route rule was applied after Nebula's route rules, or for some reason still sent my packets to the Nebula TUN device.
This PR fixes issue #493