VPN-Fun (this time with Wireguard)

older
Sent a message with video (3.3M)...

Axel Braun

27 Jan 2024 27 Jan '24

17:32

Hi, after my recent experience with vpnc, which obviously does not support IPv6. I made another attempt with Wireguard, to connect to a IPv6 only host (DS-LITE connection). I could not get Strongswan for IPSec running. I followed the instructions of the FritzBox (6600 cable) and created a working Wireguard connection. At least it claims to work. Here is the startup protocoll: https://paste.opensuse.org/pastes/41e4656db770 So, if I'm on a IPv6 Telekom Connection and connect, it still shows Teleckm as provider (although VPN host is in via Vodafone) That means in fact it is not working! If I use an IPv4 connection it claims to work again, but same result - in fact it does not. Above log is from a IPv4 I tried to work this out with AVM support (Manufacturer of FritzBox), no success. Any ideas? Has anyone Wiresguard running (on TW)? Thanks Axel

Show replies by date

Andrei Borzenkov

27 Jan 27 Jan

17:46

On 27.01.2024 20:32, Axel Braun wrote:

...

Hi,

after my recent experience with vpnc, which obviously does not support IPv6. I made another attempt with Wireguard, to connect to a IPv6 only host (DS-LITE connection). I could not get Strongswan for IPSec running.

I followed the instructions of the FritzBox (6600 cable) and created a working Wireguard connection. At least it claims to work. Here is the startup protocoll:

https://paste.opensuse.org/pastes/41e4656db770

I guess you see yourself that it does not provide any information. Start VPN and show the output of ip a ip -4 r ip -6 r ip rule ip -6 rule

...

So, if I'm on a IPv6 Telekom Connection and connect, it still shows Teleckm as provider (although VPN host is in via Vodafone) That means in fact it is not working!

If I use an IPv4 connection it claims to work again, but same result - in fact it does not. Above log is from a IPv4

I tried to work this out with AVM support (Manufacturer of FritzBox), no success. Any ideas? Has anyone Wiresguard running (on TW)?

Thanks Axel

Axel Braun

28 Jan 28 Jan

08:44

Am Samstag, 27. Januar 2024, 18:46:51 CET schrieb Andrei Borzenkov:

...

On 27.01.2024 20:32, Axel Braun wrote:

...
Hi,

after my recent experience with vpnc, which obviously does not support IPv6. I made another attempt with Wireguard, to connect to a IPv6 only host (DS-LITE connection). I could not get Strongswan for IPSec running.

I followed the instructions of the FritzBox (6600 cable) and created a working Wireguard connection. At least it claims to work. Here is the startup protocoll:

https://paste.opensuse.org/pastes/41e4656db770

I guess you see yourself that it does not provide any information.

yes, except the 'successful' start

...

Start VPN and show the output of

ip a ip -4 r ip -6 r ip rule ip -6 rule

https://paste.opensuse.org/pastes/47b3ce0ce8d6 Cheers Axel

Andrei Borzenkov

09:13

On 28.01.2024 11:44, Axel Braun wrote:

...

Am Samstag, 27. Januar 2024, 18:46:51 CET schrieb Andrei Borzenkov:

...
On 27.01.2024 20:32, Axel Braun wrote:

...
Hi,

after my recent experience with vpnc, which obviously does not support IPv6. I made another attempt with Wireguard, to connect to a IPv6 only host (DS-LITE connection). I could not get Strongswan for IPSec running.

I followed the instructions of the FritzBox (6600 cable) and created a working Wireguard connection. At least it claims to work. Here is the startup protocoll:

https://paste.opensuse.org/pastes/41e4656db770

I guess you see yourself that it does not provide any information.

yes, except the 'successful' start

...
Start VPN and show the output of

ip a ip -4 r ip -6 r ip rule ip -6 rule

https://paste.opensuse.org/pastes/47b3ce0ce8d6

Cheers Axel

Well, as is obvious, your VPN interface does not have any global IPv6 address so it cannot have normal IPv6 connectivity, nor there are any IPv6 routing rules to forward traffic via VPN interface. Does your provider support IPv6 over WireGuard at all? E.g. ProtonVPN does not. It explicitly blocks all IPv6 traffic over VPN. Even if your provider is using some kind of NAT, lack of routing still means IPv6 will not go over VPN. And your VPN interface does not have any IPv4 address so even IPv4 should not work.

...

31501: not from all fwmark 0xcaca lookup 51914

Show ip route show table 51914

Axel Braun

09:28

Am Sonntag, 28. Januar 2024, 10:13:39 CET schrieb Andrei Borzenkov:

...

...
https://paste.opensuse.org/pastes/47b3ce0ce8d6

Well, as is obvious, your VPN interface does not have any global IPv6 address so it cannot have normal IPv6 connectivity, nor there are any IPv6 routing rules to forward traffic via VPN interface. Does your provider support IPv6 over WireGuard at all? E.g. ProtonVPN does not. It explicitly blocks all IPv6 traffic over VPN.

yes, this is to be expected. I'm currently in Maroc, they seem to have IPv4 only. The point is, in both cases (IPv6 connection in Germany) it did not work. But wireguard looks like everything is right. Bug?

...

Even if your provider is using some kind of NAT, lack of routing still means IPv6 will not go over VPN.

