Possible Gaming Use?

[ndo360]

Greetings! I have come with a quite unique question for this software.

I have been trying to get the network created, and I managed to create a connection between myself and the lighthouse with relative ease. I am able to connect, and ping the lighthouse. (The lighthouse can also ping me.) What I wanted to do for the next step is to host a dedicated server for a video game, to see if once connected to the network I could see the server and join.

The server uses different ports, I have adjusted the adapter's metrics to be a lower number, and so far I am unable to see the lighthouse's server. Here are the configs below, is it not possible to host a server and have people join... or am I missing something? Thanks in advance!

P.S The game in question is 'Splinter Cell Chaos Theory'.

My Node.
# This is the nebula example configuration file. You must edit, at a minimum, the static_host_map, lighthouse, and firewall sections
# Some options in this file are HUPable, including the pki section. (A HUP will reload credentials from disk without affecting existing tunnels)

# PKI defines the location of credentials for this node. Each of these can also be inlined by using the yaml ": |" syntax.
pki:
  # The CAs that are accepted by this node. Must contain one or more certificates created by 'nebula-cert ca'
  ca: ca.crt
  cert: Noah.crt
  key: Noah.key
  #blacklist is a list of certificate fingerprints that we will refuse to talk to
  #blacklist:
  #  - c99d4e650533b92061b09918e838a5a0a6aaee21eed1d12fd937682865936c72

# The static host map defines a set of hosts with fixed IP addresses on the internet (or any network).
# A host can have multiple fixed IP addresses defined here, and nebula will try each when establishing a tunnel.
# The syntax is:
#   "{nebula ip}": ["{routable ip/dns name}:{routable port}"]
# Example, if your lighthouse has the nebula IP of 192.168.100.1 and has the real ip address of 100.64.22.11 and runs on port 4242:
static_host_map:
  "192.168.98.1": ["[REDACTED]:4242"]


lighthouse:
  # am_lighthouse is used to enable lighthouse functionality for a node. This should ONLY be true on nodes
  # you have configured to be lighthouses in your network
  am_lighthouse: false
  # serve_dns optionally starts a dns listener that responds to various queries and can even be
  # delegated to for resolution
  #serve_dns: false
  #dns:
    # The DNS host defines the IP to bind the dns listener to. This also allows binding to the nebula node IP.
    #host: 0.0.0.0
    #port: 53
  # interval is the number of seconds between updates from this node to a lighthouse.
  # during updates, a node sends information about its current IP addresses to each node.
  interval: 60
  # hosts is a list of lighthouse hosts this node should report to and query from
  # IMPORTANT: THIS SHOULD BE EMPTY ON LIGHTHOUSE NODES
  hosts:
    - "192.168.98.1"

# Port Nebula will be listening on. The default here is 4242. For a lighthouse node, the port should be defined,
# however using port 0 will dynamically assign a port and is recommended for roaming nodes.
listen:
  host: 0.0.0.0
  port: 4242
  # Sets the max number of packets to pull from the kernel for each syscall (under systems that support recvmmsg)
  # default is 64, does not support reload
  #batch: 64
  # Configure socket buffers for the udp side (outside), leave unset to use the system defaults. Values will be doubled by the kernel
  # Default is net.core.rmem_default and net.core.wmem_default (/proc/sys/net/core/rmem_default and /proc/sys/net/core/rmem_default)
  # Maximum is limited by memory in the system, SO_RCVBUFFORCE and SO_SNDBUFFORCE is used to avoid having to raise the system wide
  # max, net.core.rmem_max and net.core.wmem_max
  #read_buffer: 10485760
  #write_buffer: 10485760

# Punchy continues to punch inbound/outbound at a regular interval to avoid expiration of firewall nat mappings
punchy: true
# punch_back means that a node you are trying to reach will connect back out to you if your hole punching fails
# this is extremely useful if one node is behind a difficult nat, such as symmetric
punch_back: true

# Cipher allows you to choose between the available ciphers for your network.
# IMPORTANT: this value must be identical on ALL NODES/LIGHTHOUSES. We do not/will not support use of different ciphers simultaneously!
#cipher: chachapoly

# Local range is used to define a hint about the local network range, which speeds up discovering the fastest
# path to a network adjacent nebula node.
#local_range: "172.16.0.0/24"

