Wireguard won't connect from WAN

I built a Wireguard server on my exactly as the tutorial shows (http://chrisbuchan.co.uk/uncategorized/wireguard-setup-openwrt/) and I can connect to it from any device on my LAN, even devices in different VLANs. But I cannot connect to it from a device on an outside network.

The tutorial shows putting the Wireguard interface in the LAN firewall zone, and then building a traffic rule to allow the listening port through the firewall. But it seems I need to do something else. Can anyone post a sample firewall config?

network.wg0=interface
network.wg0.proto='wireguard'
network.wg0.private_key='QEQiLdN**********kXjIVRwC1*****oRJR1tkS+ZH8='
network.wg0.listen_port='51820'
network.wg0.addresses='10.200.200.1/24'
network.@wireguard_wg0[0]=wireguard_wg0
network.@wireguard_wg0[0].public_key='QW3ihUL**********N5V3bBTlK******vZtGGSGvCVk='
network.@wireguard_wg0[0].allowed_ips='10.200.200.2/32'
network.@wireguard_wg0[0].route_allowed_ips='1'
network.@wireguard_wg0[0].persistent_keepalive='25'

firewall.@rule[10]=rule
firewall.@rule[10].src='*'
firewall.@rule[10].target='ACCEPT'
firewall.@rule[10].proto='udp'
firewall.@rule[10].dest_port='51820'
firewall.@rule[10].name='Allow-Wireguard-Inbound'

Do you have a publicly routable op address on your wan port? If not, or if it is cgnat, you won’t be able to connect to your WireGuard endpoint from outside your network.

3 Likes

Yes, it's a routable public IP.

And I assume the OpenWrt router is directly connected to the internet? (Not begins another router, right?)

Have you verified that the connection from within your network is actually passing through the tunnel (use traceroute on your device). Do the logs on your device reveal any details about the connection? what does the WireGuard status on openwrt say? Does it see the incoming connection and handshake?

2 Likes

Try removing this (or changing to '0')...and add this:

# in /etc/config/network

config route                                                            
        option interface 'wireguard_wg0'
        option target '10.200.200.0'
        option netmask '255.255.255.0'

If not this, you may need to check the remote device, remote network, peer's key pair, etc.

Also, what firewall zone is your wireguard_wg0 interface in; and what are its default rules?

How do you know this...?

No handshakes, cannot get to Internet...?

:thinking:

1 Like

I think your problem is that you need to use port forwarding instead of that "Allow-Wireguard-Inbound" rule.

I know I can't get to Wireguard from the internet because the client I am using, on a physically different network, will not connect, it just continually tries to handshake. On the router's physical network, I can instantly connect--because the client says it's connected and so does the Wireguard Status screen in OpenWRT.

So anyway, it does seem to me that it's likely a firewall/routing issue getting from the WAN to to Wireguard interface. To answer the question about the firewall zone, as instructed in this tutorial http://chrisbuchan.co.uk/uncategorized/wireguard-setup-openwrt/ I assigned the Wireguard interface to LAN.

It might be worth verifying that your ‘server’s’ external IP address is entered correctly in your ‘client’ peer config and/or that your domain/dynamic dns is resolving properly to the same value as your wan address.

2 Likes

@psherman, I've run whatsmyip.org multiple times to determine the public IP, and it is correct in the client. @lleachii, I tried your network changes but still no joy. Arrgghh!

I'm guessing not a lot of folks are using Wireguard, because I found at least a half dozen tutorials online and they're all slightly different. The one I used is the one linked from the OpenWRT manual page on Wireguard, and it never mentions anything about routing or port forwarding, just making a traffic rule to let the Wireguard port through the firewall....

But does that IP match the one you see on Interface wan? (not to insult you)

Then try:

Although, I thought it was an inbound rule...

And what is its: Input, Output and Forward rules? (especially FORWARD)

1 Like

Some really great ideas. Shamefully, I have to confess the problem was the ISP. I was using a cellular LTE modem as a test network for the OpenWRT router. But I found I was also unable to connect to a device on the LAN using Remote Desktop. So I switched the two ISP sources, putting the OpenWRT router on my home network (cable internet) and using the LTE modem for the remote access. BAM! Instant Wireguard connection, blazing fast!

I'll do some more digging to try and figure out why the LTE modem was blocking the Wireguard AND Remote Desktop access attempts. I had the modem in bridge mode, so everything should have been forwarded to the OpenWRT router. But somehow it wasn't--the Gibson Shields Up! website said all the relevant ports were stealth.

Anyway, for now I'll mark this as a "solution" although it is really just a mea culpa. The really great thing is that you folks gave me some very good ideas and things to try, and I feel like I learned a lot. Thanks....

Did you use a port forward? Because I can't see why that would be needed. Unless you want to use a port that's already in use. Some people like to use for example port 53 on the WAN interface with wireguard but still use port 53 on the LAN interface with dnsmasq. Wireguard always binds to all local IP addresses and you would need to listen on another port in this case and add a port forward.

1 Like
  • Reversing the modems and having success does point to the ISP
    • Check if you need a business account
  • Shields Up! should report stealth, if your firewall WAN Zone Input rule is set to DROP.
  • How did you test a "relevant" UDP port with his tool?!?!
  • Just a reminder, Wireguard uses UDP
2 Likes

As far as I am aware, most cellular based service providers use cg-nat (unless you have a carrier/plan that explicitly offers a public IP) which is why I had asked the earlier question about a fully publicly routable IP address.

your original firewall traffic rule was right, though - no need to try to do port forwarding or dnat rulesets.

As @lleachii pointed out, the sheilds-up test may not be meaningful at all given that WireGuard is udp based and it is also not “chatty” and will appear to be closed except when actually connecting via WireGuard with proper keys and such. Your Remote Desktop protocol may be a bit different in this regard, but regardless, it is generally accepted that the port scanning websites can produce flawed results (false positives and false negatives) depending on a number of factors, so they should not be treated as fully reliable indicators.

Anyway, glad you got everything working!

3 Likes

@mikma No, Although port forwarding was something I tried along the way, along with policy based routing, in the end it was not necessary. In fact, let me stress this for anyone else who finds this thread: The tutorial on setting up Wireguard that is linked in the OpenWRT manual page on Wireguard (I've given the link twice above) works perfectly if you follow it exactly. The tutorial gives an example of an Android client, and I used TunSafe, but setting up the client is the easy part.

One thing that may not be clear from the tutorial is the encryption keys, so let me spell this out: First, the command he gives puts the client keys in whatever directory you run the commands in, and it puts the server keys in /etc/wireguard. To avoid confusion, after you execute the first command to create the directory /etc/wireguard, just change to that directory before running the two commands to generate the keys. Then all four key files will be in /etc/wireguard.

The other insight not spelled out at all in the tutorial, is that you will be generating PUBLIC and PRIVATE keys for both SERVER (your OpenWRT box) and CLIENT (your remote device). So when he tells you to enter the PRIVATE key, it's the SERVER PRIVATE key you want. And when he tells you to enter the PUBLIC key (in the PEERS section of the Wireguard interface), it's the CLIENT PUBLIC key you enter. On the other end, in your remote device client setup, it's vice versa: The PRIVATE key will be the CLIENT PRIVATE key you generated, and the PUBLIC key will be the SERVER PUBLIC key. I know this is obvious for the cognoscente, but it took me a day to get this simple reality into my head.

@lleachii I have done some reading, and you're right, there are many ways the Shields Up! port testing can be unrevealing, and in fact I guess I wasn't testing UDP. Also, I'm convinced that @psherman is correct, AT&T Wireless is in fact using cg-nat, so I was doomed from the start trying to use the LTE modem as an ISP for my OpenWRT Wireguard router. In my case it doesn't matter, because this is all on a test bench and when finally installed the router will be on a true routable "business class" IP, which is what I swapped to when I made my discovery. The LTE modem works great for remote access, i.e. connecting a Wireguard client to it.

I'll have to say again, Wireguard is truly amazing! Virtually instant connection, no perceptible overhead (blazing fast--or as fast as your internet connections on either end), and in fact really easy to set up in OpenWRT if you simply follow the tutorial linked above. There are other things you can do in the config, like restricting allowable clients, using "nonstandard" ports, etc. But for now, I'm happy, and I hope others find this thread and don't spend days pulling their hair out only to find that the problem is with their ISP. Try connecting with Remote Desktop first--that's how I found out that AT&T was sabotaging my work (it didn't work either)....

1 Like

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