And your VPN interface does not have any IPv4 address so even IPv4 should not work.

...
31501: not from all fwmark 0xcaca lookup 51914

Show

ip route show table 51914

X1E:~ # ip route show table 51914 Error: ipv4: FIB table does not exist. Dump terminated I will follow up once I'm on a IPv6 Connection Thanks so far! Axel

Andrei Borzenkov

14:07

On 28.01.2024 12:28, Axel Braun wrote:

...

Am Sonntag, 28. Januar 2024, 10:13:39 CET schrieb Andrei Borzenkov:

...
...
https://paste.opensuse.org/pastes/47b3ce0ce8d6

Well, as is obvious, your VPN interface does not have any global IPv6 address so it cannot have normal IPv6 connectivity, nor there are any IPv6 routing rules to forward traffic via VPN interface. Does your provider support IPv6 over WireGuard at all? E.g. ProtonVPN does not. It explicitly blocks all IPv6 traffic over VPN.

yes, this is to be expected. I'm currently in Maroc, they seem to have IPv4 only. The point is, in both cases (IPv6 connection in Germany) it did not work. But wireguard looks like everything is right. Bug?

The only thing WireGuard does is to forward packets between your system and the peer. The IP addresses, routing tables, firewall rules etc are explicitly out of scope for WireGuard. It is up to you (or tools you use) to create working configuration by configuring suitable IP address on the WireGuard interface, by making sure routing table matches allowed IPs in the WireGuard configuration and your firewall allows traffic to/from the WireGuard interface. What do you use to set up WireGuard (wg-quick, NetworkManager, anything else)?

...

...
Even if your provider is using some kind of NAT, lack of routing still means IPv6 will not go over VPN.

And your VPN interface does not have any IPv4 address so even IPv4 should not work.

...
31501: not from all fwmark 0xcaca lookup 51914

Show

ip route show table 51914

X1E:~ # ip route show table 51914 Error: ipv4: FIB table does not exist. Dump terminated

I will follow up once I'm on a IPv6 Connection

Well, WireGuard can tunnel IPv6 over IPv4 so you do not need IPv6 connectivity to establish IPv6 WireGuard tunnel. But you do need the correct WireGuard configuration to do it. Post configuration you are using (obfuscating any private keys).

Axel Braun

18 Feb 18 Feb

10:32

Hello Andrei, Am Sonntag, 28. Januar 2024, 15:07:43 CET schrieb Andrei Borzenkov:

...

On 28.01.2024 12:28, Axel Braun wrote:

...
Am Sonntag, 28. Januar 2024, 10:13:39 CET schrieb Andrei Borzenkov:

...
...
https://paste.opensuse.org/pastes/47b3ce0ce8d6

Well, as is obvious, your VPN interface does not have any global IPv6 address so it cannot have normal IPv6 connectivity, nor there are any IPv6 routing rules to forward traffic via VPN interface. Does your provider support IPv6 over WireGuard at all? E.g. ProtonVPN does not. It explicitly blocks all IPv6 traffic over VPN.

yes, this is to be expected. I'm currently in Maroc, they seem to have IPv4 only. The point is, in both cases (IPv6 connection in Germany) it did not work. But wireguard looks like everything is right. Bug?

The only thing WireGuard does is to forward packets between your system and the peer. The IP addresses, routing tables, firewall rules etc are explicitly out of scope for WireGuard. It is up to you (or tools you use) to create working configuration by configuring suitable IP address on the WireGuard interface, by making sure routing table matches allowed IPs in the WireGuard configuration and your firewall allows traffic to/from the WireGuard interface.

What do you use to set up WireGuard (wg-quick, NetworkManager, anything else)?

I'm using Network Manager Find the settings here: https://c.gmx.net/@329946484294293704/8_Ohi_kLT3OGDdFy8JVVUQ Not sure if the IPv6 Tab needs to be adjusted: except the Method 'ignored', all other are 'not supported'

...

...
I will follow up once I'm on a IPv6 Connection

Here is the output: docb@X1E:~> ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: enp0s31f6: mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 48:2a:e3:7b:f5:ce brd ff:ff:ff:ff:ff:ff 3: wlp82s0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether dc:71:96:f1:57:61 brd ff:ff:ff:ff:ff:ff inet 192.168.2.49/24 brd 192.168.2.255 scope global dynamic noprefixroute wlp82s0 valid_lft 1814321sec preferred_lft 1814321sec inet6 2003:ee:3f10:f9d4:3ee9:c46b:d45c:2c6/64 scope global temporary dynamic valid_lft 172796sec preferred_lft 85982sec inet6 2003:ee:3f10:f9d4:62a4:7868:df2d:292/64 scope global dynamic mngtmpaddr noprefixroute valid_lft 172796sec preferred_lft 86396sec inet6 fe80::1d56:2c2f:68d9:e428/64 scope link noprefixroute valid_lft forever preferred_lft forever 4: Wireguard: mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000 link/none inet6 fe80::38f3:bb5c:ca2:65bb/64 scope link stable-privacy proto kernel_ll valid_lft forever preferred_lft forever docb@X1E:~> ip -4 r default via 192.168.2.1 dev wlp82s0 proto dhcp src 192.168.2.49 metric 600 192.168.2.0/24 dev wlp82s0 proto kernel scope link src 192.168.2.49 metric 600 docb@X1E:~> ip -6 r 2003:ee:3f10:f9d4::/64 dev wlp82s0 proto ra metric 600 pref medium fe80::/64 dev Gorden proto kernel metric 256 pref medium fe80::/64 dev wlp82s0 proto kernel metric 1024 pref medium default via fe80::1 dev wlp82s0 proto ra metric 600 pref medium docb@X1E:~> ip rule 0: from all lookup local 31500: from all lookup main suppress_prefixlength 0 31501: not from all fwmark 0xcaca lookup 51914 32766: from all lookup main 32767: from all lookup default docb@X1E:~> ip -6 rule 0: from all lookup local 32766: from all lookup main

