Is there a need to Bind Nebula address when using multiple virtual IP Addresses? #1000

johnjces · 2023-10-20T01:58:23Z

johnjces
Oct 20, 2023

BTW, I did Google and search github and etc. and never landed on anything regarding this. I'm certain there is somethign somewhere, but I didn't get the correct search i suppose.

I am in the process of moving a bunch of specialty software,Nebula being one of them, to a Ubuntu box which has multiple virtual IP addresses. Actual physical address is 192.168.0.45. I had Nebula running successfully on a Raspberry Pi with a physical IP address of 192.168.0.15. Since I am lazy, I didn't want to redo any static routes that I had set on my router so I created a virtual IP of 192.168.0.15 on the Ubuntu box. It works well as I have unsafe routes on two LANs connected via Nebula miles apart. My T-LAN sees the WM-LAN (lighhouse) and vice- versa which is awesome. This has worked well for a coujple years (other than forgetting about the certificate expiry a few times), and works well on the Ubuntu box. EXCEPT:

I just "installed" the Windows version on my Win 11 Pro laptop, adding the unsafe routes of my LANs. The T-LAN, still on a raspberry pi with a physcial interface of 1.30, works great. I can see it's LAN just fine! But I cannot see the WM-LAN (Lighthouse) at all. I can ping and access the 1.15 address, the physical IP of 1.45 and one other virtual IP I have which I can't recall right now why I have it.

What did I miss in my config.yml file? There is no unsafe route in my cert for my laptop as who knows what LAN I might be on. ALso my IP of the laptop was no where near my WM-LAN (lighthouse) IP. Do I or should I set the virtual IP under:
listen:
Hashtag To listen on both any ipv4 and ipv6 use "::"
host: 192.168.0.15

...and should I also add my virtual IP to:
outbound:
Hashtag Allow all outbound traffic from this node
- port: any
proto: any
host: 192.168.0.15

This is the only thing I can think of that might be messing up my windows ability to see my unsafe route (LAN).

Thanks so much for any thoughts. Again, all is working well with a static route on my router (192.168.0.20) pointing to 0.15 for the current two node setup. One cloent and one lighthouse. Adding the windows Nebula in things are different. It can access on LAN but not the other,

Thanks so much for any help!

John

Answered by johnjces

Feb 26, 2024

It has been several weeks of life and work and I have been spotty at best on my issue, It is my screwup that I seem to finally have discovered. Getting old and trying to keep up and makes sense of some of this tech stuff and remembering some of the things that I did and need to be done to ensure things are working can be difficult. Enough of my excuses, Let me say that I am sorry I put you all through this excercise. Oh me...

My two Ubuntu instances that are hosting Nebula, one a lighthouse the other the client, did not have the firewall enabled and even though I did the post routing stuff, it certainly did nothing. It is no wonder that I couldn't get to the other devices on the lans. I r…

View full answer

johnmaguire · 2023-10-20T14:23:28Z

johnmaguire
Oct 20, 2023
Maintainer

Hi @johnjces - can you please post your config.yml's and log files from each host, removing any sensitive material such as the pki.key field? Thanks!

2 replies

johnjces Oct 21, 2023
Author

Thanks John!

I am traveling and I can certainly do that hopefully sometime Sunday night 10/22 (or 10/23) if all goes to plan! At what level would you like logging?

John

johnmaguire Oct 21, 2023
Maintainer

Sounds good. The default info level should be fine.

johnjces · 2023-10-24T00:29:37Z

johnjces
Oct 24, 2023
Author

@johnmaguire

THANK-YOU!

Herein is a quick logfile and my config.yml file. As a reminder, I can access all devices on my 192.168.1.0/24 LAN and I can only access the lighthouse via local IP of 192.168.0.15 or 192168.98.1, the VPN IP on this Windows 11 Pro PC. Not seeing anything off in the log and I'm not seeing anything off in my config file but I am still learning! Also as a reminder, when I am local on either LAN I can see all devices. Just can't see the 0.0/24 LAN when away and on the WIndows Laptop. I reiterated this as sometimes when I try to explain things on forums I am not clear or confusing.

If I missed something, please let me know. Do you need any files from the lighthouse (192.168.0.0/24 node) or the Other lan, (192.168.1.0/24) node?

Uh oh... config.yml not displaying correctly even using the code tag. I had to remove all comments that had a hastag. I hope I didn't remove something necessary for your review.

logfile:

