Wireguard fails on cell phone connection

I have had wireguard working flawlessly for a while now including access to the openwrt router via my cell phone data plan. This let me connect to my home cameras from anywhere. However, recently, in the last 6 months or so, the cell phone stopped working with wireguard even though the android app shows that it is connected.

In my testing with the cell phone, wireguard still works from a wired internet provider (via wifi), however, if I go to whatsmyip.com, it shows only an ipv4 address. With the vpn disabled, it shows both ipv4 and ipv6.

When the cell phone is on its data plan, whatsmyip,.com shows both IPv4 and IPv6 addresses, However, with the VPN turned on, it never connects.

I'm guessing that tmobile is not doing something they used to do. I'm guessing it has something to do with IPv6.

I have attached my config files below. Has anyone gotten ipv6 to work on wireguard on openwrt?

Thanks.

 
network

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fdf2:gggg:hhhh::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        option macaddr ''
        list ports 'lan2'
        list ports 'lan3'
        list ports 'lan4'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config device
        option name 'wan'
        option macaddr 'aa:bb:cc:dd:ee:ff'

config interface 'wan'
        option device 'wan'
        option proto 'dhcp'

config interface 'wan6'
        option device 'wan'
        option proto 'dhcpv6'

config device
        option name 'eth0'
        option macaddr 'aa:bb:cc:dd:ee:ff5'

config interface 'vpn'
        option proto 'wireguard'
        option private_key '<private Key>'
        option listen_port '99999'
        list addresses '192.168.10.1/24'
        list addresses 'isp:assigned:prefix:address::/64'

config wireguard_vpn 'wgclient'
        option public_key '<public Key>'
        option preshared_key '<pre-shared-key>'
        option private_key '<private key>'
        list allowed_ips '192.168.10.2/32'
        option description 'Cell Phone Peer'

config interface 'CamLan'
        option proto 'static'
        option ipaddr '192.168.999.1'
        option netmask '255.255.255.0'
        option device 'lan1'

config wireguard_vpn
        option description 'Computer'
        option public_key '<public key>'
        option private_key 'private key'
        option preshared_key 'preshared key'
        list allowed_ips '192.168.10.3/32'

================================


firewall

config defaults
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'

config zone 'lan'
        option name 'lan'
        list network 'lan'
        list network 'vpn'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'

config zone 'wan'
        option name 'wan'
        list network 'wan'
        list network 'wan6'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config rule
        option name 'Allow_Web_Server_v6'
        option family 'ipv6'
        option dest 'lan'
        option dest_port '80'
        option proto 'tcp'
        option target 'ACCEPT'
        option limit '10/second'
        option src 'wan'
        list dest_ip '::116/-64'

config redirect
        option dest 'lan'
        option target 'DNAT'
        option name 'Asterisk'
        option family 'ipv4'
        list proto 'udp'
        option src 'wan'
        option src_dport '990-999'
        option dest_ip '192.168.1.999'
        option dest_port '9999'

config redirect
        option dest 'lan'
        option target 'DNAT'
        option name 'AsteriskRTP'
        option family 'ipv4'
        list proto 'udp'
        option src 'wan'
        option src_dport '10000-10001'
        option dest_ip '192.168.1.999'
        option dest_port '1111-2222'

config redirect
        option dest 'lan'
        option target 'DNAT'
        option name 'Apache2_ipv4'
        option family 'ipv4'
        list proto 'tcp'
        option src 'wan'
        option src_dport '80'
        option dest_ip '192.168.1.116'
        option dest_port '80'

config rule 'wg'
        option name 'Allow-WireGuard'
        option src 'wan'
        option dest_port '99999'
        option proto 'udp'
        option target 'ACCEPT'

config zone
        option name 'CamWall'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'
        list network 'CamLan'

config forwarding
        option src 'CamWall'
        option dest 'lan'

config forwarding
        option src 'lan'
        option dest 'CamWall'

config rule
        option name 'Allow_BlueIrisOut'
        list src_ip '192.168.999.999'
        option dest '*'
        option target 'ACCEPT'
        option src 'CamWall'
        option enabled '0'