Andrei Borzenkov

13:02

On 18.02.2024 13:32, Axel Braun wrote:

...

Hello Andrei,

Am Sonntag, 28. Januar 2024, 15:07:43 CET schrieb Andrei Borzenkov:

...
On 28.01.2024 12:28, Axel Braun wrote:

...
Am Sonntag, 28. Januar 2024, 10:13:39 CET schrieb Andrei Borzenkov:

...
...
https://paste.opensuse.org/pastes/47b3ce0ce8d6

Well, as is obvious, your VPN interface does not have any global IPv6 address so it cannot have normal IPv6 connectivity, nor there are any IPv6 routing rules to forward traffic via VPN interface. Does your provider support IPv6 over WireGuard at all? E.g. ProtonVPN does not. It explicitly blocks all IPv6 traffic over VPN.

yes, this is to be expected. I'm currently in Maroc, they seem to have IPv4 only. The point is, in both cases (IPv6 connection in Germany) it did not work. But wireguard looks like everything is right. Bug?

The only thing WireGuard does is to forward packets between your system and the peer. The IP addresses, routing tables, firewall rules etc are explicitly out of scope for WireGuard. It is up to you (or tools you use) to create working configuration by configuring suitable IP address on the WireGuard interface, by making sure routing table matches allowed IPs in the WireGuard configuration and your firewall allows traffic to/from the WireGuard interface.

What do you use to set up WireGuard (wg-quick, NetworkManager, anything else)?

I'm using Network Manager Find the settings here: https://c.gmx.net/@329946484294293704/8_Ohi_kLT3OGDdFy8JVVUQ

And what is your question? Something does not work?

...

Not sure if the IPv6 Tab needs to be adjusted: except the Method 'ignored', all other are 'not supported'

...
...
I will follow up once I'm on a IPv6 Connection

Here is the output:

docb@X1E:~> ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: enp0s31f6: mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 48:2a:e3:7b:f5:ce brd ff:ff:ff:ff:ff:ff 3: wlp82s0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether dc:71:96:f1:57:61 brd ff:ff:ff:ff:ff:ff inet 192.168.2.49/24 brd 192.168.2.255 scope global dynamic noprefixroute wlp82s0 valid_lft 1814321sec preferred_lft 1814321sec inet6 2003:ee:3f10:f9d4:3ee9:c46b:d45c:2c6/64 scope global temporary dynamic valid_lft 172796sec preferred_lft 85982sec inet6 2003:ee:3f10:f9d4:62a4:7868:df2d:292/64 scope global dynamic mngtmpaddr noprefixroute valid_lft 172796sec preferred_lft 86396sec inet6 fe80::1d56:2c2f:68d9:e428/64 scope link noprefixroute valid_lft forever preferred_lft forever 4: Wireguard: mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000 link/none inet6 fe80::38f3:bb5c:ca2:65bb/64 scope link stable-privacy proto kernel_ll valid_lft forever preferred_lft forever docb@X1E:~> ip -4 r default via 192.168.2.1 dev wlp82s0 proto dhcp src 192.168.2.49 metric 600 192.168.2.0/24 dev wlp82s0 proto kernel scope link src 192.168.2.49 metric 600 docb@X1E:~> ip -6 r 2003:ee:3f10:f9d4::/64 dev wlp82s0 proto ra metric 600 pref medium fe80::/64 dev Gorden proto kernel metric 256 pref medium fe80::/64 dev wlp82s0 proto kernel metric 1024 pref medium default via fe80::1 dev wlp82s0 proto ra metric 600 pref medium docb@X1E:~> ip rule 0: from all lookup local 31500: from all lookup main suppress_prefixlength 0 31501: not from all fwmark 0xcaca lookup 51914

That is the table where routing via wireguard takes place. I think I asked for the ip -4 route show table 51914 ip -6 route show table 51914 output.

...

32766: from all lookup main 32767: from all lookup default docb@X1E:~> ip -6 rule 0: from all lookup local 32766: from all lookup main

Anyway - is wireguard session established? Show output of wg show

Andrei Borzenkov

15:16

On 18.02.2024 16:02, Andrei Borzenkov wrote:

...

...
Anyway - is wireguard session established? Show output of

wg show

You are supposed to have interface: wg0 public key: xxx private key: (hidden) listening port: 33058 fwmark: 0xcb59 peer: yyy endpoint: a.b.c.d:1024 allowed ips: 0.0.0.0/0, ::/0 latest handshake: 1 minute, 10 seconds ago transfer: 798.08 KiB received, 1.32 MiB sent Until you see successful handshake, everything else does not matter. Of course, once you do see successful handshake, next is to have meaningful allowed IPs.