time="2023-10-23T16:58:53-07:00" level=info msg="Firewall rule added" firewallRule="map[caName: caSha: direction:outgoing endPort:0 groups:[] host:any ip: localIp: proto:0 startPort:0]"
time="2023-10-23T16:58:53-07:00" level=info msg="Firewall rule added" firewallRule="map[caName: caSha: direction:incoming endPort:0 groups:[] host:any ip: localIp: proto:0 startPort:0]"
time="2023-10-23T16:58:53-07:00" level=info msg="Firewall started" firewallHash=498215dec4e5687a2353f51c10838c113bd1af35ef72b8e8c9f536986ada5417
2023/10/23 16:58:53 Using existing driver 0.14
2023/10/23 16:58:53 Creating adapter
time="2023-10-23T16:58:54-07:00" level=warning msg="route MTU is not supported in windows" route="{1300 100 192.168.0.0/24 192.168.98.1 true}"
time="2023-10-23T16:58:54-07:00" level=warning msg="route MTU is not supported in windows" route="{1300 100 192.168.1.0/24 192.168.98.3 true}"
time="2023-10-23T16:58:54-07:00" level=info msg="Main HostMap created" network=192.168.98.4/24 preferredRanges="[]"
time="2023-10-23T16:58:54-07:00" level=info msg="punchy enabled"
time="2023-10-23T16:58:54-07:00" level=info msg="Loaded send_recv_error config" sendRecvError=always
time="2023-10-23T16:58:54-07:00" level=info msg="Nebula interface is active" boringcrypto=false build=1.7.2 interface=nebula1 network=192.168.98.4/24 udpAddr="[::]:4242"
time="2023-10-23T16:58:54-07:00" level=info msg="DNS results changed for host list" newSet="map[24.119.132.46:4242:{}]" origSet="&map[]"
time="2023-10-23T16:58:54-07:00" level=info msg="Handshake message sent" handshake="map[stage:1 style:ix_psk0]" initiatorIndex=1993547907 localIndex=1993547907 remoteIndex=0 udpAddrs="[24.119.132.46:4242]" vpnIp=192.168.98.1
time="2023-10-23T16:58:54-07:00" level=info msg="Handshake message received" certName=lighthouse durationNs=379954700 fingerprint=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx handshake="map[stage:2 style:ix_psk0]" initiatorIndex=1993547907 issuer=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx remoteIndex=1993547907 responderIndex=2709609364 sentCachedPackets=2 udpAddr="24.119.132.46:4242" vpnIp=192.168.98.1
time="2023-10-23T16:58:57-07:00" level=info msg="Handshake message sent" handshake="map[stage:1 style:ix_psk0]" initiatorIndex=2162105081 localIndex=2162105081 remoteIndex=0 udpAddrs="[76.29.210.210:4242 192.168.1.30:4242]" vpnIp=192.168.98.3
time="2023-10-23T16:58:58-07:00" level=info msg="Handshake message received" certName=client durationNs=1325777800 fingerprint=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx handshake="map[stage:2 style:ix_psk0]" initiatorIndex=2162105081 issuer=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx remoteIndex=2162105081 responderIndex=4118309518 sentCachedPackets=6 udpAddr="76.29.210.210:4242" vpnIp=192.168.98.3
time="2023-10-23T16:59:01-07:00" level=info msg="Handshake timed out" durationNs=7113469800 handshake="map[stage:1 style:ix_psk0]" initiatorIndex=891778952 localIndex=891778952 remoteIndex=0 udpAddrs="[]" vpnIp=192.168.98.255
time="2023-10-23T16:59:08-07:00" level=info msg="Handshake timed out" durationNs=6831740200 handshake="map[stage:1 style:ix_psk0]" initiatorIndex=3450004011 localIndex=3450004011 remoteIndex=0 udpAddrs="[]" vpnIp=192.168.98.255
time="2023-10-23T16:59:16-07:00" level=info msg="Handshake timed out" durationNs=6884999200 handshake="map[stage:1 style:ix_psk0]" initiatorIndex=1416313210 localIndex=1416313210 remoteIndex=0 udpAddrs="[]" vpnIp=192.168.98.255
time="2023-10-23T16:59:23-07:00" level=info msg="Handshake timed out" durationNs=7190091400 handshake="map[stage:1 style:ix_psk0]" initiatorIndex=922624213 localIndex=922624213 remoteIndex=0 udpAddrs="[]" vpnIp=192.168.98.255
time="2023-10-23T17:00:23-07:00" level=info msg="Handshake timed out" durationNs=6886443900 handshake="map[stage:1 style:ix_psk0]" initiatorIndex=2229027223 localIndex=2229027223 remoteIndex=0 udpAddrs="[]" vpnIp=192.168.98.255
time="2023-10-23T17:01:23-07:00" level=info msg="Handshake timed out" durationNs=7087110400 handshake="map[stage:1 style:ix_psk0]" initiatorIndex=2256744551 localIndex=2256744551 remoteIndex=0 udpAddrs="[]" vpnIp=192.168.98.255