# sshd can expose informational and administrative functions via ssh this is a
#sshd:
  # Toggles the feature
  #enabled: true
  # Host and port to listen on, port 22 is not allowed for your safety
  #listen: 127.0.0.1:2222
  # A file containing the ssh host private key to use
  # A decent way to generate one: ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N "" < /dev/null
  #host_key: ./ssh_host_ed25519_key
  # A file containing a list of authorized public keys
  #authorized_users:
    #- user: steeeeve
      # keys can be an array of strings or single string
      #keys:
        #- "ssh public key string"

# Configure the private interface. Note: addr is baked into the nebula certificate
tun:
  # Name of the device
  dev: nebula1
  # Toggles forwarding of local broadcast packets, the address of which depends on the ip/mask encoded in pki.cert
  drop_local_broadcast: false
  # Toggles forwarding of multicast packets
  drop_multicast: false
  # Sets the transmit queue length, if you notice lots of transmit drops on the tun it may help to raise this number. Default is 500
  tx_queue: 500
  # Default MTU for every packet, safe setting is (and the default) 1300 for internet based traffic
  mtu: 1300
  # Route based MTU overrides, you have known vpn ip paths that can support larger MTUs you can increase/decrease them here
  routes:
    #- mtu: 8800
    #  route: 10.0.0.0/16
  # Unsafe routes allows you to route traffic over nebula to non-nebula nodes
  # Unsafe routes should be avoided unless you have hosts/services that cannot run nebula
  # NOTE: The nebula certificate of the "via" node *MUST* have the "route" defined as a subnet in its certificate
  unsafe_routes:
    #- route: 172.16.1.0/24
    #  via: 192.168.100.99
    #  mtu: 1300 #mtu will default to tun mtu if this option is not sepcified


# TODO
# Configure logging level
logging:
  # panic, fatal, error, warning, info, or debug. Default is info
  level: info
  # json or text formats currently available. Default is text
  format: text

#stats:
  #type: graphite
  #prefix: nebula
  #protocol: tcp
  #host: 127.0.0.1:9999
  #interval: 10s

  #type: prometheus
  #listen: 127.0.0.1:8080
  #path: /metrics
  #namespace: prometheusns
  #subsystem: nebula
  #interval: 10s

# Nebula security group configuration
firewall:
  conntrack:
    tcp_timeout: 120h
    udp_timeout: 3m
    default_timeout: 10m
    max_connections: 100000

  # The firewall is default deny. There is no way to write a deny rule.
  # Rules are comprised of a protocol, port, and one or more of host, group, or CIDR
  # Logical evaluation is roughly: port AND proto AND (ca_sha OR ca_name) AND (host OR group OR groups OR cidr)
  # - port: Takes `0` or `any` as any, a single number `80`, a range `200-901`, or `fragment` to match second and further fragments of fragmented packets (since there is no port available).
  #   code: same as port but makes more sense when talking about ICMP, TODO: this is not currently implemented in a way that works, use `any`
  #   proto: `any`, `tcp`, `udp`, or `icmp`
  #   host: `any` or a literal hostname, ie `test-host`
  #   group: `any` or a literal group name, ie `default-group`
  #   groups: Same as group but accepts a list of values. Multiple values are AND'd together and a certificate would have to contain all groups to pass
  #   cidr: a CIDR, `0.0.0.0/0` is any.
  #   ca_name: An issuing CA name
  #   ca_sha: An issuing CA shasum

  outbound:
    # Allow all outbound traffic from this node
    - port: any
      proto: any
      host: any

  inbound:
    # Allow icmp between any nebula hosts
    - port: any
      proto: any
      host: any

    # Allow tcp/443 from any host with BOTH laptop and home group
#    - port: 443
#     proto: tcp
#      groups:
#        - laptop
#        - home

Lighthouse Node.
# This is the nebula example configuration file. You must edit, at a minimum, the static_host_map, lighthouse, and firewall sections
# Some options in this file are HUPable, including the pki section. (A HUP will reload credentials from disk without affecting existing tunnels)

# PKI defines the location of credentials for this node. Each of these can also be inlined by using the yaml ": |" syntax.
pki:
  # The CAs that are accepted by this node. Must contain one or more certificates created by 'nebula-cert ca'
  ca: ca.crt
  cert: lighthouse.crt
  key: lighthouse.key
  #blacklist is a list of certificate fingerprints that we will refuse to talk to
  #blacklist:
  #  - c99d4e650533b92061b09918e838a5a0a6aaee21eed1d12fd937682865936c72