Axel Braun

19 Feb 19 Feb

11:44

Am Sonntag, 18. Februar 2024, 14:02:28 CET schrieb Andrei Borzenkov:

...

On 18.02.2024 13:32, Axel Braun wrote:

...
Hello Andrei,

Am Sonntag, 28. Januar 2024, 15:07:43 CET schrieb Andrei Borzenkov:

...
On 28.01.2024 12:28, Axel Braun wrote:

...
Am Sonntag, 28. Januar 2024, 10:13:39 CET schrieb Andrei Borzenkov:

...
...
https://paste.opensuse.org/pastes/47b3ce0ce8d6

Well, as is obvious, your VPN interface does not have any global IPv6 address so it cannot have normal IPv6 connectivity, nor there are any IPv6 routing rules to forward traffic via VPN interface. Does your provider support IPv6 over WireGuard at all? E.g. ProtonVPN does not. It explicitly blocks all IPv6 traffic over VPN.

yes, this is to be expected. I'm currently in Maroc, they seem to have IPv4 only. The point is, in both cases (IPv6 connection in Germany) it did not work. But wireguard looks like everything is right. Bug?

The only thing WireGuard does is to forward packets between your system and the peer. The IP addresses, routing tables, firewall rules etc are explicitly out of scope for WireGuard. It is up to you (or tools you use) to create working configuration by configuring suitable IP address on the WireGuard interface, by making sure routing table matches allowed IPs in the WireGuard configuration and your firewall allows traffic to/from the WireGuard interface.

What do you use to set up WireGuard (wg-quick, NetworkManager, anything else)?

I'm using Network Manager Find the settings here: https://c.gmx.net/@329946484294293704/8_Ohi_kLT3OGDdFy8JVVUQ

And what is your question? Something does not work?

...
Not sure if the IPv6 Tab needs to be adjusted: except the Method 'ignored', all other are 'not supported'

...
...
I will follow up once I'm on a IPv6 Connection

Here is the output:

docb@X1E:~> ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: enp0s31f6: mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 48:2a:e3:7b:f5:ce brd ff:ff:ff:ff:ff:ff 3: wlp82s0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether dc:71:96:f1:57:61 brd ff:ff:ff:ff:ff:ff inet 192.168.2.49/24 brd 192.168.2.255 scope global dynamic noprefixroute wlp82s0 valid_lft 1814321sec preferred_lft 1814321sec inet6 2003:ee:3f10:f9d4:3ee9:c46b:d45c:2c6/64 scope global temporary dynamic valid_lft 172796sec preferred_lft 85982sec inet6 2003:ee:3f10:f9d4:62a4:7868:df2d:292/64 scope global dynamic mngtmpaddr noprefixroute valid_lft 172796sec preferred_lft 86396sec inet6 fe80::1d56:2c2f:68d9:e428/64 scope link noprefixroute valid_lft forever preferred_lft forever 4: Wireguard: mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000 link/none inet6 fe80::38f3:bb5c:ca2:65bb/64 scope link stable-privacy proto kernel_ll valid_lft forever preferred_lft forever docb@X1E:~> ip -4 r default via 192.168.2.1 dev wlp82s0 proto dhcp src 192.168.2.49 metric 600 192.168.2.0/24 dev wlp82s0 proto kernel scope link src 192.168.2.49 metric 600 docb@X1E:~> ip -6 r 2003:ee:3f10:f9d4::/64 dev wlp82s0 proto ra metric 600 pref medium fe80::/64 dev Gorden proto kernel metric 256 pref medium fe80::/64 dev wlp82s0 proto kernel metric 1024 pref medium default via fe80::1 dev wlp82s0 proto ra metric 600 pref medium docb@X1E:~> ip rule 0: from all lookup local 31500: from all lookup main suppress_prefixlength 0 31501: not from all fwmark 0xcaca lookup 51914

That is the table where routing via wireguard takes place. I think I asked for the

ip -4 route show table 51914 ip -6 route show table 51914

output.

X1E:/home/docb # ip -4 route show table 51914 Error: ipv4: FIB table does not exist. Dump terminated X1E:/home/docb # ip -6 route show table 51914 Error: ipv6: FIB table does not exist. Dump terminated Does not look good, no?

...

...
32766: from all lookup main 32767: from all lookup default docb@X1E:~> ip -6 rule 0: from all lookup local 32766: from all lookup main

Anyway - is wireguard session established? Show output of

wg show

X1E:/home/docb # wg show interface: Wireguard public key: k08BjY+ODUypz1xENaHrpdinyDooKZPap9A2a9zjgz4= private key: (hidden) listening port: 35440 fwmark: 0xcaca peer: utC93j4omCcw7V1WcByh8zVggcuS8tw9mmQDQTbHUAs= preshared key: (hidden) endpoint: [xxxx:xxxx:f000:2c::db1]:51710 allowed ips: 192.168.178.0/24, 0.0.0.0/0 X1E:/home/docb #

Andrei Borzenkov

12:02

On Mon, Feb 19, 2024 at 2:45 PM Axel Braun wrote:

...

Am Sonntag, 18. Februar 2024, 14:02:28 CET schrieb Andrei Borzenkov:

...
On 18.02.2024 13:32, Axel Braun wrote:

...
Hello Andrei,