config rule
        option name 'Allow_BlueIrisIn'
        option src '*'
        option dest 'CamWall'
        list dest_ip '192.168.999.999'
        option target 'ACCEPT'
        option enabled '0'

config redirect
        option dest 'lan'
        option target 'DNAT'
        option name 'Apache2-Test'
        list proto 'tcp'
        option src 'wan'
        option src_dport '80'
        option dest_ip '192.168.1.999'
        option dest_port '8080'
        option enabled '0'

        

Are you redacting certain information with 9's? For example:

It is not necessary to redact RFC1918 addresses and will lead to confusion when reading the configs. If these are not redacted, they are invalid.

Meanwhile, you've also (maybe) redacted the port number for the WG config...

We don't necessarily need to know the actual port number, but it is critical that it is consistent between the network, firewall, and remote peer configs.

That said, let's check a few things:

  1. What does your remote peer config look like (from your phone)?
  2. What is the output of wg show?
  3. what are the first two octets of ifstatus wan | grep address (in bold: aaa.bbb.ccc.ddd)
  4. Can it connect properly if you are on the lan (via wifi)?
  5. If it can't connect while on wifi, does it connect if you change the endpoint host on the phone's config (in the peer section) to 192.168.1.1 (still then trying to connect while on wifi)?
1 Like

Just curious. You mention only receiving an IPv4 address when connected to VPN, but you mentioned IPv6 when disconnected.

Then I noticed this:

This is incorrect. I'm not sure why you have this configured instead of IPv6 from your home.

Yes, I redacted everything including the local addresses and port numbers. The wireguard port numbers are consistent on both ends. So the following holds true:

Android---> --[wifi]--> --[openwrt]-->[whatsmyIP.com] === returns both ipv6 and ipv4.

Android--> --[data-plan]-->[whatsmyIP.com] === returns both ipv6 and ipv4.

Android--> --[wireguard(client)]--> --[wifi]--> --[openwrt]--> --[wireguard(serv)]--> [whatsmyIP.com] === returns only ipv4.

Android--> --[wireguard(client)]--> --[data-plan]--> --[openwrt]--> --[wireguard(serv)]--> [whatsmyIP.com] === No connection.

I don't know how to run wg from android. On the interface section:
Addresses: 192.168.10.2/32, fdaa:bbcc:ddee::2/128 <-- not redacted
DNS servers: 192.168.1.1, [My:routers:full:dedicated:ipv6:address]

