[SOLVED] Unable to set allowed IPs to '0.0.0.0' for wireguard client

[Seimus]

Sorry for intrusion,

But, if you did correct your config for WG as was advised.

Do you see in live logs permit for the specific source and destinations being hit with permit?
Also this issue is only related to HTTP/s?
Did you do as well MSS clamping (Normalization)?

If you are connecting WG over cell, set on the client WG app [Interface] as well MTU 1390.

Regards,
S.

[tiermutter]

Using cellular / android I have no problems using default MTU, only on Windows / fiber and DSL I issued connectivity problems and solved it with 1293 (?) in client config.

[Seimus]

Not saying it cant work with default MTU but there is a BUT.

I had the same but for cell network depending on ISP.

As I do a lot of traveling across the EU, I have seen instances where on some Cell providers the Default MTU didn't worked. Even if the WG tunnel was established and handshake was seen, keep-alive was working. The moment I wanted to access HTTP/s it basically wasn't working well.

In order to combat that lowering the MTU on the WG client in the APP helped. The value I provided is tested across half of the EU Cell providers.

Regards,
S.

[cookiemonster]

Sorry for intrusion,

But, if you did correct your config for WG as was advised.

Do you see in live logs permit for the specific source and destinations being hit with permit?
Also this issue is only related to HTTP/s?
Did you do as well MSS clamping (Normalization)?

If you are connecting WG over cell, set on the client WG app [Interface] as well MTU 1390.

Regards,
S.

That's OK. I'm asking for help.
I will try this value 1390.

[cookiemonster]

Using cellular / android I have no problems using default MTU, only on Windows / fiber and DSL I issued connectivity problems and solved it with 1293 (?) in client config.

Thanks but no windows or dsl here. I could try the 1293 value though. Thanks.

[cookiemonster]

I do wonder now that I have written my methodology if I have a flaw there.

Methodology has been to disconnect the mobile phone from wifi and use cellular. Allow wifi tethering to it. Connect laptop vi wifi tethering to the phone. wg-quick up the wireguard client on the laptop. Try to open 192.168.5.1:55443 or 192.168.5.1:8080 (adguardhome) or ssh to another lan machine.

So when I connect the mobile phone to the cellular network and the laptop wirelessly to it (wifi, personal hotspot), then the phone will need to nat the laptop. Although the laptop has its wg client set to allowedips=0.0.0.0 , would the NAT need something else to be bypassed by the tunneling via 0.0.0.0 ?

If yes, then though checked and I can continue with testing with these MTU values.

[Seimus]

Well you NAT at L3, VPN such as WG is a bit higher right.

So you will NAT the IP of LAPTOP with the IP of the Phone. What is allowed in WG is basically telling what traffic destination should go via the tunnel. NAT considers only NATing the IP of the Laptop (source of the tunnel) itself as the WG header is encapsulated by the L3 header.

 [IPv4] > [WG] > [Payload]


As for testing, why not to try WG on the phone over cell first. And then move the WG on the Laptop over Phone tether? One less headache in the middle.

Regards,
S.

[cookiemonster]

Well you NAT at L3, VPN such as WG is a bit higher right.

So you will NAT the IP of LAPTOP with the IP of the Phone. What is allowed in WG is basically telling what traffic destination should go via the tunnel. NAT considers only NATing the IP of the Laptop (source of the tunnel) itself as the WG header is encapsulated by the L3 header.

 [IPv4] > [WG] > [Payload]


As for testing, why not to try WG on the phone over cell first. And then move the WG on the Laptop over Phone tether? One less headache in the middle.

Regards,
S.

have done bud. On the phone only it works as expected. Once I thether the laptop to it, the laptop can't get to LAN, the problem I'm trying to understand and solve.

[Seimus]

Indeed interesting!

Well at least this confirms the config is alright, the issue smells like a potential problem with the MTU.

So the next steps should be:
1. WG client on Laptop
2. Laptop connected to mobile via tether
3. Mobile on cell (LTE/5G) network
4. Change WG MTUs
5. Check if you hit rules, WAN rule for WG to be established
6. Check if you hit WG rule for traffic pass

