The allowed IP's for your peer should be 0.0.0.0/0 NOT /32. (That literally means that only IP 0.0.0.0 is allowed). I'm pretty sure that's your problem since 0.0.0.0 is not a valid IP that anyone is assigned.
this post was submitted on 20 Dec 2023
27 points (93.5% liked)
Selfhosted
39985 readers
761 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 1 year ago
MODERATORS
Well, that was a silly mistake. Thanks for noticing it. I rebuilt the client side several times yesterday, so I can't say for certain I made that typo each time, but it's possible.
I just blew out the whole thing, both sides, and rebuilt it from scratch using a different UDP port and it's all working now.
One issue I've had in some networks is that wg will connect, but not receive any traffic from the network. You can try to set up a static route for your wg subnet pointing at your wg server's local IP.
No idea if that's your issue though.
It definitely not connecting. I get no handshake stats on either side and my tcpdump shows 0 packets to try and even initiate the tunnel.
This probably does not apply for you but don't try sending wg over port 53, learned the hard way some routers simply won't pass non-dns packets there.
~~Otherwise considering you are able to access VPS stuff from phone but not the router connected to the same VPS then I would check~~
- ~~if forwarding is enabled on the vps~~
- ~~if you can't see any packets on the router side then it sounds like a routing issue at the vps~~
E: I am too baked and assumed you are trying to have the VPS as a central hop point.
My backup plan is to route the traffic through the VPS to the home network. I was hoping to avoid that hop.
I’ve encountered a similar issue with WireGuard on my iOS and macOS devices. On iOS, I need to first connect to the VPN, then disable and re-enable both Wi-Fi and cellular data before the traffic begins flowing through the tunnel. On macOS, the process involves connecting the tunnel and toggling Wi-Fi off and on. It seems like I have to reset the network connection on the device after establishing the tunnel to get it working. I’m also using OPNsense with the WireGuard plugin.
Sounds like it may be the same issue so I hope that this helps!
I'll give it a try, thanks.
If your VPS can connect to your home router as a client it sounds like your wireguard server on opnsense is working correctly.
Might be a problem with your phones WG config. Have you tried taking the client .conf file from your VPS and loading it onto your phone to test a working config file?
I didn't think the wg-quick conf is compatible but I'll look into that in the am.
For the love of all that is holy
At least change the interface IP. I multiboot my laptop and when I copied a wg.conf being lazy, the server basically ignored the newer client. I had to boot back into the OG OS and add a peer via ssh. I'm still learning wg but don't count on clones interfaces working.
All I meant was, it hadn't occurred to me that the android app and wg-quick used the same file format. I can certainly give this a try.
Show the conf file for your ubuntu endpoint, and maybe a screenshot of the server/peer on the opnsense server. Redact keys and endpoint hostnames.
I'll have to do that in the morning.
Have you been down the MTU rabbit hole? The wg-quick helper scripts are supposed to find the best MTU but I've found cases (tethering) where I had to adjust. Too big an MTU and you could silently drop packets.
Are you virtualizing opnsense? I am, and the wg plugins and config felt foreign to me it was easier to virtualize a wg endpoint.
Have you been down the MTU rabbit hole?
No. I'm going to look into that and do some testing today. Perhaps there's something wonky between my mobile and home ISPs in that regard.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
| Fewer Letters | More Letters |
|---|---|
| HTTP | Hypertext Transfer Protocol, the Web |
| IP | Internet Protocol |
| NAT | Network Address Translation |
| TCP | Transmission Control Protocol, most often over IP |
| UDP | User Datagram Protocol, for real-time communications |
| VPN | Virtual Private Network |
| VPS | Virtual Private Server (opposed to shared hosting) |
[Thread #366 for this sub, first seen 20th Dec 2023, 02:45] [FAQ] [Full list] [Contact] [Source code]
Is wireguard hosted on opnsense, or an internal device that the port is being forwarded to?
If it's on opnsense, be sure you route outgoing traffic on that port over the correct gateway, possibly even an extra rule to be sure the proper reply-to is set. Opnsense used to do the gateway routing configuration automatically, but once wg got added to the kernel, you're now required to manually specify the gateway in your rules for it to work properly.
Also, if you see zero packets, then as others mentioned, try a different mtu. Some service providers (mobile, and even hotels) try to block all VPN traffic altogether and they do this by measuring the mtu of the packets. A little tweaking might get it to work, although I'd expect this to have held true for the VPS too, honestly.
Is wireguard hosted on opnsense, or an internal device that the port is being forwarded to? opnsense. I do have the interface and gw configured and was able to successfully connect when I did the test config from my VPS.
Also, if you see zero packets, then as others mentioned, try a different mtu. Some service providers (mobile, and even hotels) try to block all VPN traffic altogether and they do this by measuring the mtu of the packets.
I didn't think about MTU. I'll do some research and testing on this today.
A little tweaking might get it to work, although I’d expect this to have held true for the VPS too, honestly.
This is why I'm struggling. Every test I do is successful, by all rights this should be working. Phone to VPS, GOOD. VPS to opnsense, GOOD. Phone to VPS, BAD. Can I see packets from the phone to opnsense, YES, unless it's wireguard.
I'll experiment with MTU and see if that bears and fruit. Thanks.
New Lemmy Post: Weird Wireguard issues I could use some help with. (https://lemmy.world/post/9772632)
Tagging: #SelfHosted
(Replying in the OP of this thread (NOT THIS BOT!) will appear as a comment in the lemmy discussion.)
I am a FOSS bot. Check my README: https://github.com/db0/lemmy-tagginator/blob/main/README.md
Did you setup a NAT on the firewall? You have to setup a static NAT on the interface that your Public IP sits on and to the private IP address of your VPS (you are using a private network space from one of the other interfaces on your FW right?).
Make sure that the policy that you create with the NAT includes UDP 51820 (unless you changed the default port) People often mistake using TCP which is a different protocol. If that doesn’t work, then look at the traffic on your FW
Meant to say if you still get stuck, run Wireshark on your FW and your VPS and run a tcp dump and filter the traffic to see where the data stops.
You can also use traceroute to your public IP on the port 51820 and check your connectivity or even curl: -v http:////publicip:51820
Yeah I would probably try if the phone can actually access anything on that port.
On router: netcat -vvvl 0.0.0.0 51820
On phone: http://router_ip:51820
The browser will fail opening it but on router you should see the first incoming HTTP GET packet.
Or one could run a local shell on the phone (assuming android) and try netcat too.
(or this http server one liner python3 -m http.server can be used instead of netcat)
I have an network tools app that lets me test arbitrary ports and I do see those packets on a tcpdump, but this app (and you're suggestions above) are all TCP while Wireguard listens on UDP. I haven't come up with a way to test UDP from the phone yet.
Netcat can do UDP with -u flag, to get netcat on the phone (android) you could try local shell (Connect Bot app can do it) and try calling the local netcat (nc, though it's a simple busybox implementation so it might not have all the features). Not sure if it would let you send udp just like that.
They call it a tcpdump but Wireshark analyzes all network traffic. You can use the udp.port == 51820
Do you have a laptop? Probably more tools and easier to test from there.
There's some confusion here. I'm running wireguard on my opnsense router and I'm trying to connect my Android phone to it.
I just used the VPS to help troubleshoot to show other clients can connect to opnsense AND the phone can connect to other servers but the phone and opn won't talk.
I know this screams config issue. I've gone over it and rebuilt it multiple times. I can't find anything wrong. Someone else asked to see configs so I'll post those tomorrow.
It is a config issue. Allowed IPs for your client should be 0.0.0.0/0 not 0.0.0.0/32