Am Sonntag, 28. Januar 2024, 15:07:43 CET schrieb Andrei Borzenkov:

...
On 28.01.2024 12:28, Axel Braun wrote:

...
Am Sonntag, 28. Januar 2024, 10:13:39 CET schrieb Andrei Borzenkov:

...
> https://paste.opensuse.org/pastes/47b3ce0ce8d6

Well, as is obvious, your VPN interface does not have any global IPv6 address so it cannot have normal IPv6 connectivity, nor there are any IPv6 routing rules to forward traffic via VPN interface. Does your provider support IPv6 over WireGuard at all? E.g. ProtonVPN does not. It explicitly blocks all IPv6 traffic over VPN.

yes, this is to be expected. I'm currently in Maroc, they seem to have IPv4 only. The point is, in both cases (IPv6 connection in Germany) it did not work. But wireguard looks like everything is right. Bug?

The only thing WireGuard does is to forward packets between your system and the peer. The IP addresses, routing tables, firewall rules etc are explicitly out of scope for WireGuard. It is up to you (or tools you use) to create working configuration by configuring suitable IP address on the WireGuard interface, by making sure routing table matches allowed IPs in the WireGuard configuration and your firewall allows traffic to/from the WireGuard interface.

What do you use to set up WireGuard (wg-quick, NetworkManager, anything else)?

I'm using Network Manager Find the settings here: https://c.gmx.net/@329946484294293704/8_Ohi_kLT3OGDdFy8JVVUQ

And what is your question? Something does not work?

...
Not sure if the IPv6 Tab needs to be adjusted: except the Method 'ignored', all other are 'not supported'

...
...
I will follow up once I'm on a IPv6 Connection

Here is the output:

docb@X1E:~> ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: enp0s31f6: mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 48:2a:e3:7b:f5:ce brd ff:ff:ff:ff:ff:ff 3: wlp82s0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether dc:71:96:f1:57:61 brd ff:ff:ff:ff:ff:ff inet 192.168.2.49/24 brd 192.168.2.255 scope global dynamic noprefixroute wlp82s0 valid_lft 1814321sec preferred_lft 1814321sec inet6 2003:ee:3f10:f9d4:3ee9:c46b:d45c:2c6/64 scope global temporary dynamic valid_lft 172796sec preferred_lft 85982sec inet6 2003:ee:3f10:f9d4:62a4:7868:df2d:292/64 scope global dynamic mngtmpaddr noprefixroute valid_lft 172796sec preferred_lft 86396sec inet6 fe80::1d56:2c2f:68d9:e428/64 scope link noprefixroute valid_lft forever preferred_lft forever 4: Wireguard: mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000 link/none inet6 fe80::38f3:bb5c:ca2:65bb/64 scope link stable-privacy proto kernel_ll valid_lft forever preferred_lft forever docb@X1E:~> ip -4 r default via 192.168.2.1 dev wlp82s0 proto dhcp src 192.168.2.49 metric 600 192.168.2.0/24 dev wlp82s0 proto kernel scope link src 192.168.2.49 metric 600 docb@X1E:~> ip -6 r 2003:ee:3f10:f9d4::/64 dev wlp82s0 proto ra metric 600 pref medium fe80::/64 dev Gorden proto kernel metric 256 pref medium fe80::/64 dev wlp82s0 proto kernel metric 1024 pref medium default via fe80::1 dev wlp82s0 proto ra metric 600 pref medium docb@X1E:~> ip rule 0: from all lookup local 31500: from all lookup main suppress_prefixlength 0 31501: not from all fwmark 0xcaca lookup 51914

That is the table where routing via wireguard takes place. I think I asked for the

ip -4 route show table 51914 ip -6 route show table 51914

output.

X1E:/home/docb # ip -4 route show table 51914 Error: ipv4: FIB table does not exist. Dump terminated X1E:/home/docb # ip -6 route show table 51914 Error: ipv6: FIB table does not exist. Dump terminated

Does not look good, no?

No, it does not. It may be the consequence of the missing IP address. Show the actual information you got from your provider (obfuscating any private keys), not the final NetworkManager configuration.

...

...
...
32766: from all lookup main 32767: from all lookup default docb@X1E:~> ip -6 rule 0: from all lookup local 32766: from all lookup main

Anyway - is wireguard session established? Show output of

wg show

X1E:/home/docb # wg show interface: Wireguard public key: k08BjY+ODUypz1xENaHrpdinyDooKZPap9A2a9zjgz4= private key: (hidden) listening port: 35440 fwmark: 0xcaca

peer: utC93j4omCcw7V1WcByh8zVggcuS8tw9mmQDQTbHUAs= preshared key: (hidden) endpoint: [xxxx:xxxx:f000:2c::db1]:51710 allowed ips: 192.168.178.0/24, 0.0.0.0/0 X1E:/home/docb #

Well, there is no handshake information so there is no connection to the peer. It is possible that wireguard establishes connection on demand and there is no traffic via this interface.

Axel Braun

20 Feb 20 Feb

13:53

Am Montag, 19. Februar 2024, 13:02:37 CET schrieb Andrei Borzenkov:

...

...
X1E:/home/docb # ip -4 route show table 51914 Error: ipv4: FIB table does not exist. Dump terminated X1E:/home/docb # ip -6 route show table 51914 Error: ipv6: FIB table does not exist. Dump terminated