config.yml

pki:
  ca: C:\Users\jjarrett\Applications\WinNebulaVPN\ca.crt
  cert: C:\Users\jjarrett\Applications\WinNebulaVPN\winclient.crt
  key: C:\Users\jjarrett\Applications\WinNebulaVPN\winclient.key

static_host_map:
 "192.168.98.1": ["mydomain.com:4242"]
 #"192.168.98.1": []

lighthouse:
  interval: 60

  am_lighthouse: false

  hosts:
    - "192.168.98.1"

listen:
  host: 0.0.0.0
  port: 4242

punchy: true

punch_back: true

punchy:
  respond: false
  delay: 1s
relay:
  am_relay: false
  use_relays: true

tun:
  dev: nebula1
  drop_local_broadcast: false
  drop_multicast: false
  tx_queue: 500
  mtu: 1300
  
  routes:

  unsafe_routes:
    - route: 192.168.0.0/24
      via: 192.168.98.1
      mtu: 1300
      metric: 100
    - route: 192.168.1.0/24
      via: 192.168.98.3
      mtu: 1300
      metric: 100

logging:
  level: info
  format: text

firewall:
  conntrack:
    tcp_timeout: 120h
    udp_timeout: 3m
    default_timeout: 10m
    max_connections: 100000

  outbound:
    - port: any
      proto: any
      host: any

  inbound:
    - port: any
      proto: any
      host: any

0 replies

johnjces · 2023-10-24T00:50:20Z

johnjces
Oct 24, 2023
Author

Here is the lighthouse config.yml with hashtags/comments removed. This is the 192.168.0.0/24 LAN that I cannot see except for the box nebula is running.

pki:
  ca:   /opt/NebulaVPN/ca.crt
  cert: /opt/NebulaVPN/lighthouse.crt
  key:  /opt/NebulaVPN/lighthouse.key

static_host_map:
  "192.168.98.1": ["mydomain.com:4242"]

lighthouse:
  interval: 60

  am_lighthouse: true

  hosts:

listen:
  host: 192.168.0.15
  port: 4242

punchy:
  punch: true
  respond: true
  delay: 1s

relay:
  am_relay: false
  use_relays: true

tun:
  dev: nebula1
  drop_local_broadcast: false
  drop_multicast: false
  tx_queue: 500
  mtu: 1300
  routes:
  unsafe_routes:
    - route: 192.168.1.0/24
      via: 192.168.98.3

logging:
  level: info
  format: text

firewall:
  conntrack:
    tcp_timeout: 120h
    udp_timeout: 3m
    default_timeout: 10m
    max_connections: 100000

  outbound:
    - port: any
      proto: any
      host: any

  inbound:
    - port: any
      proto: any
      host: any

0 replies

johnmaguire · 2023-10-25T13:27:41Z

johnmaguire
Oct 25, 2023
Maintainer

