Question on Wireguard tunnel configuration.

[pkcouch]

Asus RT-AX3000 w/Asus-Merlin 3004.388.6_2

Server configuration:
Intranet access=on
Tunnel IPv4= 10.6.0.1/32

Sample Client configuration:
Address=10.6.0.2/32
Allowed IPs (Server)=10.6.0.2/32
Allowed IPs (Client)=0.0.0.0/0

I am new to Wireguard and by no means am anywhere close to being an expert. I "just know enough to be dangerous" .

The configuration above results in a split tunnel and I can also access my home's intranet. Websites such as "ip.me" and "dnsleaktest.com" both report my remote client's IP address at a hotel, or wherever I happen to be away from home.

Question: Is the configuration above what is expected behavior for a split tunnel? What should I change if I wanted a full tunnel?

Thank you in advance for your help!

 

[ZebMcKayhan]

Question: Is the configuration above what is expected behavior for a split tunnel? What should I change if I wanted a full tunnel?

No... the

Allowed IPs (Client)=0.0.0.0/0

Means 0.0.0.0/0 (all destination ip) should go through the tunnel. Are you sure you are not looking at the local IP obtained by webrtc?

How did the AllowediPs end up on the client side? Usually there is a way to edit/view these setting in the Wireguard app on the client device, perhaps something went wrong?

 

[pkcouch]

No... the

Means 0.0.0.0/0 (all destination ip) should go through the tunnel. Are you sure you are not looking at the local IP obtained by webrtc?

How did the AllowediPs end up on the client side? Usually there is a way to edit/view these setting in the Wireguard app on the client device, perhaps something went wrong?

The way I am looking at the endpoint's IP is to first connect my iPhone via cellular signal only, then connect via Wireguard IOS client. Then I go to Edge on my phone and try 'dnsleakdetector.com' and 'ip.me'. Both report the IPv4 address my phone is assigned by Verizon. (Please note that this is the way I thought to check to see if I had established a full tunnel, but if this is wrong/technically incorrect, please let me know). When I am on a friend's Wifi, I get the public IP of his router. BTW, I am not sure what Webrtc is, but willing to learn.

On the AllowedIPs, during Asus/Merlin client setup, when you go to add a Peer, there is a drop-down menu for 'Site to Site Usage'. It is there you find Address, Allowed IPs (server), and Allowed IPs (client). A QR code is generated and is imported by the Wireguard client on my iPhone.

 

[bluepoint]

The way I am looking at the endpoint's IP is to first connect my iPhone via cellular signal only, then connect via Wireguard IOS client. Then I go to Edge on my phone and try 'dnsleakdetector.com' and 'ip.me'. Both report the IPv4 address my phone is assigned by Verizon. (Please note that this is the way I thought to check to see if I had established a full tunnel, but if this is wrong/technically incorrect, please let me know). When I am on a friend's Wifi, I get the public IP of his router. BTW, I am not sure what Webrtc is, but willing to learn.

On the AllowedIPs, during Asus/Merlin client setup, when you go to add a Peer, there is a drop-down menu for 'Site to Site Usage'. It is there you find Address, Allowed IPs (server), and Allowed IPs (client). A QR code is generated and is imported by the Wireguard client on my iPhone.

I have tested the wireguard from 388.7 A2 and did the same procedures as yours to setup an iPhone using iOS Wireguard client through the QR code by scanning the code with the wireguard client to get the config. My tests works as tested from a 5G or wireless network connections. I've tested it using safari and even now I tested the URL's you've posted and both showed my router's public IP which it should. I didn't even paid attention with the site to site dropdown as I think it's not relevant with this type of connection.

 

[pkcouch]

I have tested the wireguard from 388.7 A2 and did the same procedures as yours to setup an iPhone using iOS Wireguard client through the QR code by scanning the code with the wireguard client to get the config. My tests works as tested from a 5G or wireless network connections. I've tested it using safari and even now I tested the URL's you've posted and both showed my router's public IP which it should. I didn't even paid attention with the site to site dropdown as I think it's not relevant with this type of connection.

Thank you for checking. I had read elsewhere on the internet that the 0.0.0.0 was supposed to create a full tunnel. Thank you for confirming how it is supposed to work. Being a very senior member, I'm guessing you ran your test on alpha or beta firmware that'll eventually make its way to production? Since it's not a big deal for me to have a split tunnel, perhaps I need to wait until the firmware makes its way to production?

By the way, isn't removing 0.0.0.0 in the client under Allowed IPs supposed to allow split tunneling?

 

[bluepoint]

Thank you for checking. I had read elsewhere on the internet that the 0.0.0.0 was supposed to create a full tunnel. Thank you for confirming how it is supposed to work. Being a very senior member, I'm guessing you ran your test on alpha or beta firmware that'll eventually make its way to production? Since it's not a big deal for me to have a split tunnel, perhaps I need to wait until the firmware makes its way to production?

By the way, isn't removing 0.0.0.0 in the client under Allowed IPs supposed to allow split tunneling?

I'm not very good with this, all I know is it works by following the prompts and letting the default config values as is. Like what I said, I think site to site settings is only for router to router wireguard connections just ignore it. Somebody please correct me if I'm wrong.

 

[DJones]

Thank you for checking. I had read elsewhere on the internet that the 0.0.0.0 was supposed to create a full tunnel. Thank you for confirming how it is supposed to work. Being a very senior member, I'm guessing you ran your test on alpha or beta firmware that'll eventually make its way to production? Since it's not a big deal for me to have a split tunnel, perhaps I need to wait until the firmware makes its way to production?