# The static host map defines a set of hosts with fixed IP addresses on the internet (or any network).
# A host can have multiple fixed IP addresses defined here, and nebula will try each when establishing a tunnel.
# The syntax is:
#   "{nebula ip}": ["{routable ip/dns name}:{routable port}"]
# Example, if your lighthouse has the nebula IP of 192.168.100.1 and has the real ip address of 100.64.22.11 and runs on port 4242:
static_host_map:
  "192.168.98.1": ["[REDACTED]:4242"]


lighthouse:
  # am_lighthouse is used to enable lighthouse functionality for a node. This should ONLY be true on nodes
  # you have configured to be lighthouses in your network
  am_lighthouse: false
  # serve_dns optionally starts a dns listener that responds to various queries and can even be
  # delegated to for resolution
  #serve_dns: false
  #dns:
    # The DNS host defines the IP to bind the dns listener to. This also allows binding to the nebula node IP.
    #host: 0.0.0.0
    #port: 53
  # interval is the number of seconds between updates from this node to a lighthouse.
  # during updates, a node sends information about its current IP addresses to each node.
  interval: 60
  # hosts is a list of lighthouse hosts this node should report to and query from
  # IMPORTANT: THIS SHOULD BE EMPTY ON LIGHTHOUSE NODES
  hosts:
  #  - "192.168.98.1"

# Port Nebula will be listening on. The default here is 4242. For a lighthouse node, the port should be defined,
# however using port 0 will dynamically assign a port and is recommended for roaming nodes.
listen:
  host: 0.0.0.0
  port: 4242
  # Sets the max number of packets to pull from the kernel for each syscall (under systems that support recvmmsg)
  # default is 64, does not support reload
  #batch: 64
  # Configure socket buffers for the udp side (outside), leave unset to use the system defaults. Values will be doubled by the kernel
  # Default is net.core.rmem_default and net.core.wmem_default (/proc/sys/net/core/rmem_default and /proc/sys/net/core/rmem_default)
  # Maximum is limited by memory in the system, SO_RCVBUFFORCE and SO_SNDBUFFORCE is used to avoid having to raise the system wide
  # max, net.core.rmem_max and net.core.wmem_max
  #read_buffer: 10485760
  #write_buffer: 10485760

# Punchy continues to punch inbound/outbound at a regular interval to avoid expiration of firewall nat mappings
punchy: true
# punch_back means that a node you are trying to reach will connect back out to you if your hole punching fails
# this is extremely useful if one node is behind a difficult nat, such as symmetric
punch_back: true

# Cipher allows you to choose between the available ciphers for your network.
# IMPORTANT: this value must be identical on ALL NODES/LIGHTHOUSES. We do not/will not support use of different ciphers simultaneously!
#cipher: chachapoly

# Local range is used to define a hint about the local network range, which speeds up discovering the fastest
# path to a network adjacent nebula node.
#local_range: "172.16.0.0/24"

# sshd can expose informational and administrative functions via ssh this is a
#sshd:
  # Toggles the feature
  #enabled: true
  # Host and port to listen on, port 22 is not allowed for your safety
  #listen: 127.0.0.1:2222
  # A file containing the ssh host private key to use
  # A decent way to generate one: ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N "" < /dev/null
  #host_key: ./ssh_host_ed25519_key
  # A file containing a list of authorized public keys
  #authorized_users:
    #- user: steeeeve
      # keys can be an array of strings or single string
      #keys:
        #- "ssh public key string"

# Configure the private interface. Note: addr is baked into the nebula certificate
tun:
  # Name of the device
  dev: nebula1
  # Toggles forwarding of local broadcast packets, the address of which depends on the ip/mask encoded in pki.cert
  drop_local_broadcast: false
  # Toggles forwarding of multicast packets
  drop_multicast: false
  # Sets the transmit queue length, if you notice lots of transmit drops on the tun it may help to raise this number. Default is 500
  tx_queue: 500
  # Default MTU for every packet, safe setting is (and the default) 1300 for internet based traffic
  mtu: 1300
  # Route based MTU overrides, you have known vpn ip paths that can support larger MTUs you can increase/decrease them here
  routes:
    #- mtu: 8800
    #  route: 10.0.0.0/16
  # Unsafe routes allows you to route traffic over nebula to non-nebula nodes
  # Unsafe routes should be avoided unless you have hosts/services that cannot run nebula
  # NOTE: The nebula certificate of the "via" node *MUST* have the "route" defined as a subnet in its certificate
  unsafe_routes:
    #- route: 172.16.1.0/24
    #  via: 192.168.100.99
    #  mtu: 1300 #mtu will default to tun mtu if this option is not sepcified