Additionally maybe as well a capture on the WAN and WG interfaces to see whats going on.

There could be really a MTU overhead due to headers, cell networks can be wacky as I described. If the WG encrypted packet is somewhere on the path fragmented you could have such issues.

Regards,
S.

[cookiemonster]

MTU is what a few have mentioned and I'm yet to test. The configs do seem right, and only the MTU changes are left to yet do from diagnosing so far. I did do some captures last night but I had to abandon it for other reason.
Will try again but with MTU changes.

[chemlud]

Well you NAT at L3, VPN such as WG is a bit higher right.

...

Actually WG is layer 3

https://www.wireguard.com/papers/wireguard.pdf

[Seimus]

Well you NAT at L3, VPN such as WG is a bit higher right.

...

Actually WG is layer 3

https://www.wireguard.com/papers/wireguard.pdf

Indeed

Regards,
S.

[cookiemonster]

Hi. I have made progress. First, I had the client misconfigured with the wrong server's public key, so without realising it, I was not establishing the wg tunnel. Or rather I did realise it at some point but going back to basics, allowed to solve that part.
So I can still by setting 0.0.0.0/0 on the client, route all outbound connections i.e. open internet successfully.
At least that is and allows me to focus on the original problem, unable to reach the LAN behind the OPN on 192.168.5.0/24
I set the logs on for all even default rules and that showed that the don't seem to be hitting the firewall. There are no blocks although I haven't done any more tcpdumps yet.
Before I go back to those, can someone please see if what I'm missing are network routes on the client?
When the wg tunnel is down, these are the routes on the client:

Code: [Select]

default via 192.168.4.1 dev wlp58s0 proto dhcp metric 600
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
192.168.4.0/22 dev wlp58s0 proto kernel scope link src 192.168.7.227 metric 600
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown Then when the wg tunnel is up, they are thus:

Code: [Select]

default via 192.168.4.1 dev wlp58s0 proto dhcp metric 600
10.0.0.0/24 dev wg0 proto kernel scope link src 10.0.0.4
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
192.168.4.0/22 dev wlp58s0 proto kernel scope link src 192.168.7.227 metric 600
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown Wg up:

Code: [Select]

penguin@saturn:~$ curl https://192.168.5.1:55443
curl: (7) Failed to connect to 192.168.5.1 port 55443 after 3058 ms: No route to host
penguin@saturn:~$ ping 192.168.5.1
PING 192.168.5.1 (192.168.5.1) 56(84) bytes of data.
From 192.168.7.227 icmp_seq=1 Destination Host Unreachable
From 192.168.7.227 icmp_seq=2 Destination Host UnreachableFirewall rule from wg to LAN is pass for all protocols on IPv4.
My spider senses are telling me the problem is client-side, not server side. Strenghtned by the other client (the mobile phone) with the same client settings on OPN works correctly. Naturally the client is different. Maybe the mobile client adds the appropriate routes. What do you think ?

[Patrick M. Hausen]

There is no route for anything but 10.0.0.0/24 on the client that points to the tunnel. So obviously no destination on the other side of the tunnel can be reached.

Please post the client WG config again - minus private key, of course.

[cookiemonster]

thanks Patrick. Here it is:

Code: [Select]

[Interface]
Address = 10.0.0.4/24
PrivateKey = VMVMVMVMV
MTU = 1390

[Peer]
#PublicKey = AMAMAMAMAMNC
#This one below is the server's public key
PublicKey = ABABABAB
#AllowedIPs = <Networks to which this client should have access>/<Netmask>
#             // For example "10.11.0.0/24, 192.168.1.0/24"
#             //               |             |
#             //               +--> The network area of the OPNsense WireGuard VPNs
#             //                             |
#             //                             +--> Network behind the firewall
AllowedIPs = 0.0.0.0/0
#Endpoint = <Public IP of the OPNsense firewall>:<WireGuard Port>
Endpoint = mydynamicdns:51820