By the way, isn't removing 0.0.0.0 in the client under Allowed IPs supposed to allow split tunneling?

I could be talking out my butt because I haven’t fully explored what you can do with WireGuard. But I think the way it works for split tunnelling is done in the client devices under Allowed IPs. 0.0.0.0/0, or 128.0.0.0/0 would be the full tunnel; I believe you can have multiple entries spaced like this x.x.x.x/x, x.x.x.x/x, x.x.x.x/x . You could also specify your network directly like 192.168.0.1/24. If you have a segregated/segmented subnet networks you’d specify that routing x.x.x.x/x for it to have access to that network assuming your segregated network isn’t using VLANs or isolated by NAT. VLAN’s probably could work, but would depend on your client device.

Not certain what adding additional peers client side would offer as it’s an additional encrypted tunnel. Maybe if you want to be two users? Or tunnel into a specific subnet only as a different peer. And maybe enable a secondary WireGuard vpn profile that only has access to an address that isn’t routable by internet?. Anyways think that’s the gist of it.

 

[ZebMcKayhan]

Thank you for checking. I had read elsewhere on the internet that the 0.0.0.0 was supposed to create a full tunnel. Thank you for confirming how it is supposed to work. Being a very senior member, I'm guessing you ran your test on alpha or beta firmware that'll eventually make its way to production? Since it's not a big deal for me to have a split tunnel, perhaps I need to wait until the firmware makes its way to production?

By the way, isn't removing 0.0.0.0 in the client under Allowed IPs supposed to allow split tunneling?

AllowedIPs exist at each side of the tunnel, both on the server side and on the client side. this is why you have the choice to change this when setting it up as AllowedIPs (server) that will go into the server side and AllowedIPs (client) that will end up on the client config that you import to your client device.

AllowedIPs on either side should represent all destination ip address that should be sent over the tunnel. like:
on any typical/normal server where you only have a single client connecting AllowedIPs (server) should only be the client wg ip (i.e. 10.6.0.2/32). as this is the only destination that is reachable on the other side of this peer connection.
In a site-2-site server config there may also be the additional "other site" LAN that exists as destinations. in this case it could be like AllowedIPs (server) = 10.6.0.2/32, 192.168.2.0/24

On The Client side (AllowedIPs (client)) on a normal roaming client AllowedIPs is usually set to 0.0.0.0/0 to send ALL data over the tunnel as this is usually what is expected by the user. The router will then route LAN data to LAN and unknown (internet) destinations to your router internet interface.
on a site-2-site client where you only want LAN data to go over the tunnel but internet locally AllowedIPs (Client) could be 10.6.0.1/32, 192.168.1.0/24. This is something you could set on your device as well if you only want to use the tunnel to access your local LAN resources but still access internet locally.

you say that you can access your "intranet" so the tunnel appears to be working, but if in doubt you should be able to go into the wireguard app and check the "latest handshake" and Rx, Tx data. if there are both ample Rx, Tx data and the "latest handshake" timer get reset every 2-3 min then the tunnel is up.

you may confirm in your client that AllowedIPs is indeed 0.0.0.0/0 to send ALL data over the tunnel so something did not go wrong with the importing of the config.

if everything still checks out ok I would assume its something with your client device.... when checking your ip make sure to get a new session, possibly use a privacy tab, so your not looking at old/cached info.

It is your client device that, in the end, decides where data should be routed. if data is not routed over the tunnel its not the routers decisions and no firmware would fix it.

 

[DJones]

AllowedIPs exist at each side of the tunnel, both on the server side and on the client side. this is why you have the choice to change this when setting it up as AllowedIPs (server) that will go into the server side and AllowedIPs (client) that will end up on the client config that you import to your client device.

AllowedIPs on either side should represent all destination ip address that should be sent over the tunnel. like:
on any typical/normal server where you only have a single client connecting AllowedIPs (server) should only be the client wg ip (i.e. 10.6.0.2/32). as this is the only destination that is reachable on the other side of this peer connection.
In a site-2-site server config there may also be the additional "other site" LAN that exists as destinations. in this case it could be like AllowedIPs (server) = 10.6.0.2/32, 192.168.2.0/24

On The Client side (AllowedIPs (client)) on a normal roaming client AllowedIPs is usually set to 0.0.0.0/0 to send ALL data over the tunnel as this is usually what is expected by the user. The router will then route LAN data to LAN and unknown (internet) destinations to your router internet interface.
on a site-2-site client where you only want LAN data to go over the tunnel but internet locally AllowedIPs (Client) could be 10.6.0.1/32, 192.168.1.0/24. This is something you could set on your device as well if you only want to use the tunnel to access your local LAN resources but still access internet locally.

you say that you can access your "intranet" so the tunnel appears to be working, but if in doubt you should be able to go into the wireguard app and check the "latest handshake" and Rx, Tx data. if there are both ample Rx, Tx data and the "latest handshake" timer get reset every 2-3 min then the tunnel is up.

you may confirm in your client that AllowedIPs is indeed 0.0.0.0/0 to send ALL data over the tunnel so something did not go wrong with the importing of the config.

if everything still checks out ok I would assume its something with your client device.... when checking your ip make sure to get a new session, possibly use a privacy tab, so your not looking at old/cached info.

It is your client device that, in the end, decides where data should be routed. if data is not routed over the tunnel its not the routers decisions and no firmware would fix it.

better explanation then I could give.