DId you take the ‘Drop-In Gateway’ out of the equation?
yes. And I’ve tried using both Android and iPhone. Not working…
Are you using DDNS or are the WG Client’s attempt to connect to the Public Internet/WAN IP? It’s not apparent fr the output that was posted fr wg show
.
public IP, as recommended.
See, this is what’s doing my head in ATM: LAN → LAN WG is good, yeah? You should need to do nothing more than duplicated that same setup but change out the [Endpoint]
IPs & port (1194) & be all set.
I’m at a loss here. Can you do a port scan your Pubic Internet/WAN IP fr Ning or similar while using Mobile Data (being a wholly separate Internet connection)? If 1194 works, that should show as open. If 51820 is open, that should work.
Cripes; it must be time for a cup of tea.
with Ning, I can only scan the network I am connected to. That is, I cannot scan my fixed public IP from Ning if I am not connected to local WiFi.
I can eventually use something like this Open Port Check Tool - Test Port Forwarding on Your Router
Just tried this webtool, both 1194 and 51820 are closed.
Well fcuk… I think we’ve found the problem. CG-NAT might well be in play if you know the modem’s ports are open on your end.
I’ve opened a ticket to my ISP. Let’s see what and when they will answer…
actually, I think that tool scans TCP ports.
I’ve found another one which scans UDP (UDP Port Scanner, Online UDP Port Scan, UDP Port Scanning | IPVoid), and seemingly my 1194 is open, but 51820 is “Open|filtered”.
So, most probably it’s the CG-NAT at play blocking my WG Server…
…one working week later, and after everyday talking with my ISP, each day they’ve told me they’ve fixed the port forwarding issue (and after they’ve remotely reset my AIO router/modem for a few times, like I do not know how to do that), I’m in the same situation: the port still doesn’t seems to be correctly forwarded as the WG is still not working. Let’s see what the next week will bring from my ISP…
You’re probably dealing w/ Tier 1 ‘support’; fcuk’em. PM me your Public Internet IP & I’ll set up a cronjob to scan :51820 & log its status every five 60 minutes. You can then take the logs to Tier 2.
Here’s what my Flint v1 looks like when acting as a WG Server, scanning from the upstream Slate AX:
root@slateax:~# nmap -sU -p 51820 192.168.12.137 | grep udp
51820/udp open|filtered unknown
yeah!
Thank you, but that is not going to help to open it. I’m pretty sure that their higher level support will not care about my logs. Let me keep pushing on them until they will do what I need them to do.
Perhaps not but you’ll have evidence Tier 1 is neglectful/full of shyte if/when you (may) need to escalate to someone that knows exactly WTF they’re doing. The offer stands for whenever you may want it.
You might want to start recording your calls w/ them… but do note IANAL.
Thank you again, but I think it’s not (going to be) the case as I’m not in the US…
so, I’ve talked with the ISP (with the person doing the configurations and routing and so on), they’ve told me that CG-NAT is not applicable to my ONT. Also, they said whatever port I fwd on my router is shall work fine, as they are blocking/filtering nothing.
Still strange that 1194 is working fine with OpenVPN without even being forwarded, but 51820 is not. Still, on LAN the WG is ok, but over internet is not. But if I try using 1194 for WG, it doesn’t work.
I am running out of ideas…
This sounds more like an issue with WG itself. Did you already try to delete all configs and start over?
I’m seconding @admon 's thought; @2992 : I think it may be time to reinstall the current stable firmware.
(Read: fire is the cleanser!!!1!11!!1eleventy!1!!!oneoneoneone!)
yes, for a few times, and also I’ve reset both routers for a few times.
yeah, this will be one of the things I’ll do next. And start the whole setup from scratch…
“keep settings” or not?
so, I’ve kept the settings. Same story, no change: OVPN works fine, WG nope.
I’ll do it again without keeping the settings… but I’ll need to spend some time for to reconfigure them both.
Try WG first. Something could be awry w/ the device setting up routes.