@jdub absolutely sorry for “ignoring” the previous post - I wanted to edit and add more information - so decided to delete it and create a new post. Sorry about it.
So, a few updates: Yes I do know the Main Router as ISP → port forwarding to Flint
In terms of your comments:
- I tried to connect my device to different WiFis
- Also tried to use mobile network (instead of Wifi)
- Also tried to “expose” to the internet and try the WG - did not work
I also tried to use different ports instead of the default. Also tried to create a Rule under Firewall → Open Ports on Router (for UDP)
If I go to Dynamics DNS and try “DDNS Test” I have the following message :
Final note - because I have the Flint and the Slate Plus - I tried for both (the Mac Address matched 100% for Slate and similar to Flint)
I have looked for guidelines on my ISP router (available online) and I think I’m doing everything correctly…
How can I make sure I have a static public ip address?
I also tried DDNS → did not work
The ddns test function is buggy.
But from the images seems that you didn’t enable ddns.
Try test your ddns using dnschecker.org
I activated the DDNS now :
Does this mean it is working? (your website)
This, however, does not change anything in terms of Port Forwarding from the ISP, right?..
Should I try to do what I was doing but edit the WireGuard Peer Endpoint to DDNS:PORT ?
You can just edit.
It seems you just enabled the ddns so it takes time to propagate. It should takes 10 minutes.
updating here, 25min have passed and your website looks better:
I have checked and I do have a Public IP : DHCP enabled - YES
the info I get:
I saw your another post and on Android I do not have the info you highlighted : Wireguard Server on GL-AXT1800 Slate AX - #5 by alzhao
what should I do?
So you have both vpn client and server configured on the router?
ISP router → Port Forwards → to Flint (Which has the WG Server Configured) → Then Client on Travel Router (Now testing with Android Device)
Ok, looks like you’re making some progress, so that’s good. My recommendation at this point would be to break the problem down and see where the issue is.
So I’d probably do:
start by making sure the Wireguard server is actually working correctly in the first place. Edit your config file to use the local (192.168.X.X) IP and get that working first.
find your public IP by googling “what is my IP”. Then try manually editing your file to connect to that IP. Leave the Flint as the DMZ host for the moment so we can eliminate that variable. Try this from your cell phone if you can, or from a completely different network (someone else’s house/apartment).
if that doesn’t work, it may be that your ISP is blocking inbound traffic. That’s usually not the case with high port UDP traffic, but possible.
We can always start looking at configs, etc, but if you’re DMZed then it shouldn’t be a forwarding issue.
Today is a holiday where I am, so I won’t have a ton of time to respond but I’ll try to check in on this as I can.
Just an update: I checked with @pedritocs97 remotely and found that the ISP only gives IPv6 IP address. So thing are a little different now.
I will update once I get a solution.
I read somewhere that “IPv6 is not fully supported on the flint and may result in leakage on ipv6 connections. I would recommend you just not use it.”
Hopefully, I can still use it safely…
Hey, I actually found out I can do the following: " 1 Set up a public IPv4 subnet in the FRITZ!Box"
Does this work?
It was actually already set up and looks the following:
edit: i think you are right, it says "Internet, IPv4: FRITZ!Box uses a DS-Lite tunnel "
What you’re looking at here is your internal IPv4 network, not an internet facing one. If your ISP allows you to get an external IPv4 address that would be what you’re looking for. The help page you posted would require your ISP to hand out those addresses.
IPv6 will make things more complicated in several ways:
- If you’re planning on using it to connect back to your house while traveling you’ll need to have IPv6 at your remote site (generally not true in hotels). You can sort of get around this, probably, by building an IPv4->IPv6 tunnel (Hurricane Electric, maybe?), but goodness that’s a pain.
- IPv6 just makes it easier to make mistakes and/or leak traffic over the IPv4 tunnel. It’s not that you can’t do it safely (if obfuscation of your traffic is the goal), but you just have to be a lot more careful.
Can you contact your ISP and see if there’s any way you are able to get an external IPv4 address (can be static or dynamic).
Keeping everyone up to date, I’m going to try to help @pedritocs97 with a Tailscale solution, which I think may handle all of the IPv6 weirdness for us. Hopefully.
I am sure it will work, but lets make things more complicated with another service running.
You can use www.astrorelay.com to relay the wireguard server.
Hey, I’m totally open to any suggestions you have for doing a pure Wireguard implementation where you’ve only got IPv6 running on the server (and where you may not have IPv6 running at all on the client side), since that’s something I’ve never attempted.
Tailscale seems like it will handle that with some penalty in performance (and, admittedly, without the main GL.iNet interface, which I generally don’t prefer anyway). In other words, it looks like it will potentially handle the tricky parts of this setup in its overlay and probably give you a direct connection (rather than relay) most of the time. May not work, but worth a try, I think.
(disclosure: I’m running TS as my main VPN solution on my AXT1800 right now, and at least for my purposes I’ve found it excellent. But I have a rather more complicated setup and need to access 6-10 data centers, which that allows me to do quite easily).
adding the IPv4 rules
PostUp = iptables -t nat -A POSTROUTING -o ens5 -j MASQUERADE;
PostDown = iptables -t nat -D POSTROUTING -o ens5 -j MASQUERADE;
In the IPv6 rules,adding a rule to forward traffic to the internet interface.
PostUp = ip6tables -A FORWARD -i ens5 -o wg0 -j ACCEPT; ip6tables -A FORWARD -i wg0 -j ACCEPT;
PostDown = ip6tables -D FORWARD -i ens5 -o wg0 -j ACCEPT; ip6tables -D FORWARD -i wg0 -j ACCEPT;
Should look like this:
Address = 10.66.66.1/24, fd42:42:42::1/64
ListenPort = 60002
PostUp = iptables -t nat -A POSTROUTING -o ens5 -j MASQUERADE; ip6tables -A FORWARD -i ens5 -o wg0 -j ACCEPT; ip6tables -A FORWARD -i wg0 -j ACCEPT;
PostDown = iptables -t nat -D POSTROUTING -o ens5 -j MASQUERADE; ip6tables -D FORWARD -i ens5 -o wg0 -j ACCEPT; ip6tables -D FORWARD -i wg0 -j ACCEPT;
AllowedIPs = 10.66.66.2, 2a05:d014:926:ffaa:87dd:ffff::2/128
but that is just making ipv6 preferred over ipv4.
Right, but it’s not a matter of just adding firewall rules, it’s a matter of making the peer connection, right? If your server is v6 only (as a public), then your v4 only client can’t connect to it directly because, well, it can’t resolve the v6 public address.
The v6 server is (presumably) using some sort of tunnel to actually access v4 traffic, so it’s going to be able to reach an external v4 address. Which would be great, except that you don’t know what the public IP of your hotel is going to be before you get there.
To put the problem succinctly, if I’m at a hotel and I only have IPv4 access, and my home router only has an external IP address of a21b:b6f0:e9ec:9d11:5c48:7c4c:1054:2e32, how do I build a wireguard client config to connect back to that server?
All of the overlay networks (Nebula, Zerotier, Tailscale) kind of inadvertently solve that problem, though in different ways.
A big shout out to @jdub who was able to fix my problem completely with ipv6 on server side and ipv4/ipv6 on client side, no need to port forward- WG running perfectly exactly as needed. You rock!!!