Does not look good, no?

No, it does not. It may be the consequence of the missing IP address. Show the actual information you got from your provider (obfuscating any private keys), not the final NetworkManager configuration.

[Interface] PrivateKey = xxxxxxxxxxxxxxxxxxxxxxx= Address = 192.168.178.202/24 DNS = 192.168.178.1 DNS = fritz.box [Peer] PublicKey = xxxxxxxxxxxxxxxxxxxxxxxxxxx= PresharedKey = xxxxxxxxxxxxxxxxxxxxxxc= AllowedIPs = 192.168.178.0/24,0.0.0.0/0 Endpoint = xxxxxxxx.myfritz.net:51710 PersistentKeepalive = 25

Andrei Borzenkov

14:10

On Tue, Feb 20, 2024 at 4:53 PM Axel Braun wrote:

...

Am Montag, 19. Februar 2024, 13:02:37 CET schrieb Andrei Borzenkov:

...
...
X1E:/home/docb # ip -4 route show table 51914 Error: ipv4: FIB table does not exist. Dump terminated X1E:/home/docb # ip -6 route show table 51914 Error: ipv6: FIB table does not exist. Dump terminated

Does not look good, no?

No, it does not. It may be the consequence of the missing IP address. Show the actual information you got from your provider (obfuscating any private keys), not the final NetworkManager configuration.

[Interface] PrivateKey = xxxxxxxxxxxxxxxxxxxxxxx= Address = 192.168.178.202/24

Somehow you did not configure this address. Did you create a NetworkManager connection manually or imported wg-quick configuration?

...

DNS = 192.168.178.1 DNS = fritz.box

[Peer] PublicKey = xxxxxxxxxxxxxxxxxxxxxxxxxxx= PresharedKey = xxxxxxxxxxxxxxxxxxxxxxc=

OK, so you do have PSK. Wireguard continuously performs a handshake to establish a session encryption key. As long as you do not see a successful handshake in `wg show` output, nothing can work.

...

AllowedIPs = 192.168.178.0/24,0.0.0.0/0

0.0.0.0/0 includes 192.168.178.0/24. I would omit it.

...

Endpoint = xxxxxxxx.myfritz.net:51710 PersistentKeepalive = 25

Does it work using wg-quick instead of NetworkManager?

Axel Braun

22 Feb 22 Feb

08:49

Am Dienstag, 20. Februar 2024, 15:10:16 CET schrieb Andrei Borzenkov:

...

...
...
No, it does not. It may be the consequence of the missing IP address. Show the actual information you got from your provider (obfuscating any private keys), not the final NetworkManager configuration.

[Interface] PrivateKey = xxxxxxxxxxxxxxxxxxxxxxx= Address = 192.168.178.202/24

Somehow you did not configure this address. Did you create a NetworkManager connection manually or imported wg-quick configuration?

I created the connection manually, tried import afterwards.

...

...
Endpoint = xxxxxxxx.myfritz.net:51710 PersistentKeepalive = 25

Does it work using wg-quick instead of NetworkManager?

X1E:/home/docb/Downloads # wg-quick up wg_config [#] ip link add wg_config type wireguard [#] wg setconf wg_config /dev/fd/62 [#] ip -4 address add 192.168.178.202/24 dev wg_config [#] ip link set mtu 1420 up dev wg_config [#] mount `192.168.178.1' /etc/resolv.conf [#] wg set wg_config fwmark 51820 [#] ip -4 route add 0.0.0.0/0 dev wg_config table 51820 [#] ip -4 rule add not fwmark 51820 table 51820 [#] ip -4 rule add table main suppress_prefixlength 0 [#] sysctl -q net.ipv4.conf.all.src_valid_mark=1 [#] nft -f /dev/fd/62 X1E:/home/docb/Downloads # wg show interface: wg_config public key: xxxxxxxxxxxxxxxxxxxxx= private key: (hidden) listening port: 52736 fwmark: 0xca6c peer: xxxxxxxxxxxxxxxxxxxxxxxxxxx= preshared key: (hidden) endpoint: [2a02:908:f000:2c::db1]:51710 allowed ips: 192.168.178.0/24, 0.0.0.0/0 latest handshake: 20 seconds ago transfer: 23.01 KiB received, 29.55 KiB sent persistent keepalive: every 25 seconds So this indicates that we see a handshake (hoooorrrrraaaaayyyyyy!). In the Fritzox on the other side, my VPN host, it shows a successful connection. But https://whatismyipaddress.com/ still shows the same exit point as before. Thats still not the expected result Cheers Axel

Andrei Borzenkov

09:29

On Thu, Feb 22, 2024 at 11:49 AM Axel Braun wrote:

...

Am Dienstag, 20. Februar 2024, 15:10:16 CET schrieb Andrei Borzenkov:

...
...
...
No, it does not. It may be the consequence of the missing IP address. Show the actual information you got from your provider (obfuscating any private keys), not the final NetworkManager configuration.

[Interface] PrivateKey = xxxxxxxxxxxxxxxxxxxxxxx= Address = 192.168.178.202/24

Somehow you did not configure this address. Did you create a NetworkManager connection manually or imported wg-quick configuration?

I created the connection manually, tried import afterwards.

...
...
Endpoint = xxxxxxxx.myfritz.net:51710 PersistentKeepalive = 25