# TODO
# Configure logging level
logging:
  # panic, fatal, error, warning, info, or debug. Default is info
  level: info
  # json or text formats currently available. Default is text
  format: text

#stats:
  #type: graphite
  #prefix: nebula
  #protocol: tcp
  #host: 127.0.0.1:9999
  #interval: 10s

  #type: prometheus
  #listen: 127.0.0.1:8080
  #path: /metrics
  #namespace: prometheusns
  #subsystem: nebula
  #interval: 10s

# Nebula security group configuration
firewall:
  conntrack:
    tcp_timeout: 120h
    udp_timeout: 3m
    default_timeout: 10m
    max_connections: 100000

  # The firewall is default deny. There is no way to write a deny rule.
  # Rules are comprised of a protocol, port, and one or more of host, group, or CIDR
  # Logical evaluation is roughly: port AND proto AND (ca_sha OR ca_name) AND (host OR group OR groups OR cidr)
  # - port: Takes `0` or `any` as any, a single number `80`, a range `200-901`, or `fragment` to match second and further fragments of fragmented packets (since there is no port available).
  #   code: same as port but makes more sense when talking about ICMP, TODO: this is not currently implemented in a way that works, use `any`
  #   proto: `any`, `tcp`, `udp`, or `icmp`
  #   host: `any` or a literal hostname, ie `test-host`
  #   group: `any` or a literal group name, ie `default-group`
  #   groups: Same as group but accepts a list of values. Multiple values are AND'd together and a certificate would have to contain all groups to pass
  #   cidr: a CIDR, `0.0.0.0/0` is any.
  #   ca_name: An issuing CA name
  #   ca_sha: An issuing CA shasum

  outbound:
    # Allow all outbound traffic from this node
    - port: any
      proto: any
      host: any

  inbound:
    # Allow icmp between any nebula hosts
    - port: any
      proto: any
      host: any

    # Allow tcp/443 from any host with BOTH laptop and home group
#    - port: 443
#     proto: tcp
#      groups:
#        - laptop
#        - home

Again if it turns out that this program wouldn't be able to support LAN emuation play then I understand. The reason I was drawn to it was due to the hole punching features, and had be believe it could be possible to host a mesh P2P network for playing older games.

If anyone helps, it would be much apprieated!

[ghost]

There is generally 3 levels of connectivity you want to consider:

Layer 2 (like a physical network, very few VPNs because it carries overhead while needed by very few applications)
Layer 3, Common broadcast domain (like nebula, and some other VPNs)
Layer 3, Different broadcast domain (like the internet, and some other VPNs)

Layer 2 would be a physical ethernet network, this is usually provided by a virtual device called TAP, where hardware addresses (MACs) are mapped to IPs over ARP.
Layer 3 is looking at it without the physical network, usually using a virtual device called TUN, nebula sits here.

Nebula does provide broadcast capabilities - check if your IPs are in the same subnet. (using a /24 subnet mask will give you all addresses in the last byte, e.g. 10.0.0.x/24, excluding x=0 and x=255)

Some games however will directly use ARP, you wouldn't be able to discover gameservers here. I happen to know you can still directly connect over the console if you want to play SCCT Versus, but you might be out of luck on Coop.

[ndo360]

@schittler Thanks for the detailed response!

It seems that it may use ARP to discover game sessions... however I will test later today by setting both interface metrics to one and confirm. (To ensure broadcasts are sent through the adapters.)

Also how do you connect through the console? There isn't a direct connect button when searching for a LAN session, so could you explain what console command that is used to directly connect?

Thanks again!

[ndo360]

@schittler Greetings again!
I just did a test, this time setting the adapter metric to one, and the server still wasn't visible in the server listing... Unsure what to do at the present moment that could fix this.

P.S. If you know the console command off hand, please do post it so I can give that a try. Cheers!

[jpmvferreira]

I'm also doing the exact same thing, my goal is to setup a nebula lighthouse on my raspberry pi at home and then connect all of my friends devices using nebula, so that i don't have to be the one who always hosts the server.

I'm pretty sure this would be possible using nebula, i did it with wireguard and it worked.

Also i know that there's multiple ciphers for nebula, which one is the least demanding on the CPU? My goal is to play videogames so the lighter the encryption the better.

[jpmvferreira]

