I am having trouble connecting to wireguard running on openwrt 18.06.5. I am traveling and the local ISP does not provide public IP. Wireguard claims that it is connected but I cannot access anything. BTW It did work back home when connected through another ISP.
2020-01-22 12:51:15.054 [APP] Status update notification timeout for tunnel 'myvpn'. Tunnel status is now 'connected'.
2020-01-22 12:51:37.366 [NET] peer(jGEi…kLUY) - Sending keepalive packet
2020-01-22 12:51:37.515 [NET] peer(jGEi…kLUY) - Receiving keepalive packet
What device is behind a double nat? Is it the ‘client’ peer attempting to establish a connection to the remote peer? Or is it the ‘server’ peer that is supposed to accept a connection from the other peer?
Also, Probably easiest if you post your config files:
/etc/config/network
/etc/config/firewall
And your remote peer’s wireguard config.
Please redact your keys and any public Ip addresses, but do not change your private ips, and make sure anything you change or redact is clearly indicated so we know it is not a mistake.
Openwrt router is the server peer in old terminology. That is connected to a public IP address. I do not have access to it. I cannot connect to it ;-). Client peer is my laptop behind double NAT
Here is the problematic configuration
laptop Remote Peer (LAN 192.x.x.x)<->Home router WAN(172.x.x.x) <->ISP Router (shows some other public address on whatismyip)<->Internet<->Server peer Openwrt router running Wireguard
I called the local ISP (remote location while traveling) and confirmed that they do not provide a public IP address.
Following setup was tested before traveling. I have not made any changes.
laptop<->router<->Internet<->Openwrt router running Wireguard
Try removing the listen port from the Interface definition -- since the laptop peer ('client') is not expecting inbound connections, this should be unnecessary, and may possibly be part of the issue.
The address on the interface should also be /32, not /24 (hopefully the 'server' side has the same /32 definition for this peer).
What is the laptop's LAN IP range? if it is 192.168.1.0/24, you may have issues because you also have that network defined in the allowed IP's (I'm guessing that is the LAN on your OpenWrt router) -- this collision could also be responsible for the issue. Try taking that network out of the peer allowed IPs.
What was your upgrade path? Did you preserve settings? If so, try reverting to defaults and configuring fresh (you can copy certain files via scp, and copy/paste bits of others, but don't blindly restore or copy over all the files).
Regarding the /32 -- a /32 subnet corresponds to a single host. That is what I meant. Don't use a /30 (I tried it and it didn't work). WG seems to work on /32 configurations only (there was another thread somewhere where this was debated, but I still recommend always going with /32).
Wireguard really isn't that picky about what IP you use. As long as you use valid addresses/subnet masks then the only issue is getting your allowed IPs right. You can use /24, /30, or /32 in the address field without an issue. Similarly you can use those masks in the allowed IPs without an issue. (As well as any other masks which may be relevant for your setup).
In the address section of the interface I use a normal mask, like /24, same as the peer mask.
In the allowed IPs part of the peer configuration you can use /32 if only this IP is expected to send traffic. Otherwise, if another subnet is connected behind the peer without NAT, then you can add more allowed IPs and route them.
@psherman I did not preserve settings intentionally. I wanted to start fresh. But I did manually copy back my other network settings such as local subnet, DNS etc. and custom firewall rules to block certain PCs going out on port 80.
/32 for single host makes sense but my current netmask is /24 and it seems to work, so I am keeping it for now. I am not at the location where it failed and the host ISP is also changed. So double NAT testing is not possible anymore but I am using it to remote-in daily now and it just works.