Does it work using wg-quick instead of NetworkManager?

X1E:/home/docb/Downloads # wg-quick up wg_config [#] ip link add wg_config type wireguard [#] wg setconf wg_config /dev/fd/62 [#] ip -4 address add 192.168.178.202/24 dev wg_config [#] ip link set mtu 1420 up dev wg_config [#] mount `192.168.178.1' /etc/resolv.conf [#] wg set wg_config fwmark 51820 [#] ip -4 route add 0.0.0.0/0 dev wg_config table 51820 [#] ip -4 rule add not fwmark 51820 table 51820 [#] ip -4 rule add table main suppress_prefixlength 0 [#] sysctl -q net.ipv4.conf.all.src_valid_mark=1 [#] nft -f /dev/fd/62

X1E:/home/docb/Downloads # wg show interface: wg_config public key: xxxxxxxxxxxxxxxxxxxxx= private key: (hidden) listening port: 52736 fwmark: 0xca6c

peer: xxxxxxxxxxxxxxxxxxxxxxxxxxx= preshared key: (hidden) endpoint: [2a02:908:f000:2c::db1]:51710 allowed ips: 192.168.178.0/24, 0.0.0.0/0 latest handshake: 20 seconds ago transfer: 23.01 KiB received, 29.55 KiB sent persistent keepalive: every 25 seconds

So this indicates that we see a handshake (hoooorrrrraaaaayyyyyy!). In the Fritzox on the other side, my VPN host, it shows a successful connection. But https://whatismyipaddress.com/ still shows the same exit point as before.

I have no idea what "Fritzbox on the other side" is nor what is "exit point".

...

Thats still not the expected result

You did not really explain what you expected or what should be the correct result. Nor do I know what this site does and how it determines your IP address (if that is what you mean). This site seems to load some scripts. Try e.g. https://www.showmyip.com. AFAICT it returns the address you are connected from (it returns it even when I load this page with curl).

Axel Braun

11:03

Am Donnerstag, 22. Februar 2024, 10:29:24 CET schrieb Andrei Borzenkov:

...

...
So this indicates that we see a handshake (hoooorrrrraaaaayyyyyy!). In the Fritzox on the other side, my VPN host, it shows a successful connection. But https://whatismyipaddress.com/ still shows the same exit point as before.

I have no idea what "Fritzbox on the other side" is nor what is "exit point".

The FritzBox is a quite popular DSL/cable modem in Germany. I connect to this box ('the box on the other side') which is located in Germany (The exit point). Whole reason for this excercise is to avoid geoblocking from german media/news websites

...

You did not really explain what you expected or what should be the correct result. Nor do I know what this site does and how it determines your IP address (if that is what you mean). This site seems to load some scripts.

Try e.g. https://www.showmyip.com. AFAICT it returns the address you are connected from (it returns it even when I load this page with curl).

