Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WireGuard: Beyond the most basic configuration

sloonz.github.io

Post reply on HN
Print view View original

61–70 of 115 posts

Re: WireGuard: Beyond the most basic configuration

#61

Post by denkmoon »

NhanH wrote: post #46
jwiz wrote: post #44

Earlier quoted context omitted.

There is a dynamic IP on the external address, from their ISP.

Yeah but you don't use the external IP for the purpose of accessing your VPN (not via a DNS record anyway). I am also unclear on the purpose of the dynamic DNS.

Really?

Imagine, if you will, the following scenario: I have a wireguard endpoint on my home router. The home router uses a residential ISP connection and I don't want to pay $10/mo for a static IP because my ISP is cheeky and expensive. I want to have my phone connect to said wireguard endpoint to establish a secure link. I don't want to have to change my wireguard configuration on my phone every time my home IP changes.

So, I set my phone to peer with the wireguard endpoint on `home.denk.moon:1234`. Every time my home router's external IP changes, it sends a dynamic DNS update to my DNS server such that `home.denk.moon` reflects the new IP for my router. Now, whenever my phone attempts to connect to wireguard, it will resolve that domain name, get the latest IP for my router, and connect.

Re: WireGuard: Beyond the most basic configuration

#62

Post by denkmoon »

speakspokespok wrote: post #57
denkmoon wrote: post #39

Earlier quoted context omitted.

I've been very pleased with powerdns for my self hosted internal DNS services. It implements basically everything you want for even the most esoteric DNS setups, and IMO, quite sanely.

I've tried many times to setup PowerDNS and never complete it because I get bogged down in the complexity. I saw they had an ansible / terraform script for deployments. Do you just use the team's docs or something else?

Yeah just the PDNS docs. They're excellent. I'll admit my personal setup isn't particularly complex, but I'm not sure how much more complex it can get. I've just got an authoritative server for `lan.` and two secondaries, all 3 using sqlite as their database.

I just added their debian repo and apt install'd the two packages (dnsdist and pdns-server). Set the respective config files appropriately (dnsdist is a little hard, but googling got me there) and bam. I've got dnsdist serving DoH, DoT, and plain port53 DNS with some ACLs, was really easy IMO.

Re: WireGuard: Beyond the most basic configuration

#63

Post by logicziller »

One that I could not get to work properly with Wireguard is port-forwarding without masquerading.

I need the source IP to remain intact, but unless I add 0.0.0.0/0 to the AllowedIPs, the Wireguard peer will drop the packet. If I do add 0.0.0.0/0 to AllowedIPs then it adds a route which prevents the response from my application to go back to the source.

Eventually gave up on it. Nobody had a clue how to fix this or what actually needs to be in the nft or firewalld rules for this to actually work properly.

Re: WireGuard: Beyond the most basic configuration

#64

Post by mbilker »

logicziller wrote: post #63

One that I could not get to work properly with Wireguard is port-forwarding without masquerading. I need the source IP to remain intact, but unless I add 0.0.0.0/0 to the AllowedIPs, the Wireguard peer will drop the packet. If I do add 0.0.0.0/0 to AllowedIPs then it adds a route which prevents the response from my application to go back to the source. Eventually gave up on it. Nobody had a clue how to fix this or wh…

If you are using `wg-quick`, then you need `Table = off` to disable adding routes to the system route table automatically. After that, then you can add routes manually.

Re: WireGuard: Beyond the most basic configuration

#65

Post by pm2222 »

sevg wrote: post #6

I've always been slightly puzzled about why there isn't an easy built-in way to tunnel all traffic (ie, AllowedIPs = 0.0.0.0/0, ::/0) EXCEPT for some specific IPs. You end up having to programmatically generate a massive list of CIDRs that include everything except those specific IPs.

ip route to blackhole works. ip rule works. ip/nftables works. tc works. ebpf works.

Re: WireGuard: Beyond the most basic configuration

#66

Post by graton »

mbilker wrote: post #64
logicziller wrote: post #63

One that I could not get to work properly with Wireguard is port-forwarding without masquerading. I need the source IP to remain intact, but unless I add 0.0.0.0/0 to the AllowedIPs, the Wireguard peer will drop the packet. If I do add 0.0.0.0/0 to AllowedIPs then it adds a route which prevents the response from my application to go back to the source. Eventually gave up on it. Nobody had a clue how to fix this or wh…

If you are using `wg-quick`, then you need `Table = off` to disable adding routes to the system route table automatically. After that, then you can add routes manually.

This is the answer. I too ran into the same issue. Took me awhile to figure this part out.

Re: WireGuard: Beyond the most basic configuration

#67

Post by graton »

sevg wrote: post #6

I've always been slightly puzzled about why there isn't an easy built-in way to tunnel all traffic (ie, AllowedIPs = 0.0.0.0/0, ::/0) EXCEPT for some specific IPs. You end up having to programmatically generate a massive list of CIDRs that include everything except those specific IPs.

I think you need to use `Table = off`. With that you probably can get what you want.

Re: WireGuard: Beyond the most basic configuration

#68

Post by Salgat »

yjftsjthsd-h wrote: post #49
NhanH wrote: post #46

Earlier quoted context omitted.

Yeah but you don't use the external IP for the purpose of accessing your VPN (not via a DNS record anyway). I am also unclear on the purpose of the dynamic DNS.

Your external IP is dynamic because the ISP can rotate it. You want to reach your home's external IP to VPN in. One common way is to create a public DNS record that's dynamically updated (by a cronjob or whatever) to always contain whatever IP your ISP last handed you.

That's what I do. Just a cronjob on my TrueNAS server to query my IP and update my subdomain's A record if my IP has changed. That way when a power outage happens and my IP gets rotated, it makes no difference.

Re: WireGuard: Beyond the most basic configuration

#69

Post by [deleted] »

logicziller wrote: post #63

One that I could not get to work properly with Wireguard is port-forwarding without masquerading. I need the source IP to remain intact, but unless I add 0.0.0.0/0 to the AllowedIPs, the Wireguard peer will drop the packet. If I do add 0.0.0.0/0 to AllowedIPs then it adds a route which prevents the response from my application to go back to the source. Eventually gave up on it. Nobody had a clue how to fix this or wh…

[deleted]

Re: WireGuard: Beyond the most basic configuration

#70

Post by tptacek »

icelancer wrote: post #37

No RBAC is sad, though understandable. Wireguard is so much faster than OpenVPN. We use Wireguard for S2S but unfortunately need OpenVPN for our employees and contractors due to RBAC. All posts and writeups we've found trying to shoehorn RBAC into Wireguard ultimately ends up with people saying "don't do this."

The point of the WireGuard design is to be agnostic to "upper-layer" concerns like this; it's a fast (optionally) kernel-resident secure transport that you can build whatever you'd like on top of. WireGuard isn't about RBAC and doesn't have a "don't do RBAC" position.
Post reply on HN