DDNS IP different from whatismyipaddress IP leads to wg problem

echidna · August 1, 2019, 9:14am

I am trying to set up wireguard on my Openwrt router connected to the DMZ of a Huawei 4g router provided by 3UK (poor mans bridge). Both the Open wrt and the huwei router have (different) DDNS services running which both report the same IP address of 188.31.x.x. A lookup of this shows it belongs to 3UK. If I do a web lookup of my IP I get a different result 94.197.xx.xx which also belongs to 3UK
If I use the ddns url or its 188.31.xx.xx equivalent in the endpoint of my Android wireguard app no packets are exchanged with the other end of the tunnel on the openwrt router. I changed the endpoint to the 94.197.xx.xx address which worked once

I think this means that the wg setup is ok but the ddns is a problem. Can anyone confirm this and is there a fix?
Thanks

trendy · August 1, 2019, 9:51am

Could you post the ddns config? Use preformatted text (Ctrl-Shift-c)
uci show ddns
You can cover any sensitive data, like passwords.

But if I understand properly, the Huawei is bridged and passed everything without NAT to the OpenWrt router.
They both appear to have the same WAN IP (which makes sense).
However I didn't understand how did you get the different IP 94.197... Did you open on the browser some whatismyip page?
What is the output of ip -4 addr ?

iplaywithtoys · August 1, 2019, 12:01pm

I have a Three SIM and a Huawei E8372 which I use with OpenWRT and WireGuard when away from home, so I took a quick look.

First thing to note, if you weren't already aware, is that Three is very aggressive with IP address recycling; you'll rarely get the same IP address twice. So DDNS is definitely the way to go.

Second thing is that setting the Peer IP address is only of benefit if the Peer has a known static IP address. If the Peer also has a dynamic (or unknown) IP address, then you're better off not defining the Peer's IP address. That will then allow the Peer to connect from any IP address. As long as the keys match, the Peer's IP address isn't required.

echidna · August 1, 2019, 2:40pm

HI - the Huawei can not be bridged but the OpenWrt router is in its DMZ`

ddns.global=ddns
ddns.global.ddns_dateformat='%F %R'
ddns.global.ddns_loglines='250'
ddns.global.upd_privateip='0'
ddns.duckdns=service
ddns.duckdns.enabled='1'
ddns.duckdns.domain='xx.duckdns.org'
ddns.duckdns.password='xx'
ddns.duckdns.lookup_host='xx.duckdns.org'
ddns.duckdns.service_name='duckdns.org'
ddns.duckdns.ip_source='web'

The output of ip -4 addr is

root@OpenWrt:~# ip -4 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
5: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 192.168.3.1/24 brd 192.168.3.255 scope global br-lan
       valid_lft forever preferred_lft forever
7: eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 192.168.0.100/24 brd 192.168.0.255 scope global eth0.1
       valid_lft forever preferred_lft forever
8: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 10.200.200.1/24 brd 10.200.200.255 scope global wg0
       valid_lft forever preferred_lft forever

All the reported IP addresses are now the same on both DDNS services and a browser whatsmy IP lookup. As iplaywithtoys mentions 3 recycle addresses rapidly and I now wonder if this was a timing problem - DDNS services had not updated to catch a new IP.
However there are no handshakes on the Wireguard interface now that all ip's are the same.
`

echidna · August 1, 2019, 2:58pm

Just to clarify I'm trying to connect to an OpenWrt router in the DMZ of a 3 provided simple Huawei 4G router. The DDNS issue seems to be resolved and I wonder if I got an IP address from the DDNS services which had not yet been updated but the one from a web service was up to date. I still don't have any handshakes on the wg0 interface
I'm not sure what you mean by the peer IP address . On the android app there is a value for the endpoint which is where I put the xxxx.duckdns.org:51820 to point to the OpenWrt router. Are you referring to the 10.200.200.2 addresses in peer and server? The luci interface describes the wg0 IP address as recommended and the peer allowed IP as required.
Sorry if these are dumb questions, if you could share a working configuration of server and peer that would be great.