This is quite interesting, both detect the same (IPv4) address when connected to VPN, but showmyip gives different details, e.g. location in germany, which is the expected result. Whatismyipaddress shows a IPv6 address as well, showmyip not. (I'm currently on a connection with v4 and v6). so with wg-quick I could establish a connection to the ipv6 box (on the other side), using the same .conf file as with NetworkManager, which did not work. I think I start all over again..... Thanks Axel

Andrei Borzenkov

11:20

On Thu, Feb 22, 2024 at 2:03 PM Axel Braun wrote:

...

Am Donnerstag, 22. Februar 2024, 10:29:24 CET schrieb Andrei Borzenkov:

...
...
So this indicates that we see a handshake (hoooorrrrraaaaayyyyyy!). In the Fritzox on the other side, my VPN host, it shows a successful connection. But https://whatismyipaddress.com/ still shows the same exit point as before.

I have no idea what "Fritzbox on the other side" is nor what is "exit point".

The FritzBox is a quite popular DSL/cable modem in Germany. I connect to this box ('the box on the other side') which is located in Germany (The exit point). Whole reason for this excercise is to avoid geoblocking from german media/news websites

...
You did not really explain what you expected or what should be the correct result. Nor do I know what this site does and how it determines your IP address (if that is what you mean). This site seems to load some scripts.

Try e.g. https://www.showmyip.com. AFAICT it returns the address you are connected from (it returns it even when I load this page with curl).

This is quite interesting, both detect the same (IPv4) address when connected to VPN, but showmyip gives different details, e.g. location in germany, which is the expected result. Whatismyipaddress shows a IPv6 address as well, showmyip not. (I'm currently on a connection with v4 and v6).

You seem to misunderstand. Your WireGuard configuration does not handle IPv6 at all so your IPv6 traffic will NOT be sent over WireGuard connection (which may be one of reasons why the site you mentioned shows the "incorrect" location). You need to assign an IPv6 address to the WireGuard interface and configure routing rules to send IPv6 traffic over it. This must be of course coordinated with your peer.

...

so with wg-quick I could establish a connection to the ipv6 box (on the other side), using the same .conf file as with NetworkManager, which did not work.

So far importing wg-quick configuration into NetworkManager always results in the identical setup (modulo /etc/resolv.conf handling). Arguably, I did not attempt to use multiple allowed IP ranges and only ever used WG interface as default catch-all.

Andrei Borzenkov

18 Feb 18 Feb

15:29

On 18.02.2024 13:32, Axel Braun wrote:

...

Hello Andrei,

Am Sonntag, 28. Januar 2024, 15:07:43 CET schrieb Andrei Borzenkov:

...
On 28.01.2024 12:28, Axel Braun wrote:

...
Am Sonntag, 28. Januar 2024, 10:13:39 CET schrieb Andrei Borzenkov:

...
...
https://paste.opensuse.org/pastes/47b3ce0ce8d6

Well, as is obvious, your VPN interface does not have any global IPv6 address so it cannot have normal IPv6 connectivity, nor there are any IPv6 routing rules to forward traffic via VPN interface. Does your provider support IPv6 over WireGuard at all? E.g. ProtonVPN does not. It explicitly blocks all IPv6 traffic over VPN.

yes, this is to be expected. I'm currently in Maroc, they seem to have IPv4 only. The point is, in both cases (IPv6 connection in Germany) it did not work. But wireguard looks like everything is right. Bug?

The only thing WireGuard does is to forward packets between your system and the peer. The IP addresses, routing tables, firewall rules etc are explicitly out of scope for WireGuard. It is up to you (or tools you use) to create working configuration by configuring suitable IP address on the WireGuard interface, by making sure routing table matches allowed IPs in the WireGuard configuration and your firewall allows traffic to/from the WireGuard interface.

What do you use to set up WireGuard (wg-quick, NetworkManager, anything else)?

I'm using Network Manager Find the settings here: https://c.gmx.net/@329946484294293704/8_Ohi_kLT3OGDdFy8JVVUQ

Not sure if the IPv6 Tab needs to be adjusted: except the Method 'ignored', all other are 'not supported'

...
...
I will follow up once I'm on a IPv6 Connection

Here is the output:

docb@X1E:~> ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: enp0s31f6: mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 48:2a:e3:7b:f5:ce brd ff:ff:ff:ff:ff:ff 3: wlp82s0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether dc:71:96:f1:57:61 brd ff:ff:ff:ff:ff:ff inet 192.168.2.49/24 brd 192.168.2.255 scope global dynamic noprefixroute wlp82s0 valid_lft 1814321sec preferred_lft 1814321sec inet6 2003:ee:3f10:f9d4:3ee9:c46b:d45c:2c6/64 scope global temporary dynamic valid_lft 172796sec preferred_lft 85982sec inet6 2003:ee:3f10:f9d4:62a4:7868:df2d:292/64 scope global dynamic mngtmpaddr noprefixroute valid_lft 172796sec preferred_lft 86396sec inet6 fe80::1d56:2c2f:68d9:e428/64 scope link noprefixroute valid_lft forever preferred_lft forever 4: Wireguard: mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000 link/none inet6 fe80::38f3:bb5c:ca2:65bb/64 scope link stable-privacy proto kernel_ll valid_lft forever preferred_lft forever

There is no address on this interface. I am not sure whether it is supposed to work at all. Most likely not. Do you have any traffic on this interface at all? What is the source address of packets sent via this interface?

...

docb@X1E:~> ip -4 r default via 192.168.2.1 dev wlp82s0 proto dhcp src 192.168.2.49 metric 600 192.168.2.0/24 dev wlp82s0 proto kernel scope link src 192.168.2.49 metric 600 docb@X1E:~> ip -6 r 2003:ee:3f10:f9d4::/64 dev wlp82s0 proto ra metric 600 pref medium fe80::/64 dev Gorden proto kernel metric 256 pref medium fe80::/64 dev wlp82s0 proto kernel metric 1024 pref medium default via fe80::1 dev wlp82s0 proto ra metric 600 pref medium docb@X1E:~> ip rule 0: from all lookup local 31500: from all lookup main suppress_prefixlength 0 31501: not from all fwmark 0xcaca lookup 51914 32766: from all lookup main 32767: from all lookup default docb@X1E:~> ip -6 rule 0: from all lookup local 32766: from all lookup main

Bengt Gördén

20:07

On 2024-02-18 11:32, Axel Braun wrote:

...

I'm using Network Manager Find the settings here:https://c.gmx.net/@329946484294293704/8_Ohi_kLT3OGDdFy8JVVUQ

Here is an indication that commas are a problem in the allowed IP field. Try ; instead https://bugzilla.redhat.com/show_bug.cgi?id=2055577 -- /bengan

Axel Braun

21:04

Hello Bengan Am Sonntag, 18. Februar 2024, 21:07:51 CET schrieb Bengt Gördén:

...

On 2024-02-18 11:32, Axel Braun wrote:

...
I'm using Network Manager Find the settings here:https://c.gmx.net/@329946484294293704/8_Ohi_kLT3OGDdFy8JVVUQ

Here is an indication that commas are a problem in the allowed IP field. Try ; instead

https://bugzilla.redhat.com/show_bug.cgi?id=2055577

Thank you for the hint. In fact, when editing the NetworkManager connection, one can't enter a semicolon, only commata allowed in the respective field However, the corresponding /etc/NetworkManager/system-connections/Wireguard.nmconnection contains semicolon as separator for the IP addresses. So that looks OK.... Thanks Axel

Age (days ago)

Last active (days ago)

List overview

Download

19 comments

3 participants

participants (3)

Andrei Borzenkov
Axel Braun
Bengt Gördén

VPN-Fun (this time with Wireguard)

tags

participants (3)