Thanks @johnjces - for future reference, you can use three backticks (```) to encapsulate a multi-line code block. I've gone ahead and edited your comments to include these - I hope you do not mind.

Just can't see the 0.0/24 LAN when away and on the WIndows Laptop. I reiterated this as sometimes when I try to explain things on forums I am not clear or confusing.

Thanks for reiterating and sharing the configs. Next time you are away, and this unsafe route is not working, can you run ipconfig? I'd like to know what the LAN subnet for the network you're on is. If you're on a network that uses 192.168.0.0/24 as its IP space, you'll have a conflict when you attempt to add the Nebula unsafe route.

0 replies

johnjces · 2023-10-25T16:28:00Z

johnjces
Oct 25, 2023
Author

@johnmaguire
Thanks John!

I knew that and ensured when I connected, when I first wrote my question above, (I was away from home) that I was on my Verizon phone's hotspot with wireless off connected only to Verizon's internet and had a local IP of no where near 192.168.0.0/24 or 192.168.1.0/24. The lan I was on at the time, before connecting to Verizon was 192.168.1.0/24. But was no where near that and had no difficulty seeing my 1.0/24 lan. FWIW, I set up the Windows Nebula when I was away and after several days trying to figure it out, wrote the post.

When I did the configs and yml files for posting, I did do that from home on my 192.168.0.0 network but again connected via my phone's hotspot using only the Verizon network internet and checked my local IP using ipconfig /all and it again was not anywhere near my lan with 192.168.0.0/24 or 192.168.1.0/24.

Is there something I was missing in setting up my certificates? Command line switches?

Ugh! Any other thoughts? And again, thank-you!

John

0 replies

johnmaguire · 2023-10-25T17:13:49Z

johnmaguire
Oct 25, 2023
Maintainer

Hi @johnjces -

To be honest, I'm struggling to sort out what your network looks like, and what you're trying to do.

I was on my Verizon phone's hotspot with wireless off connected only to Verizon's internet and had a local IP of no where near 192.168.0.0/24 or 192.168.1.0/24.

Regardless of your actual IP address, we need to know what subnet the ISP is advertising. In any case, please fetch the ipconfig /all output the next time this issue occurs.

The lan I was on at the time, before connecting to Verizon was 192.168.1.0/24. But was no where near that and had no difficulty seeing my 1.0/24 lan.

I want to make sure I'm understanding you correctly here. Before connecting to Verizon, you were on a LAN that used 192.168.1.0/24 as its IP space. This LAN is different from the network you were exposing via unsafe_routes. The unsafe_routes subnet was also 192.168.1.0/24, and you were able to talk to devices through the unsafe_routes feature?

This doesn't sound right, so I'd love to understand more about the behavior you're seeing. For example, when there are IP address conflicts between your local LAN and your unsafe_routes subnet, which device is your node speaking with? Again, ipconfig /all output will be helpful to understand what's happening here.

When I did the configs and yml files for posting, I did do that from home on my 192.168.0.0 network but again connected via my phone's hotspot using only the Verizon network internet and checked my local IP using ipconfig /all and it again was not anywhere near my lan with 192.168.0.0/24 or 192.168.1.0/24.

I do not understand this statement. You say, "I did do that from on my 192.168.0.0 network" but then you say "but again connected via my phone's hotspot using only the Verizon network internet." How can you be connected to your local 192.168.0.0 network if you're also only connected to your phone's hotspot on the Verizon network?

Also, I just want to take a moment to clarify some context from your original message:

I am in the process of moving a bunch of specialty software,Nebula being one of them, to a Ubuntu box which has multiple virtual IP addresses. Actual physical address is 192.168.0.45. I had Nebula running successfully on a Raspberry Pi with a physical IP address of 192.168.0.15. Since I am lazy, I didn't want to redo any static routes that I had set on my router so I created a virtual IP of 192.168.0.15 on the Ubuntu box.

OK, so far so good. You were running Nebula on a Raspberry Pi (192.168.0.15), and are migrating to an Ubuntu machine (192.168.0.45) which has many virtual addresses, including that of your old Pi. Is this the machine that's exposing 192.168.0.0/24 via unsafe_routes?

It works well as I have unsafe routes on two LANs connected via Nebula miles apart. My T-LAN sees the WM-LAN (lighhouse) and vice- versa which is awesome. This has worked well for a coujple years (other than forgetting about the certificate expiry a few times), and works well on the Ubuntu box.

When you refer to T-LAN, I assume this is your 192.168.0.0/24 LAN. When you refer to WM-LAN, I assume this is 192.168.1.0/24. It sounds like your WM-LAN is exposed via unsafe_routes by your Lighthouse, correct? When you say this "works well on the Ubuntu box," you mean that your Ubuntu machine can access resources on the 192.168.1.0/24 subnet being exposed by the Lighthouse.

EXCEPT: I just "installed" the Windows version on my Win 11 Pro laptop, adding the unsafe routes of my LANs. The T-LAN, still on a raspberry pi with a physcial interface of 1.30, works great. I can see it's LAN just fine! But I cannot see the WM-LAN (Lighthouse) at all. I can ping and access the 1.15 address, the physical IP of 1.45 and one other virtual IP I have which I can't recall right now why I have it

You have completely lost me here...

You have a new Windows laptop, and it is trying to access both unsafe_routes (referred to as T-LAN and WM-LAN, and exposed by your Ubuntu VM and Lighthouse, respectively.)

But then you mention your Raspberry Pi has a physical interface of 1.30. Previously, you mentioned it had an IP address of 192.168.0.15. So are you saying you have physically moved it from your T-LAN (192.168.0.0/24) to your WM-LAN (192.168.1.0/24)? Or does it now exist on an entirely separate (third) LAN, which also uses 192.168.1.0/24?

When you say it "the T-LAN [...] works great" on the Raspberry Pi, do you mean that it is able to access the 192.168.0.0/24 subnet, as exposed by your new Ubuntu machine?

You then say that "I cannot see the WM-LAN (Lighthouse) at all" - my understanding is that WM-LAN is 192.168.1.0/24. If the Raspberry Pi has a physical address of 192.168.1.30, why does it need to use unsafe_routes to access this LAN? It sounds like it is physically present on the LAN.

I don't know what to make of the comments about which hosts you can ping, because I don't understand the network topology of this Raspbbery Pi at this point, or how it fits into your Windows issues...

As for whether your certificates are correct, your nodes that are providing unsafe_routes to other devices need to have that subnet described in their certificate. You can verify this with the nebula-cert print command.

5 replies

johnjces Oct 25, 2023
Author

Oh me! As I mentioned before I have a heck of a time in forums describing what I'm doing and making it understandable. John, give me some time to sort this all out and better describe (somehow) how this is all configured. But a couple of quick clarifications: (I hope helps and is clear)

The raspberry pi is no longer in the equation on the WMLAN. Removed from service. The Ubuntu box took over it's IP address of 0.15.

When local at either location, I can "see", i.e., http, ping, https, SSH and etc. anything on the other (remote) network from any machine on the local network. Remote FreePBX, IP Phones, router, home automation, RAID storage, printers and everything I may need to control or fix. I have a proper static route applied on my router/gateway/firewall at the locations pointing to the correct-local Nebula VPN Device OR Virtual IP.

It's the WIN10 laptop when away and with some good, (not a 0.0 or 1.0 IP address being assigned), I.E. 192.168.150.233, or 172.16.4.54. that I cannot see the 192.168.0.0/24 LAN, the WMLAN, (Lighthouse). I can 'see" everything on the 192.168.1.0/24 LAN the TLAN.

My WMLAN is 192.168.0.0/24 - Nebula IP: 192.168.98.1 (Lighthouse). The LAN address of the Nebula VPN, (virtual) is 192.168.0.15. This is the LAN that I cannot access from my Win10 laptop. It has a Static WAN IP. I can "see" nebula at 192.168.0.15 on Ubuntu.

My TLAN is 192.168.1.0/24 - Nebula IP 192.168.98.3 (Client). Dynamic WAN IP. (DDNS) I "see" this entire LAN. My Nebula physical IP on a raspberry pi on the TLAN is 192.168.1.30. I have yet to migrate away from the RPi on the TLAN.

My Windows 10 Laptop local IP address when trying to access my WMLAN has been anything other than 192.168.0.X AND/OR 192.168.1.X. Nebula IP IS 192.168.98.4.. I will do an ipconfig and post after this.

I hope this makes some semblance of sense! LOL!

More to follow....

John

johnjces Oct 25, 2023
Author

Here is a tracert and an ipconfig with Nebula running.

Microsoft Windows [Version 10.0.22621.2428]
(c) Microsoft Corporation. All rights reserved.

C:\Users\jjarrett>tracert 192.168.1.25

Tracing route to TUCSON-SERVERC [192.168.1.25]
over a maximum of 30 hops:

  1    82 ms    73 ms    79 ms  192.168.98.3
  2    86 ms    68 ms    76 ms  TUCSON-SERVERC [192.168.1.25]

Trace complete.

C:\Users\jjarrett>tracert 192.168.0.165

Tracing route to 192.168.0.165 over a maximum of 30 hops

  1   141 ms   127 ms    81 ms  JCITS-SERVERA [192.168.98.1]
  2     *        *        *     Request timed out.
  3     *        *     ^C
C:\Users\jjarrett>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : Dell-Laptop
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No

Unknown adapter nebula1:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Nebula Tunnel
   Physical Address. . . . . . . . . :
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.98.4(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter vEthernet (Default Switch (Wi-Fi)):

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter
   Physical Address. . . . . . . . . : 00-15-5D-6F-37-D6
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::87e3:c01f:c1b:dfe0%29(Preferred)
   IPv4 Address. . . . . . . . . . . : 172.26.0.1(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 486544733
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-2A-D7-97-4B-C4-03-A8-9C-49-E7
   NetBIOS over Tcpip. . . . . . . . : Enabled

Wireless LAN adapter Local Area Connection* 1:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Wi-Fi Direct Virtual Adapter
   Physical Address. . . . . . . . . : C4-03-A8-9C-49-E8
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

Wireless LAN adapter Local Area Connection* 2:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Wi-Fi Direct Virtual Adapter #2
   Physical Address. . . . . . . . . : C6-03-A8-9C-49-E7
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

Wireless LAN adapter Wi-Fi:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel(R) Wi-Fi 6E AX211 160MHz
   Physical Address. . . . . . . . . : C4-03-A8-9C-49-E7
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.53.59(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Wednesday, October 25, 2023 3:02:21 PM
   Lease Expires . . . . . . . . . . : Wednesday, October 25, 2023 4:02:20 PM
   Default Gateway . . . . . . . . . : 192.168.53.100
   DHCP Server . . . . . . . . . . . : 192.168.53.100
   DNS Servers . . . . . . . . . . . : 192.168.53.100
   NetBIOS over Tcpip. . . . . . . . : Enabled

johnmaguire Jan 24, 2024
Maintainer

@johnjces - I'm sorry this slipped my mind, and I'm not sure if you're still working on it. These two bits appear most relevant:

time="2023-10-23T16:58:54-07:00" level=warning msg="route MTU is not supported in windows" route="{1300 100 192.168.0.0/24 192.168.98.1 true}"
time="2023-10-23T16:58:54-07:00" level=warning msg="route MTU is not supported in windows" route="{1300 100 192.168.1.0/24 192.168.98.3 true}"


C:\Users\jjarrett>tracert 192.168.1.25

Tracing route to TUCSON-SERVERC [192.168.1.25]
over a maximum of 30 hops:

  1    82 ms    73 ms    79 ms  192.168.98.3
  2    86 ms    68 ms    76 ms  TUCSON-SERVERC [192.168.1.25]

Trace complete.

C:\Users\jjarrett>tracert 192.168.0.165

Tracing route to 192.168.0.165 over a maximum of 30 hops

  1   141 ms   127 ms    81 ms  JCITS-SERVERA [192.168.98.1]
  2     *        *        *     Request timed out.
  3     *        *     ^C

It looks like routes for 192.168.0.0/24 and 192.168.1.0/24 are both configured on the Windows machine. It also looks like you can reach 192.168.98.1 (you can verify by pinging it directly.) However, the route through 192.168.98.1 for 192.168.0.165/24 seems to be failing. I would hazard a guess that this has to do with how 192.168.98.1 is configured. Can you share how you configured that machine to act as a router for the subnet?

johnjces Jan 25, 2024
Author

Thank-you so much!

I gave up on trying to fix it as I thought that I was out of bounds in some way on the forum or I was not communicating myself clearly due to the angst I felt in your post of October 25th. And the title of this post has nothing to do with what's happening even though I thought it might. I do have a hard time communicating what I should say... obviously. I don't mean to be "that guy".

As far as the MTU, that is set in the config.yml (AFAIK), I could remove it from my windows client config.yml by entering nothing or changing it. But as the warning states, the MTU is not supported in a Windows route. I didn't know it was supported in a Linux route. And just a warning?

All I know is that I have one lighthouse and one client running on Ubuntu that bridges my two LANS across the state. It works perfectly LAN to LAN. I can get to any device at any time no matter what location I am at. From lighthouse LAN in one city to client LAN in another city or client LAN to lighthouse LAN. From my laptop I can flawlessly access any device on the 192.168.1.0/24 LAN via 192.168.1.98.3

To understand more what you need as far as configuring the lighthouse on 192.168.98.1 and on 192.168.0.0/24. There is a static route added to my router which points to 192.168.0.15 which is a virtual IP on the Ubuntu. Similar to the Client Nebula which is on a virtual IP of 192.168.1.30 and of course I can see all devices on that LAN.

I do have iptables -t nat -A POSTROUTING -s 192.168.98.0/24 -o eth0 -j MASQUERADE on both client and lighthouse and I have it "sticking" on reboots.

SO... I really have no clue. I'm not sure where to look as something is, I am certain, not configured correctly somewhere and the only thing I can figure is on the Windows laptop Nebula setup.

Thanks so much for reaching out again!

John

johnjces Jan 25, 2024
Author

After 'playing' with this again... Do I need to add a static route to each ubuntu box running nebula for my off network (roaming i.e. laptops) which can only use the ubuntu box as a router? Could that be my issue? My LAN routers have the proper static routes added.
But I also thought that the iptables -t nat -A POSTROUTING -s 192.168.98.0/24 -o eth0 -j MASQUERADE took care of Nebula accessing the devices on the lan since unsafe routes are set and not going through the LAN router/gateway where the route is added. I hope that made sense. I don't know how else to verbalize it.

John

johnmaguire · 2024-02-01T17:38:51Z

johnmaguire
Feb 1, 2024
Maintainer

@johnjces

Thanks again for taking the time to explain your network setup. I do apologize for any frustration you may have picked up on in my tone - it is not directed at you, but at my failure to understand the scenario.

I've tried to diagram your network topology. Does this look right? In particular, do I have it correct that a Raspberry Pi is acting as your unsafe_routes router in TLAN, with IP 192.168.1.30 (LAN), 192.168.98.3 (Nebula), routing for 192.168.1.0/24?

Also, you've mentioned that if your Windows machine is in the TLAN, instead of remote (e.g. the Verizon hotspot), then it can access the WMLAN, correct?

Can you share the output of iptables -vnL on both the Lighthouse router and Raspberry Pi router?

0 replies

johnjces · 2024-02-26T05:10:53Z

johnjces
Feb 26, 2024
Author

It has been several weeks of life and work and I have been spotty at best on my issue, It is my screwup that I seem to finally have discovered. Getting old and trying to keep up and makes sense of some of this tech stuff and remembering some of the things that I did and need to be done to ensure things are working can be difficult. Enough of my excuses, Let me say that I am sorry I put you all through this excercise. Oh me...

My two Ubuntu instances that are hosting Nebula, one a lighthouse the other the client, did not have the firewall enabled and even though I did the post routing stuff, it certainly did nothing. It is no wonder that I couldn't get to the other devices on the lans. I recall very clearly doing that wiht my raspberry pis which worked perfectly and remember doing it on the Ubuntu machines, but no firewall enabled makes things not want work correctly when you need to move packets around.

I am so sorry. But thank you so much for helping.

One very embarrassed user,

John

1 reply

IanVS Feb 26, 2024
Collaborator

Thanks for reporting back, and I'm glad that it's working for you now.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Is there a need to Bind Nebula address when using multiple virtual IP Addresses? #1000

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 8 comments 8 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

Select a reply

Is there a need to Bind Nebula address when using multiple virtual IP Addresses? #1000

johnjces Oct 20, 2023

Replies: 8 comments · 8 replies

johnmaguire Oct 20, 2023 Maintainer

johnjces Oct 21, 2023 Author

johnmaguire Oct 21, 2023 Maintainer

johnjces Oct 24, 2023 Author

johnjces Oct 24, 2023 Author

johnmaguire Oct 25, 2023 Maintainer

johnjces Oct 25, 2023 Author

johnmaguire Oct 25, 2023 Maintainer

johnjces Oct 25, 2023 Author

johnjces Oct 25, 2023 Author

johnmaguire Jan 24, 2024 Maintainer

johnjces Jan 25, 2024 Author

johnjces Jan 25, 2024 Author

johnmaguire Feb 1, 2024 Maintainer

johnjces Feb 26, 2024 Author

IanVS Feb 26, 2024 Collaborator

johnjces
Oct 20, 2023

Replies: 8 comments 8 replies

johnmaguire
Oct 20, 2023
Maintainer

johnjces Oct 21, 2023
Author

johnmaguire Oct 21, 2023
Maintainer

johnjces
Oct 24, 2023
Author

johnjces
Oct 24, 2023
Author

johnmaguire
Oct 25, 2023
Maintainer

johnjces
Oct 25, 2023
Author

johnmaguire
Oct 25, 2023
Maintainer

johnjces Oct 25, 2023
Author

johnjces Oct 25, 2023
Author

johnmaguire Jan 24, 2024
Maintainer

johnjces Jan 25, 2024
Author

johnjces Jan 25, 2024
Author

johnmaguire
Feb 1, 2024
Maintainer

johnjces
Feb 26, 2024
Author

IanVS Feb 26, 2024
Collaborator