After revisiting the issue #136 it appears that using cipher: chachapoly is better when you're running hardware that doesn't support AES in hardware, however it will be more expensive for normal machines that have AES built in. So i assume, since i haven't found any other cipher possible, that for gaming the best would be to use the default setting given that the machines will be communicating between each other (all with recent hardware of course) and the Raspberry Pi 4 will merely act as a lighthouse all the time, am i correct?

Also if you're not being able to use this game to show up in LAN, try to use direct connect. That happened to me quite often with wireguard and Stardew Valley or even Minecraft, for some reason the host doesn't show up on LAN servers, but if you perform direct connect it will work, if i had to guess it's the way that some games look for hosts that don't allow them to see everybody.

Also is there any setting we should tweak in the firewall section to achieve the biggest performance?

[wildardoc]

Am I mistaken or is there still a requirement to have the lighthouse on a completely external IP. If I'm understanding correctly the remote friends won't be able to connect to the devices you have on your internal network unless the raspberry pi can only be accessed via an external IP address. Unless you are using the unsafe routes options. I'm still trying to figure that configuration out.

…

On Fri, Jul 17, 2020 at 6:22 AM JPUnD ***@***.***> wrote: After revisiting the issue #136 <#136> it appears that using cipher: chachapoly is better when you're running hardware that doesn't support AES in hardware, however it will be more expensive for normal machines that have AES built in. So i assume, since i haven't found any other cipher possible, that for gaming the best would be to use the default setting given that the machines will be communicating between each other (all with recent hardware of course) and the Raspberry Pi 4 will merely act as a lighthouse all the time, am i correct? Also if you're not being able to use this game to show up in LAN, try to use direct connect. That happened to me quite often with wireguard and Stardew Valley or even Minecraft, for some reason the host doesn't show up on LAN servers, but if you perform direct connect it will work, if i had to guess it's the way that some games look for hosts that don't allow them to see everybody. Also is there any setting we should tweak in the firewall section to achieve the biggest performance? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#168 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIK3CW72EIRKGJYRUMJHMULR4AX7TANCNFSM4KI3BREA> .

[jpmvferreira]

I have an open port directed to my raspberry pi like i had with wireguard and it worked just fine, i haven't had the opportunity to test it with somebody else from the outside but that was my next step.

I have a free account for a dns which is pointing to my home IP address, as soon as somebody tries to connect to my IP using nebula the port 1337, which is the only i'm using for all nebula communication, will be forwarded to my Raspberry Pi and connection will be established.

Then what i assumed it was going to happen next is that my computer, where i'll be gaming, would punch a hole through the NAT and connect to all my friends, since i know all their ip addresses because i'm connected to the lighthouse aswell.

Is that not what's going to happen?

[wildardoc]

So the way it worked originally (I haven't followed up on any changes since official launch) is the lighthouse knows how it talks to someone. When a computer requests a connection, the lighthouse says here this is how I talk to them try that. If your internal computers are talking to the lighthouse by an internal lan ip:port then the lighthouse will give the external user the internal connection information. Thus your internal computers could talk out to external but the external computers could not talk to the internal computers if your lighthouse isn't on an external connection for all the devices that connect to it. This is where the digital ocean or some related service is useful. I think (I'm a very old c programmer not a network admin), if you force the main computer to go out to the internet and then back in to get a connection to the lighthouse it might work. I'm not certain of that though.

…

On Fri, Jul 17, 2020 at 1:25 PM JPUnD ***@***.***> wrote: I have an open port directed to my raspberry pi like i had with wireguard and it worked just fine, i haven't had the opportunity to test it with somebody else from the outside but that was my next step. I have a free account for a dns which is pointing to my home IP address, as soon as somebody tries to connect to my IP using nebula the port 1337, which is the only i'm using for all nebula communication, will be forwarded to my Raspberry Pi and connection will be established. Then what i assumed it was going to happen next is that my computer, where i'll be gaming, would punch a hole through the NAT and connect to all my friends, since i know all their ip addresses because i'm connected to the lighthouse aswell. Is that not what's going to happen? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#168 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIK3CW5TB5TU3F7F6EVMWYLR4CJQTANCNFSM4KI3BREA> .

[jpmvferreira]

That's a good point, i probably won't have any time that soon to test that out, but as soon as i figure out how it works i'll report back, or hopefully the devs show up and shine some light on the matter.

[johnmaguire]

I'm closing this issue out as stale. If you continue to experience issues using Nebula please open a new ticket. Thanks!