Can nebula have multiple internal subnets?

[pepsi1k]

I want to configure different zones and establish connection between them, everything of course under one root CA, for example

zone167: 
host1 - 192.168.167.1/24 (lighthouse)
zone255:
host1 - 192.168.255.1/24

I generated two certificates:

nebula-cert sign -name host1.zone167 -ip "192.168.167.1/24" ...
nebula-cert sign -name host1.zone255 -ip "192.168.255.1/24" ...

But when host1.zone255 tries to reach host1.zone167 it shows:

level=error msg="static_host_map key is not in our subnet, invalid" entry=1 network=192.168.255.1/24 vpnIp=192.168.167.1

Looking at this log and I tried to generate certificates with

nebula-cert sign -name host1.zone167 -ip "192.168.167.1/24" -subnets "192.168.0.0/16" ...
nebula-cert sign -name host1.zone255 -ip "192.168.255.1/24" -subnets "192.168.0.0/16" ...
# or
nebula-cert sign -name host1.zone167 -ip "192.168.167.1/24" -subnets "192.168.167.0/24,192.168.255.0/24" ...
nebula-cert sign -name host1.zone255 -ip "192.168.255.1/24" -subnets "192.168.167.0/24,192.168.255.0/24" ...

But log error still the same.

Is nabula capable to work with different subnets?

[cgtons]

Try changing the subnet mask to 192.168.167.1/16 and 192.168.255.1/16 when creating the certificates.

Link for reference: link.

[johnmaguire]

-subnets is for local subnets that can be exposed as unsafe_routes

-ip specifies both the host's IP and the list of IPs it can speak with. I don't believe it's possible to specify an IP range for communication that the host's IP does not exist within.

It looks like you want -ip 192.168.167.1/16 but this will likely conflict with home networks (anyone using 192.168.0.0/16 space.) Perhaps consider CGNAT or space within 10.0.0.0/8.

[timteka]

-ip specifies both the host's IP and the list of IPs it can speak with. I don't believe it's possible to specify an IP range for communication that the host's IP does not exist within.

We've tried to 'lease' several smaller subnets for our teams, all inside nebula's 10.145.0.0/22:

• team1 with 10.145.1.0/25
• team2 with 10.145.2.0/25
  All teams with distinct CA. We've concatenated all those CAs into global bundle of course. Still no interrouting. How can we solve the problem?

[nbrownus]

@timteka

We made some foundational changes that will help to eventually solve this problem in v1.10. Currently these flows are distinguished as "Peer Networks" which are hosts that are trusted but are not contained within your own issued network space(s). These packets are still rejected by the Nebula firewall.

The technical problem of enabling routing for peer networks is quite straightforward. Nebula needs to establish the route in the local system and note the cidr internally as one we should handle.

What needs a bit more thought is if the current firewall config language is good enough to provide controls for peer networks.

I would expect this to be resolved in v1.11

[nbrownus]

@pepsi1k what @johnmaguire wrote still applies in Nebula v1.10 but we are moving in a direction that would support your use case. Please see this comment #1307 (reply in thread)