In the peers section I have: Allowed IPs:0.0.0.0/0,::0/0
The endpoint is [my public domain:[wgport#]

Here is the result from ifstatus run from openwrt. I don't know how to run it from android:

ifstatus wan | grep address
        "ipv4-address": [
                        "address": "REDACTED.PUBLIC.IPV4.ADDRESS",
        "ipv6-address": [
                "ipv4-address": [
                "ipv6-address": [

In replying I noticed the public domain name is there on the cell phone, but I don't think it will return an AAAA IPv6 record. So this might be part of the problem. But I don't think it explains why there is no connection to anything when on wireguard and the data plan. I know for a fact that google.com supports both ipv4 and ipv6, but it wont work.

Do you see anything that would cause it to fail on the data plan?

[UPDATE]: I got my AAAA record to point back to the router's main IPv6 address and then set that into the cell phone WG config, but there was no change in operation.

The problem might be in my understanding of how WG works. It would seem that the WG client connects to the WG server using either ipv4 or ipv6 and all IP traffic from the client is consolidated onto one port channel and sent to the WG server. The WG server then takes the data from the single WG port expands the traffic and outputs all the original traffic in its original form whether it be ipv4 or ipv6. So if the client to server connection is over ipv4, then an app on the phone should be able to connect to google.com via ipv6 over the WG channel.

Could you elaborate on the error you found?

Perhaps someone could use different wording.

I clearly showed where you entered your cell carrier's IPv6 range into your home router configuration.

My apologies, you entered your ISP's range, did you route this subnet to the WG interface?

Do you actually have IPv6 Internet connectivity (from the ISP) at home?

That might be the wrong entry. The current line is the ISP prefix, but shouldn't it be the suffix?

Yes, both the home and cell phone have IPv6 connectivity.

I don't understand the question or why you mentioned a suffix. I asked was it routeed to your WG interface.

Also, is this a static prefix issued by your ISP?

If not, I don't understand how this is expected to work.

I don't understand the question about routing to the wg interface. The prefix comes from the main openwrt page under the IPv6 upstream section. So I assume it is from the ISP. The actual prefix has been redacted here, but in the real configs, it has the correct one.

This prefix is entered on NETWORK > INTERFACES > VPN > GENERAL SETTINGS inside of LUCI under the IP addresses section. The first address is an IPv4 address and it is "192.168.10.1/24". The second is the IPv6 prefix which I suspect is wrong. Wrong as in it doesn't belong there, not wrong as not the prefix. I'm thinking this should be an "Fxxx:..." range or something similar.

Sorry if I'm being a bit anal regarding redacting stuff. Ever since I got hacked with openvpn and ssh, I have been a bit paranoid. This morning a bunch of stuff isn't working that was working fine last night and I am concerned about another possible intrusion due to misconfigured wireguard or IPv6. This morning, for the first time in years, openwrt decided to change the local ip address (both IPv4 and IPv6) of my web server despite it being set to static.

Yesterday, I spent most of the day trying to get IPv6 addresses to update with my DDNS provider (before it was only IPv4). OpenWRT doesn't have a good mechanism for that. With IPv4, you want to send the DDNS provider your router address and the router will port forward from there. With IPv6, everything has a direct address and you need to send that address to the DDNS provider not the address of the router. So I had to make a little script to extract the correct address from nslookup. It seemed to be working right last night. This morning, the server has a different address and its not working right.

Here is my IPv6 update script here:

#!/bin/sh

HOST_NAME="${1:-LocalHostName}"      <<< the local name for the server 
LOCAL_DOMAIN="lan"                              
FQDN="${HOST_NAME}.${LOCAL_DOMAIN}"

# Call nslookup using the openwrt DNS6 server.
# Use grep, tail and awk to filter out the IPv6 we want.
SERVER_IP=$(nslookup -type=AAAA "${FQDN}" 127.0.0.1 2>/dev/null | \
    grep 'Address' | \
    grep -v '127.0.0.1' | \
    grep -E ' (2|3)[0-9a-fA-F]{3}:' | \
    tail -n 1 | \
    awk '{print $NF}')

# ----------------------------------------------------
# OUTPUT
# ----------------------------------------------------
if [ -z "${SERVER_IP}" ]; then
    # Return nothing if lookup failed to find a valid GUA
    exit 1
else
    # Output the public IPv6 address
    echo "${SERVER_IP}"
    exit 0
fi

Although this script works, I am not convinced that nslookup is 100% stable as it has done some strange things when I use it from the command line. Now, when I use "ping -4 server.lan" it tries to ping the static server IPv4 address which is now the wrong one so it doesn't work. if I use "ping -6 server.lan" it gets the new ipv6 address and ping works.

I think this IPv6 stuff has seriously messed up my router.

{UPDATE] - There is a bug in openwrt that causes the above mess when you select SET STATIC on the dhcp lease from the dashboard. if the dhcpv4 has already be made static with "SET STATIC" then when you do the same thing on the dhcpv6 lease, it makes a second entry in the static DNS entries. The IPv6 entry doesn't have an IPv4 entry. So when the system seraches for the host, it stops on the IPv6 entry, presumably because its last in the list, and doesn't get an IPv4 static lease entry. The result is that both the IPv4 and IPv6 interfaces get random assigned suffix values. Nothing works because apparently, the DNS server searches from the top down and returns the correct static address, but since it doesn't match the dhcp assigned address, nothing works.

The workaround for this bug is to delete the second entry in the static lease table that was for IPv6. Then edit the original static entry for IPv4 and select the correct IPv6 DUID. Leave the IPv6 suffix blank. Hit save, save and apply. Then the machine with the bad address needs to have its IP renewed. The easiest way is to just reboot it. So far, this solution has been working well. Sadly, it doesn't fix wireguard, but at least everything else works.

Maybe my notes can be helpful it includes ipv6 setup

2 Likes

Thanks!!! This was a major help in getting wireguard up and running under IPv6. When connected to wifi, whatismyipaddress.com reports both ipv4 and ipv6 addresses.

One note is that I used a compatible local IP address for both ipv4 and ipv6 that was in the same subnet as the regular router stuff. That way nothing special was required to access the local lan. With ipv4 I used the same 192.168.10.0/24 and ipv6 the same local prefix that openwrt was assigning to local machines.

Also, my openwrt router has an ipv6 domain name pointing to it. So in the cell phone has the ipv6 domain name. In theory, the phone is connecting via ipv6. It was a major deal to get openwrt to work with ipv6 DDNS. There is a bug in openwrt that makes a mess of things.

Anyhow, thanks for writing those instructions up, they really helped. Unfortunately, it appears that Tmobile (my carrier) seems to be blocking UDP traffic - so it works great on wifi, but not at all on data. The fact that the phone shows the checkbox as connected is disturbing because its obviously not connected. I guess getting around that is going to still be a challenge.

Of course it could be a blocking problem.
But otherwise it could be MTU related you can try to diminish mtu on both sides to 1280

Yes, it is definitely a port blocking problem. I have found numerous posts online about other people with similar problems. Apparently it didn't kick in where I live until recently. I haven't been able to figure out how to change the MTU on my cell phone. Some people have suggested changes to the access point name settings, but Tmobile and Android 10 don't allow editing or changing that info.

Sadly, its not looking good for wireguard since it currently only allows tunneling over udp ports. There is openvpn, but I already tried and dumped that one because it used tcp ports which are inferior to udp when it comes to vpn. They do have UDP to TCP converters, but I don't know if any of them will run on a cell phone.

Although Openvpn is slower and more difficult to setup using that with tcp is probably your best choice.

Alternatively have a look in the guide in the introduction section about cgnat using a man in the middle might also work because you start with an outbound connection.

I have a free oracle cloud vps which can be used for that but also started exploring netbird which also works well

I'm also thinking about getting a different cell phone provider. I also noticed that my VOIP app doesn't work on Tmobile data either since it uses UDP for the connection. Blocking all UDP ports is like giving me half the internet. I also learned in my research that tmobile also plans on getting rid of 4G LTE starting as soon as January next year. Not everybody at once, but phasing out phones that can't do 5g.

I've had security issues with OpenVPN in the past which is why I prefer not to go that route. I understand wireguard's reasons for not supporting TCP, but nefarious characters like Tmobile seem to be mandating everyone stop using UDP. It would be nice if Wireguard would come to the rescue by offering a TDP option. The source code is out there, but it Wireguard is a kernel app so it might not be trivial.

In the mean time, I'll have to duck in to a McDonalds or some place that has an open wifi in order to access my wireguard.

Then they're on the same pace as when they phased out 3G. Even so, they offered a 3G phone (which 3G didn't work in the US any longer) until last year.

BTW, I use 1342 MTU on my Wireguard app config when connecting thru T-Mobile.

(You probably cannot change the phone's MTU without rooting, but I don't understand why you would anyway.)

Actually T-mobile allegedly still supports 3g and even 2g, but people using 3g and 2g phones have a ridiculously small number of channels available to them. So their quality of service is likely going to be emergency calls only. I suspect, without proof, that they will do the same with 4g LTE and allow the phones to still work, but with noticeably crappy service so people will give up and upgrade to 5g. They have already reallocated part of their 4g spectrum to "Extended Range 5g" which lets 5g punch through walls better.

I don't know why I didn't think about the MTU in wiregaurd. I was thinking about the one in the phone itself. Ether way, I'm 100% convinced that it is T-mobile. Voip uses UDP also and those channels are all down for everyone on my asterisk server that uses a Voip cell phone app. I didn't put it together until now.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.