Posture Check

[GascPT]

Describe the problem

I have a setup with multiple Sites, in each site I have a peer act as a gateway to advertise the routes of the Sites. I have set a posture check to not advertise the routes when a mobile peer is located locally on the Site. The posture checks the IP Range.

When this endpoint goes home and reconnects to the netbird he does not acquire the routes to Site A.

To correct this we need to exclude and include the peer from the distribution group in the netbird admin panel.

Expected behavior

We expected a recheck of the posture check

Are you using NetBird Cloud?

No, is a self-hosted deployment

NetBird version

In all versions, we test from v0.26.3 to v0.27.1

[pappz]

Hello!

Could you send me more details about your system?

• Peer’s OS
• Policy in which the posture is applied, how you configured it
• The network route configuration

[GascPT]

The peer OS is an Ubuntu Machine, but happens in macOS and Windows.

The policy checks the IP Range from where the peer is connecting, if the peer is connecting from the IP Range of Site A the ACL does not allow the connection between the peers.

And I am applying this ACL on the network route.

[bcmmbaga]

Hello @GascPT, could you confirm whether the peer is part of the source group(s) specified in the access control policy? Also, please check if the peer contains the local network 10.10.0.0/24 by running the command ifconfig -a.

[GascPT]

Yes the peer is part of the of the source group. The policy applies well when this peer is in the network of the Site A 10.10.0.0/24, he doesn't acquire the route.

When the peer goes to another place with another network range different of 10.10.0.0. The posture is not re-checked we need to kick the peer from the group and add him again.

[bcmmbaga]

The posture could have already been re-checked but failed since the peer still contain the Site A network in it's network interfaces.

Please share the result of ifconfig -a when the peer is connected to site A and when is connected to another network.

[GascPT]

When is connect in Site A

enx0826ae3dc148: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.10.0.104  netmask 255.255.255.0  broadcast 10.10.0.255
        inet6 2001:8a0:8015:10:a3cb:1ebc:c782:c7ee  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::5c82:bd12:b67a:3cd6  prefixlen 64  scopeid 0x20<link>
        inet6 2001:8a0:8015:10:d6b4:3f84:fd2a:f94a  prefixlen 64  scopeid 0x0<global>
        ether 08:26:ae:3d:c1:48  txqueuelen 1000  (Ethernet)
        RX packets 136548  bytes 90034413 (90.0 MB)
        RX errors 0  dropped 4878  overruns 0  frame 0
        TX packets 153699  bytes 37866299 (37.8 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wt0: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1280
        inet 100.95.28.93  netmask 255.255.0.0  destination 100.95.28.93
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
        RX packets 865212  bytes 928817092 (928.8 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 510435  bytes 53566908 (53.5 MB)
        TX errors 2957  dropped 78 overruns 0  carrier 0  collisions 0

When is connected in other place via WiFi

wlp0s20f3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.7.154  netmask 255.255.255.0  broadcast 192.168.7.255
        inet6 fe80::cf8b:ae41:418e:d58b  prefixlen 64  scopeid 0x20<link>
        ether 74:04:f1:43:9d:51  txqueuelen 1000  (Ethernet)
        RX packets 12929526  bytes 11159631682 (11.1 GB)
        RX errors 0  dropped 183229  overruns 0  frame 0
        TX packets 1380964  bytes 2762954292 (2.7 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wt0: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1280
        inet 100.95.28.93  netmask 255.255.0.0  destination 100.95.28.93
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
        RX packets 6  bytes 544 (544.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 10  bytes 1136 (1.1 KB)
        TX errors 44  dropped 11 overruns 0  carrier 0  collisions 0

I wait a couple of minutes but the peer doesn't acquire the route, neither the connection to the peer in netbird status -d

$ ip route show table netbird
10.0.0.0/24 dev wt0 
10.27.0.0/24 dev wt0 
10.27.10.0/24 dev wt0 
10.27.16.0/24 dev wt0 
10.55.0.0/24 dev wt0 
10.55.10.0/24 dev wt0 
10.55.16.0/24 dev wt0

[bcmmbaga]

Thanks, this could potentially be a bug, but I will try to reproduce the issue. Can you confirm whether, when connecting to the other network, you did not stop the netbird and run it up again, or did you only change the network?

[GascPT]

We did the two situations. Change networks without stopping the service and the other one, change the networks with the service stopped. The result was the same.

[mlsmaycon]

This should be fixed with: https://github.com/netbirdio/netbird/pull/1693

[GascPT]

Waiting for the release :) to try.

[GascPT]

The issue persists in the version 0.27.4.

[bcmmbaga]

Hi @GascPT, #1693 has not yet been released and is currently under review.

[GascPT]

Sorry didn't see that.