iplaywithtoys · August 1, 2019, 3:24pm

If you specify a peer Endpoint address you are telling WireGuard to accept connections only from that specific address. It increases security by preventing connections from any other address. However... if that peer address ever changes (and if it's on Three then it's very likely to change), then WireGuard will not accept incoming connections.

If you specify just the public key, but do not specify an Endpoint address, then WireGuard will accept all incoming connections with a matching key, regardless of where they originate.

Here is an example approach to configuration:

WireGuard Server:

Address = 10.200.200.1/24
PrivateKey = <random gibberish>
ListenPort = 51250

[Peer]
PublicKey = <more random gibberish - see WireGuard client on Android for correct public key>
AllowedIPs = 10.200.200.2/32

WireGuard client

Address = 10.200.200.2/24
PrivateKey = <random gibberish>

[Peer]
EndPoint = dynamic.dns.hostname:51250
PublicKey = <random gibberish - obtain correct public key from WireGuard server>
AllowedIPs = 10.200.200.1/32

You can see the difference: The server doesn't specify an Endpoint address for any peers, so it will accept all inbound connections whose keys match. The client, on the other hand, does specify an Endpoint address for its peer, so it always tries to connect to the same peer.

One final note: "AllowedIPs" is a bit of a misnomer. It actually describes which IP addresses will be forced to use the VPN tunnel, rather than which IP addresses are allowed to use the VPN tunnel.

With the example above, the client will communicate only with the WireGuard server, but nothing else. If you want to send all traffic down the VPN, change AllowedIPs on the client to 0.0.0.0/0. If you want to send only certain traffic down the VPN, change AllowedIPs to cover only the desired subnets, e.g. 10.200.200.1/32,192.168.3.0/24.

echidna · August 1, 2019, 6:06pm

My config looks similar to yours, I can't see any significant differences

config interface 'wg0'
	option proto 'wireguard'
	option listen_port '51820'
	list addresses '10.200.200.1/24'
	option private_key 'deleted'

config wireguard_wg0
	option endpoint_host 'stirlingroad.duckdns.org'
	option persistent_keepalive '25'
	option description 'Mia2lite'
	option public_key 'deleted'
	list allowed_ips '10.200.200.2/32'
	option route_allowed_ips '1'

and the output of wg show

config interface 'wg0'
	option proto 'wireguard'
	option listen_port '51820'
	list addresses '10.200.200.1/24'
	option private_key 'deleted'

config wireguard_wg0
	option endpoint_host 'blahblah.duckdns.org'
	option persistent_keepalive '25'
	option description 'Mia2lite'
	option public_key 'deleted'
	list allowed_ips '10.200.200.2/32'
	option route_allowed_ips '1'

I've tried changing allowed ips to 0.0.0.0/0 on both openwrt and android with no effect. The curious feature is that this worked transiently as shown in the first post. Any ideas welcome.

iplaywithtoys · August 1, 2019, 11:24pm

I've dug out my GL-iNet MT300N-V2, which I use when away from home. I've got WireGuard running on a Raspberry Pi at home, and on OpenWRT on this MT300N. I have the Raspberry Pi set up as the WireGuard "server" and the MT300N as the "client". I put those in quotations only to highlight the role each device plays in my setup.

Earlier I posted some config principles from memory; I can now post some actual working configuration, which may help you troubleshoot yours.

