VPN-Fun (this time with Wireguard)
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
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:
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
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:
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
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:
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
Am Sonntag, 28. Januar 2024, 10:13:39 CET schrieb Andrei Borzenkov:
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
On 28.01.2024 12:28, Axel Braun wrote:
Am Sonntag, 28. Januar 2024, 10:13:39 CET schrieb Andrei Borzenkov:
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).
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:
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: <LOOPBACK,UP,LOWER_UP> 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: <NO-CARRIER,BROADCAST,MULTICAST,UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <POINTOPOINT,NOARP,UP,LOWER_UP> 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
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:
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: <LOOPBACK,UP,LOWER_UP> 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: <NO-CARRIER,BROADCAST,MULTICAST,UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <POINTOPOINT,NOARP,UP,LOWER_UP> 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
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.
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:
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: <LOOPBACK,UP,LOWER_UP> 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: <NO-CARRIER,BROADCAST,MULTICAST,UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <POINTOPOINT,NOARP,UP,LOWER_UP> 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 #
On Mon, Feb 19, 2024 at 2:45 PM Axel Braun <docb@opensuse.org> 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: <LOOPBACK,UP,LOWER_UP> 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: <NO-CARRIER,BROADCAST,MULTICAST,UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <POINTOPOINT,NOARP,UP,LOWER_UP> 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.
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
On Tue, Feb 20, 2024 at 4:53 PM Axel Braun <docb@opensuse.org> 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?
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
On Thu, Feb 22, 2024 at 11:49 AM Axel Braun <docb@opensuse.org> 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).
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
On Thu, Feb 22, 2024 at 2:03 PM Axel Braun <docb@opensuse.org> 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.
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:
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: <LOOPBACK,UP,LOWER_UP> 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: <NO-CARRIER,BROADCAST,MULTICAST,UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <POINTOPOINT,NOARP,UP,LOWER_UP> 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
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
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
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
participants (3)
-
Andrei Borzenkov -
Axel Braun -
Bengt Gördén