Unless this is something unique to the Android app, I am positive that it can accept a ddns based domain. That's how I have configured mine and it works perfectly on my "client" side devices (Mac, iPhone, OpenWrt).
It is possible you are putting the address into the wrong spot, so that might be the issue.
This is expected behavior if you have your allowed IPs set to 0.0.0.0/0 and the tunnel isn't working.
Yes, it does appear that way at the moment.
Let's look at the following files from your OpenWrt side:
Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
cat /etc/config/network
cat /etc/config/firewall
And we also need to look at the Android WG config.
I was surprised when you said that you were seeing such low amounts of free RAM. But clearly you have found that it is not WG that is responsible for the RAM usage. And yes, samba4 is much larger than 3.x, so this makes sense.
Not a problem.
Also not a problem. You'll simply allow forwarding from the VPN to the WAN.
Yes, but there is some nuance here. In most cases, you will indeed be able to connect to the systems as if you were local, but this needs to be done by hostname or IP address. MDNS and other 'autodiscovery'/'zero config' networking technologies do not work across subnets (generally speaking), so things like AirPrint or chromecast or Sonos controllers will not work -- these protocols are designed to only work on the local subnet. There are ways around this, but it may significantly increase the overhead/bandwidth of the VPN connection, and may not work universally. The other thing to know is that certain systems -- Windows in particular -- will have their firewalls set to only accept connections from the local subnet. That means that you may need to make adjustments to the firewalls on those devices to ensure that they will allow the connections from the remote VPN peers.
As far as the IP addressing of the VPN 'clients' is concerned - this is done as part of the configuration -- each peer will have an IP address that is known and consistent, but there isn't an automatic addressing method like DHCP.
I haven't done this (yet) myself, but I am 99% positive that it will work properly. I now that this can be done.
This is one of the great things about WG -- it is not chatty and is very efficient. This means low data usage when there isn't any active data transmissions, and low overhead when you are moving data between the sites. And yes, because your 4G site will be a 'client', it will be able to connect back to the system on the wired ISP without any issues.
Yup, this works without any issues. This is how I use mine.
You'll use VPN Policy Based Routing to achieve this. Absolutely not an issue.
The downstream devices don't need to have any knowledge of the VPN... it just works. The router will setup what amounts to a transparent tunnel.
VPN PBR will handle this.
You can actually generally treat these as one and the same. And WG is good for this application.
DD-WRT has this (to a degree) as well. But Tomato and DD-WRT are not flexible systems... if your configuration doesn't fit neatly into the box, it won't work. OpenWrt is far more flexible.
To a degree, this is about documentation more than development. Use any analogy you like here -- cars, computers, home theater setups, etc. -- there is a tradeoff here... typically systems that are optimized for ease of use have less flexibility and really work with a prescribed set of features/functions, where as the most flexible systems often cannot be as well optimized for ease of use because they allow the user to do all sorts of things that may not have been prescribed by the designers. No, you're not the only one who has trouble with setting this stuff up, but the forums exist to help. In time, you may learn enough (if you want to) to be like "yeah, I know how to do all of this stuff and I can even help others with different needs."
I'm still at the wired site but fixing to leave. I can continue as long as its stuff we can do with SSH. Regarding the ability to go to the router web page remotely, I was thinking that SSH might be able to make its own tunnel for that purpose. I'm not a SSH expert, but I have heard other people talk about it like it could do that.
Here are some files, you requested - redacted fake keys...
cat /etc/config/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 packet_steering '1'
option ula_prefix 'fdcb:d0b4:ffff::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
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 interface 'wan'
option device 'wan'
option proto 'dhcp'
config interface 'wan6'
option device 'wan'
option proto 'dhcpv6'
config interface 'vpn'
option proto 'wireguard'
option private_key 'TdWVM53EEvvJRcj2spNVg9yf6qofDGBI9UyBhHcY1Z+='
option listen_port '51820'
list addresses '192.168.9.1/24'
list addresses 'fdf1:e8a1:8d3f:9::1/64'
config wireguard_vpn 'wgclient'
option public_key 'pX2e3cMB00CIgw3TmB86P/zQXBCJdFxPwbBAsecd1wz='
option preshared_key 'exCYRANAhMq/hp3KTa0Gzkv6MDE3ceg7JJfgF8HRELF='
list allowed_ips '192.168.9.2/32'
list allowed_ips 'fdf1:e8a1:fded:9::2/128'
cat /etc/config/firewall
config defaults
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
config zone 'lan'
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan'
list network 'vpn'
list device 'ppp+'
config zone 'wan'
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
list network 'wan'
list network 'wan6'
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 src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
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 'Support-UDP-Traceroute'
option src 'wan'
option dest_port '33434:33689'
option proto 'udp'
option family 'ipv4'
option target 'REJECT'
option enabled '0'
config include
option path '/etc/firewall.user'
config redirect
option target 'DNAT'
option name '***********'
option src 'wan'
option src_dport '84'
option dest 'lan'
option dest_ip '192.168.1.111'
option dest_port '84'
config redirect
option target 'DNAT'
option name '**********'
option src 'wan'
option src_dport '80'
option dest 'lan'
option dest_ip '192.168.1.110'
option dest_port '80'
config redirect
option target 'DNAT'
option name '###########'
option src 'wan'
option src_dport '82'
option dest 'lan'
option dest_ip '192.168.1.112'
option dest_port '82'
config redirect
option target 'DNAT'
option name '$$$$$$$$$$$$$'
list proto 'tcp'
option src 'wan'
option src_dport '81'
option dest 'lan'
option dest_ip '192.168.1.127'
option dest_port '801'
config redirect
option target 'DNAT'
option src 'wan'
option src_dport '944'
option dest 'lan'
option dest_ip '192.168.1.100'
option dest_port '80'
option name '####'
list proto 'udp'
config redirect
option target 'DNAT'
option name '%%%%%%%%%%%%%%'
option src 'wan'
option src_dport '98'
option dest 'lan'
option dest_ip '192.168.1.179'
option dest_port '80'
list proto 'udp'
config redirect
option target 'DNAT'
option name '$$$$$$$$$$$'
option src 'wan'
option src_dport '32'
option dest 'lan'
option dest_ip '192.168.1.112'
option dest_port '32'
config redirect
option target 'DNAT'
option name '*************'
option src 'wan'
option src_dport '30'
option dest 'lan'
option dest_ip '192.168.1.110'
option dest_port '30'
config redirect
option target 'DNAT'
option name '&&&&&&&&&&'
option src 'wan'
option src_dport '34'
option dest 'lan'
option dest_ip '192.168.1.111'
option dest_port '34'
config redirect
option target 'DNAT'
option name '********'
option src 'wan'
option src_dport '96'
option dest 'lan'
option dest_ip '192.168.1.197'
option dest_port '80'
config rule
option target 'ACCEPT'
option _name 'pptpd'
option src 'wan'
option dest_port '1723'
option name 'PPTP'
list proto 'tcp'
config rule
option name 'Allow-SSH-WAN'
option proto 'tcp'
option src 'wan'
option dest_port '22'
option target 'ACCEPT'
config rule 'wg'
option name 'Allow-WireGuard'
option src 'wan'
option dest_port '51820'
option proto 'udp'
option target 'ACCEPT'
This may also be useful - redacted keys:
wg show
interface: vpn
public key: dvnGWDKS7C5JjbQwIvx4AsDXccCnauGMeyPfTlMZv1r=
private key: (hidden)
listening port: 51820
peer: 0CIgCJ1wzdFxw3pX2e3cMB0TmB86P/zQXBPwbBAsecd=
preshared key: (hidden)
allowed ips: 192.168.9.2/32, fdf1:e8a1:fded:9::2/128
I'll be making new keys so don't worry about these because they are fake anyway. I do have real keys, but I'm not posting them here.
I haven't completely removed pptp so you'll see iots stuff there as well.
To show the config on the cell phone will require a screen shot. That may have to wait until I get to the other location. In the mean time, I can get the actual IP address and use that.
For simplicity, you may want to remove the preshared key and the IPv6 stuff. You can add that back in when it is all working.
Although it is not required, I'd recommend making putting the VPN on its own firewall zone. you can basically replicate the lan zone and put the vpn network as shown below (don't forget to remove the vpn network from the lan zone definition).
config zone 'vpn'
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'vpn'
config forwarding
option src 'vpn'
option dest 'wan'
config forwarding
option src 'vpn'
option dest 'lan'
Well, they could go with install scripts or install programs that reduce the install overhead to a few simple clicks. I had a house guest a while back that requested guest access. I never did get that running and had to refuse them. On most other routers, its a checkbox. Anyhow, a sufficiently intelligent script could install these things easily. I mean, I installed asterisk by hand, no gui, and it wasn't this hard.
Not on this version. I get "cannot parse IP address "mydomain.no-ip.org" in interface address" when I go to save it. I am using "WireeGuard for Android" v1.0.20211029
The DNS server is set to 8.8.8.8.Under Endpoint is EndPoint. Allowed IP's is "0.0.0.0,::/0"
This is expected. The interface address is the address that is assigned to that WG interface, not the address to which it connects.
The interface address, per your WG config from the router, should be 192.168.9.2/32.
The endpoint address should be: your.ddns.domain:51820 (or just your.ddns.domain if the port is defined in a different field).
This isn't defined properly -- it should be 0.0.0.0/0 (you're missing the /0 above). The IPv6 is correct, but you should remove it for now (because it was removed from the 'server' peer).
The only place for an endpoint is in the peer section on android and putting the DNS name there gives a similar "Cannot parse" error. There is no other endpoint shown.
I corrected the 0.0.0.0/0 issue. It was actually right but I typed it wrong here.
I did type the local IP address into the interface box.
Right. This is where the ddns address should go.
you can put any valid domain name in there for the purpose of showing us that it is not parsing. For example, wireguard.ddns.com (a bogus address, at least AFAIK), but valid in syntax.
For some reason its not letting me do a screenshot.
I added the port number and it took it.
Meanwhile, I blocked the guy hammering me and he told all his friends and now they are hammering my SSH port. So I'm going to try to shut them down and may lose connectivity myself.
It doesn't give any errors but it doesn't work either. No connections through the vpn. Remember, pptp didn't work either.
I got the guys friends blocked for now, but its only a matter of time before he switches VPNs and starts hammering again.
Nothing is showing up in the logs when I connect and disconnect on the app. Seems like it would say something. I'm using logread, is there a better one?
This doesn't show up in the log... I assume because of the log spam this would cause due to the stateless interface. wg show will tell you what you need.
So, since you said you were going to regenerate keys, now would be a good time to do this.
When you create the new keys, you'll have a total of 4 keys
public and private for each of the peers.
Make sure that the OpenWrt side gets a private key (which will be placed in the wg interface definition under private key)
The corresponding public key will be placed in the Android side in the peer config section public key
You will then have another set of keys for the Android side. The private key here will go in the interface configuration, and the corresponding public key will be placed in the peer config of the OpenWrt side (public key).
It is really easy to mix up the keys since it is not possible to distinguish a private key from a public one at a human level.
And verify that the preshared key has been removed from both sides (for now anyway).
