fd00:22:dec:15::/64 fd00:22:dec:e2::100 UGS 0 20 - 8 wg0
fd00:22:dec:e2::/64 fd00:22:dec:e2::100 UCn 5 6 - 4 wg0
fd00:22:dec:e2::/64 fd00:22:dec:e2::1 UCn 0 1 - 4 em0
fd00:22:dec:e2::1 00:e0:67:26:67:88 UHLl 0 7 - 1 em0
fd00:22:dec:e2::2 link#0 UHc 0 42 - 3 wg0
fd00:22:dec:e2::3 link#0 UHc 1 126 - 3 wg0
fd00:22:dec:e2::100 wg0 UHhl 1 2 - 1 wg0
fd00:22:dec:e2::c964 link#0 UHc 0 8 - 3 wg0
fd00:22:dec:e2:226:b9ff:fef6:d709 link#0 UHc 0 9 - 3 wg0
fd00:22:dec:e2:86cf:bfff:fe92:5689 link#0 UHc 0 9 - 3 wg0
ff01::%wg0/32 fd00:22:dec:e2::100 Um 0 0 - 4 wg0
ff02::%wg0/32 fd00:22:dec:e2::100 Um 0 0 - 4 wg0
Good day to you
I have a wg tunnel on my openbsd routeur (just updated to 7.1, but I believe
the bug has been there for at least the last release).
When the tunnel is up, there is a route that is created and breaks my local
networking.
Here is the hostname.wg0 (xxxx for safety reasons) :
#########
inet6 fd00:22:dec:e2::100 64
wgkey xxxxxxx = wgport 51820 \
wgpeer xxxxx= \
wgpsk xxxxx= \
wgendpoint 2a01:xxxxxxx:9538 51820 \
wgaip fd00:22:dec:15::100/64
!/sbin/route add -inet6 fd00:22:dec:15::100/64 fd00:22:dec:e2::100
up
#########
Now the route indicated in that conf' itself is good. I can see the route
being established during bootup. All good.
But then local routing get messed up. Here is an extract of the routing table
(extract made with "route -n show -inet6|grep fd00")
fd00:22:dec:15::/64 fd00:22:dec:e2::100 UGS 0
20 - 8 wg0
fd00:22:dec:e2::/64 fd00:22:dec:e2::100 UCn 5
6 - 4 wg0
fd00:22:dec:e2::/64 fd00:22:dec:e2::1 UCn 0
1 - 4 em0
fd00:22:dec:e2::1 00:e0:67:26:67:88 UHLl 0
7 - 1 em0
fd00:22:dec:e2::2 link#0 UHc 0
42 - 3 wg0
fd00:22:dec:e2::3 link#0 UHc 1
126 - 3 wg0
fd00:22:dec:e2::100 wg0 UHhl 1
2 - 1 wg0
fd00:22:dec:e2::c964 link#0 UHc 0
8 - 3 wg0
fd00:22:dec:e2:226:b9ff:fef6:d709 link#0 UHc 0
9 - 3 wg0
fd00:22:dec:e2:86cf:bfff:fe92:5689 link#0 UHc 0
9 - 3 wg0
ff01::%wg0/32 fd00:22:dec:e2::100 Um 0
0 - 4 wg0
ff02::%wg0/32 fd00:22:dec:e2::100 Um 0
0 - 4 wg0
(I joined the extract as a text file so you can read it better. That text file
is the direct result of the command piped in file.)
If you pay much attention, you see two routes to fd00:22:dec:e2::/64 and I
have to manually remove that second route (pointing on wg) to have good local
connection.
As I removed the failing route, I am not losing any connectivity on my wg
tunnel, it stays good.
When the tunnel is disabled, the failing route is not established at bootup
and everything is fine.
I have no idea where that failing route comes from.
Best regards.
No comments:
Post a Comment