Before I get stuck in, your configuration above says that the peer (i.e. the client device) is called either "stirlingroad.duckdns.org" or "blahblah.duckdns.org" (it's not clear which). If that DDNS name is meant to be for the server, then it does not need to be (and should not be) in the server's configuration.

Here are the contents of the WireGuard "client" configuration, in /etc/config/network on the MT300N (with comments in parentheses):

config interface 'wg0'
        option proto 'wireguard'
        option private_key 'MT300N's private WireGuard key'
        list addresses '192.168.10.4/24'
        option listen_port '51280'
        option mtu '1420'

config wireguard_wg0
        option endpoint_host 'VPN server's public address / domain name'
        option endpoint_port '51280'
        option public_key 'server's public WireGuard key'
        option persistent_keepalive '25'
        option route_allowed_ips '1'
        list allowed_ips '192.168.10.0/24' (WireGuard's own subnet)
        list allowed_ips '192.168.3.0/24' (optional additional internal subnet I want to reach via WireGuard)

And here's the configuration of the WireGuard "server". It's on Raspbian, so the syntax looks slightly different than on OpenWRT, but the required information is still the same (i.e. a lot less than the client needs):

[Interface]
Address = 192.168.10.1/24
ListenPort = 51280
PrivateKey = 'server's private WireGuard key'

[Peer]
PublicKey = 'MT300N's public WireGuard key'
AllowedIPs = 192.168.10.4/32

You can see that the server has very little configuration on it. It has a private key, a listen port, and it knows about the public key and private (i.e. WireGuard) IP address of one client. It doesn't need to know the client's public IP address (or DDNS, if you use DDNS on the client). The client needs to know the server's IP address (or DDNS), but the server does not need to know the client's.

echidna · August 2, 2019, 7:36am

Thanks, I'll look at this later. I was following http://chrisbuchan.co.uk/uncategorized/wireguard-setup-openwrt/
to set up wireguard. I am still confused by the set up working for a short time then stopping. Possibly something at the 3 end?

iplaywithtoys · August 2, 2019, 12:20pm

The instructions on that website seem reasonably comprehensive but, in common with many of these copy-and-paste "tutorials", assume that nothing will ever go wrong and offer no information for troubleshooting or greater understanding of the underlying principles.

Your configuration deviates slightly from that shown on Buchan's website. The instructions show the peer's endpoint details as optional:

But your configuration indicates that you filled in the Endpoint Host field:

config wireguard_wg0
	option endpoint_host 'stirlingroad.duckdns.org'

That configuration, on the server, tells the server that your Android device is called "stirlingroad.duckdns.org". This may be why the connection is failing.

As a quick resolution, it may be worth ripping out the WireGuard configuration and starting again.

iplaywithtoys · August 2, 2019, 1:24pm

As an example, I quickly set up a WireGuard server on a spare OpenWRT box, following Buchan's instructions. Here is the result.

Excerpt from /etc/config/firewall:

config rule
        option enabled '1'
        option target 'ACCEPT'
        option name 'Allow-Wireguard-Inbound'
        option proto 'udp'
        option src '*'
        option dest_port '51820'

Excerpt from /etc/config/network:

config interface 'wg0'
        option proto 'wireguard'
        option private_key 'KIIyLxqpoNvVnIEy2PesZJGcHfT0TcJz4CvCfaDgvmE='        (private key of this server)
        option listen_port '51820'
        list addresses '10.200.200.1/24'

config wireguard_wg0
        option public_key 'IKLXVXxzHIVs874mCVO+i95TaX4vtMFFn92lHSlnigw='        (public key of the VPN client)
        list allowed_ips '10.200.200.2/32'
        option route_allowed_ips '1'
        option persistent_keepalive '25'

As you can see, there is no "endpoint_host" directive. This means that the device which announces that it has the public key IKLXVXxzHIVs874mCVO+i95TaX4vtMFFn92lHSlnigw= can connect from anywhere, no matter what its own IP address or DDNS is.

(By the way, it's usually not a good idea to post private keys in a public forum. However, I've no intention of putting this configuration into production use; it's just an illustration of what a working configuration should look like.)

trendy · August 2, 2019, 1:45pm

Moreover selecting to "Route allowed IPs" on the peer configuration of the server for a /32 address is needless. Only if the client peer is a router with more networks behind it (without NAT), which will be added in the allowed list.
Back to the DDNS issue. I can see that you are querying some webpage to find out your address. If this doesn't match the address that your router have, maybe your ISP is using some proxy.

Usually the ddns scripts run upon restart of the interface. The problem in your case is that the wan interface is always up, so you cannot really depend on it to detect IP change. Better use the ddns client on the Huawei router only, to avoid getting banned from the dyndns provider for hammering.

echidna · August 3, 2019, 10:19am

OK so I removed all wg packages and deleted remaining directory and files and went through the installation again. The relevant excerpts corresponding to those above are:

config rule
	option enabled '1'
	option src '*'
	option target 'ACCEPT'
	option proto 'udp'
	option dest_port '51820'
	option name 'Allow-Wireguard-Inbound'

LUCI did not write the "option enabled 1 line" so I edited it in.

From the network file

config interface 'wg0'
	option proto 'wireguard'
	option private_key 'key text'
	option listen_port '51820'
	list addresses '10.200.200.1/24'

config wireguard_wg0
	option public_key 'key text'
	option route_allowed_ips '1'
	list allowed_ips '10.200.200.2/32'
	option persistent_keepalive '25'

I had to add the persistent keep alive line.
I can't see anything wrong but still no handshakes and if I look at the (very long) android log it also sees no handshakes. I appreciate your help but perhaps this is not soluble?

iplaywithtoys · August 3, 2019, 10:41am

You may be able to see incoming traffic using tcpdump. If you don't already have it installed, it's a package which is available for opkg.

If you listen on the WAN interface for protocol UDP and port 51820, you will be able to tell if incoming WG traffic is even reaching OpenWRT.

If the traffic isn't reaching OpenWRT then you're looking at a DDNS issue, a Huawei modem issue, or a client-configuration issue.

If the traffic is reaching OpenWRT, but you're not seeing any WG handshakes, then you're looking at a WG configuration issue.

The purpose of the above is to try to narrow down where the failure is (or may be) occurring.

echidna · August 3, 2019, 11:58am

tcpdump -i eth0.1 port 51820

shows no packets.

I've gone over the client configuration, can't see any errors, I can ping the DDNS hostname. Don't think I can do much about the Huawei router, its very basic.

iplaywithtoys · August 3, 2019, 2:46pm

Yeah, Huawei doesn't expose much configuration for the end user. But, you do what you can with what you have.

I have an E8372 USB dongle which, fortunately, does expose a "DMZ" function. So this afternoon I set up a successfully-working WireGuard connection on OpenWRT and Android, as shown in Buchan's article, with the following equipment and software:

Huawei E8372 USB 4G modem
GL-iNet MT300N-v2 with OpenWRT 18.06.4, all post-18.06.4 opkg updates applied, and the following extra packages installed:
** wireguard
** wireguard-tools
** kmod-wireguard
** luci-app-wireguard
** luci-proto-wireguard
** ddns-scripts
** ddns-scripts_no-ip_com
** luci-app-ddns
Sony Xperia X Compact phone, running Android 8 and WireGuard app version 0.0.20190708
An account with noip.com for DDNS
The DDNS hostname lanakane.ddns.net (My choice of DDNS provider is irrelevant; I already had an account with no-ip.com and couldn't be bothered jumping through myriad hoops just to register with DuckDNS. As long as DDNS resolves to the correct IP address, then that's all that matters.)

The first thing to note is that if I did not enable the DMZ feature on the Huawei E8372, then nothing reached the MT300N. Once I enabled the DMZ feature on the E8372, then external traffic started reaching the MT300N.

So if you're not seeing any traffic hitting OpenWRT's WAN interface at all, then check the Huawei's configuration, particularly the DMZ setting.

Here are the relevant parts of the MT300N's configuration. Interface names may be different for your setup:

/etc/config/network:

config interface 'mobile'
	option proto 'dhcp'
	option ifname 'eth1'

config interface 'wg2'
	option proto 'wireguard'
	option private_key 'ILhaJHp+eK4vCdoCAR2jFtaoHlfGsKPk48DMrj2beV4='
	option listen_port '51280'
	list addresses '10.200.200.1/24'

config wireguard_wg2
	option public_key '4KEBz5GMG2SaxM/mEpMOtj0Rpz6w1/XQaFOZCZNNF1Q='
	list allowed_ips '10.200.200.2/32'
	option route_allowed_ips '1'
	option persistent_keepalive '25'

/etc/config/firewall:

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option network 'lan wg2'

config rule
	option src '*'
	option target 'ACCEPT'
	option proto 'udp'
	option dest_port '51820'
	option name 'Allow-Wireguard-Inbound'

/etc/config/ddns:

config service 'NoIP'
	option lookup_host 'lanakane.ddns.net'
	option service_name 'no-ip.com'
	option domain 'lanakane.ddns.net'
	option password 'My No-IP password'
	option enabled '1'
	option username 'My No-IP username'
	option interface 'mobile'
	option use_syslog '1'
	option ip_source 'script'
	option ip_script '/etc/ddns/myip'

/etc/ddns/myip:

curl ifconfig.co

Here are the ifconfig and route details from the MT300N:

root@mt300nv2:/etc/config# ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 0C:5B:8F:27:9A:64  
          inet addr:192.168.8.100  Bcast:192.168.8.255  Mask:255.255.255.0
          inet6 addr: fe80::e5b:8fff:fe27:9a64/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:39174 errors:0 dropped:0 overruns:0 frame:0
          TX packets:35636 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:20355546 (19.4 MiB)  TX bytes:10749832 (10.2 MiB)

root@mt300nv2:/etc/config# ifconfig wg2
wg2       Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.200.200.1  P-t-P:10.200.200.1  Mask:255.255.255.0
          UP POINTOPOINT RUNNING NOARP  MTU:1420  Metric:1
          RX packets:7075 errors:0 dropped:3 overruns:0 frame:0
          TX packets:6696 errors:0 dropped:3 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4034220 (3.8 MiB)  TX bytes:1756180 (1.6 MiB)

root@mt300nv2:/etc/config# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.8.1     0.0.0.0         UG    0      0        0 eth1
10.200.200.0    0.0.0.0         255.255.255.0   U     0      0        0 wg2
10.200.200.2    0.0.0.0         255.255.255.255 UH    0      0        0 wg2

Here is the relevant setting from the Huawei E8372:

Here is the configuration of WireGuard on my Android phone:

And here's the evidence of the successful connection and response:

If you follow Buchan's instructions, they will work. If they don't, you've missed something. Bear in mind that you're making it more difficult for yourself by trying to host a server (which typically benefits from a static IP address) on a service which is infamous for aggressively recycling DHCP addresses (Three). It's not impossible to achieve (as I've just proven in the course of preparing this reply), but it is more awkward than it needs to be.

echidna · August 3, 2019, 6:04pm

As far as I can see the DMZ set up is correct as evidenced by the OpenWrt ddns reporting the correct IP address. I'm away for a couple of weeks now and will try again when back.

iplaywithtoys · August 3, 2019, 7:16pm

The DMZ function on the Huawei does not affect DDNS. DDNS is updated by an outbound HTTP/HTTPS request from the DDNS client. As long as OpenWRT can reach the Internet, it can update DDNS. All the DMZ controls is whether unsolicited inbound traffic can reach the designated device.

Take the gear with you. It's all mobile, right?

echidna · August 3, 2019, 7:38pm

Forgot to say that 192.168.0.100 is the DMZ

iplaywithtoys · August 3, 2019, 8:51pm

That shouldn't be a problem, as long as 192.168.0.100 is the actual WAN address of OpenWRT. If, for example, the WAN address has become 192.168.0.101 but the Huawei still has the DMZ set to 192.168.0.100 then nothing will come through.

What does ifconfig eth0.1 show? Is it still 192.168.0.100 or has it changed?