Tunnel Manager Change

Althea L1 Development
1

Timeframe for A/B release

  • Alpha 4

    • Change made
    • Backward compat with Alpha 3

  • Alpha 5

    • Backward compat with Alpha 3 removed

Change

Previous TunnelManager behavior

  1. Check neighbors, local peers etc
  2. Create WG tunnel identified by local/internet (non-mesh) IP addresses
  3. Send LocalIdentity to them, containing identity + wg port of interface
  4. On other end, LocalIdentity is received and wg interface is created, with endpoint being IP which the connection request is received on and the wg port from the LocalIdentity
  5. The other end sends back their own LocalIdentity
  6. The requester sets the wg tunnel with the appropriate endpoint via the same method above

New TunnelManager behavior

  1. Check neighbors, local peers etc
  2. Create WG tunnel identified by local/internet (non-mesh) IP addresses
  3. Send Identity to them, containing identity + wg port of interface
  4. On other end, Identity is received and wg interface is created, with endpoint being IP which the connection request is received on and the wg port from the LocalIdentity with no endpoint
  5. The other end sends back their own LocalIdentity
  6. The requester sets the wg tunnel with the appropriate endpoint via the same method body
  7. the requester’s wg starts a handshake, and when the other end recieves the packet, it will set the endpoint to the proper address

Backwards compat TunnelManager behavior

  1. Check neighbors, local peers etc

  2. Create WG tunnel identified by local/internet (non-mesh) IP addresses

  3. Send LocalIdentity to them, containing identity + wg port of interface random port

  4. a. (other end is old rita or new rita) On other end, LocalIdentity is received and wg interface is created, with endpoint being IP which the connection request is received on and the wg port from the LocalIdentity (as port is random, it doesn’t work)
    b. (other end is new rita) On other end, Identity is received and wg interface is created, with endpoint being IP which the connection request is received on and the wg port from the LocalIdentity with no endpoint

  5. The other end sends back their own LocalIdentity

  6. The requester sets the wg tunnel with the appropriate endpoint via the same method body

  7. the requester’s wg starts a handshake, and when the other end recieves the packet, it will set the endpoint to the proper address

2

What is the purpose of this change?

3

Fixes the issue where you can’t have 2 gateways behind a single ISP modem/external IP address

4

Can you sum up what was causing the issue? Would be interested.

5

mainly its caused by step 2

  1. Create WG tunnel identified by local/internet (non-mesh) IP addresses

Because when we send a hello to someone, we don’t know their mesh IP address yet, so we have to have to create a tunnel which we internally identify by their non mesh ip
If there are 2 nodes behind the same non mesh ip, we will have them both use the same tunnels

6

which we internally identify by their non mesh ip

Their link-local IP?

7

link local or internet ip, in the case of exits and gateways