10
Unable to forward ports using wireguard (self.selfhosted)
submitted 1 year ago* (last edited 1 year ago) by SexualPolytope to c/selfhosted@lemmy.world
14 comments fedilink hide all child comments

Update: Sorry guys, looks like I just needed to reboot the public server.

My goal is to forward port 8096 from my private server to my public server. That, is any traffic at public server's port 8096 should be tunneled to port 8096 of my private server and back.

I've set up a wireguard tunnel and ping is working from one device to the other. In this, 10.8.0.1 is the private server and 10.8.0.2 is the public server.

Here are my config files (/etc/wireguard/wg0).

***
On the public server
***
[Interface]
Address = 10.8.0.2/24
ListenPort = 51820
PrivateKey = *****************************************

# packet forwarding
PreUp = sysctl -w net.ipv4.ip_forward=1

# port forwarding
PreUp = firewall-cmd --zone=public --add-port 8096/tcp
PreUp = iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8096 -j DNAT --to-destination 10.8.0.1:8096
PostDown = iptables -t nat -D PREROUTING -i eth0 -p tcp --dport 8096 -j DNAT --to-destination 10.8.0.1:8096
PostDown = firewall-cmd --zone=public --remove-port 8096/tcp

# packet masquerading
PreUp = iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o wg0 -j MASQUERADE

[Peer]
PublicKey = *****************************************
AllowedIPs = 10.8.0.1

***
On the private server
***
[Interface]
Address = 10.8.0.1/24
PrivateKey = *****************************************

[Peer]
PublicKey = *****************************************
AllowedIPs = 10.8.0.2
Endpoint = <public-server-addr>:51820
PersistentKeepalive = 25

Now, I'm trying to test the connection using netcat. I'm listening from my private server using nc -l 8096 (I've made sure that the port is unblocked) and trying to connect from a third device using nc <public-server-addr> 8096 but it's not working.

I have no idea what's going on here. Some help from experienced people is very appreciated.

top 12 comments
sorted by: hot top controversial new old
[-] alex@agora.nop.chat 2 points 1 year ago

You have to have a firewall rule on your public server to tell it to send any traffic on port 8096 to the IP of your private server. Currently, your public server isn't listening on that port, so the packets would just be dropped.

[-] SexualPolytope 2 points 1 year ago* (last edited 1 year ago)

Don't PreUp = iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8096 -j DNAT --to-destination 10.8.0.1:8096 and PreUp = iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE do that?

I'm new to this stuff, so I'm probably wrong. What do you think I need to do to achieve this?

[-] Max_P@lemmy.max-p.me 2 points 1 year ago* (last edited 1 year ago)

It should yeah, that's the whole point of doing that through firewall. I'm not entirely sure how MASQUERADE will interact with a prior DNAT though.

[-] alex@agora.nop.chat 2 points 1 year ago

Ah, I did the bad thing and didn't read properly.

It looks correct, yes. Can you run iptables -L -t nat on the public host after bringing up the wireguard connection to see if it works?

Also, if you can do a netcat to that same port from a local computer to that public endpoint without the wireguard connection running, you can test that the port isn't being blocked anywhere else along the way.

[-] SexualPolytope 1 points 1 year ago* (last edited 1 year ago)

Edit: Looks like I just needed to reboot the public server.

This is what I get when I do it.

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DOCKER     all  --  anywhere             anywhere             ADDRTYPE match dst-type LOCAL
DNAT       tcp  --  anywhere             anywhere             tcp dpt:8096 to:10.8.0.1:8096
DNAT       tcp  --  anywhere             anywhere             tcp dpt:8096 to:10.8.0.1:8096

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
DOCKER     all  --  anywhere            !localhost/8          ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

And yes, it's working locally. I even got it to work through the tunnel using redir but I need the masquerading to hide my private server's IP.

I saw a difference when it worked. I got server [192.168.0.5] 8096 open on connection. But I didn't see it through this setup. I simply don't get any reply at all.

[-] eskuero@lemmy.fromshado.ws 2 points 1 year ago

It's been a long time since I did forwarding through wireguard so this might be outdated, missing info or actually doing unneeded stuff but I had this notes saved in some old iptables personal documentation from like 4 years ago that might shed you some light:

Allow first packet to start the connection

iptables -A FORWARD -i eth0 -o wg0 -p tcp --syn --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -i eth0 -o wg0 -p tcp --syn --dport 443 -m conntrack --ctstate NEW -j ACCEPT

Allow already established connections

iptables -A FORWARD -i eth0 -o wg0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i wg0 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Send whatever arrives via port 80 or 443 to the other side of the wg tunnel

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.168.3.1
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination 192.168.3.1

Modify source address so it can return

iptables -t nat -A POSTROUTING -o wg0 -p tcp --dport 80 -d 192.168.3.1 -j SNAT --to-source 192.168.3.2
iptables -t nat -A POSTROUTING -o wg0 -p tcp --dport 443 -d 192.168.3.1 -j SNAT --to-source 192.168.3.2
[-] sifrmoja@mastodon.social 2 points 1 year ago

@eskuero @SexualPolytope do you have the nftables version?

[-] SexualPolytope 1 points 1 year ago

If I run iptables directly, it tells me that I have the nf_tables version.

[-] sifrmoja@mastodon.social 2 points 1 year ago

@SexualPolytope yeah. It's rare that nftables isn't the default anymore.

[-] SexualPolytope 1 points 1 year ago

Thanks. I'll try these out.

[-] Max_P@lemmy.max-p.me 2 points 1 year ago* (last edited 1 year ago)

I suspect the mixing of firewalld and iptables might not be helping there.

Other than that, -j REDIRECT might be a bit easier than DNAT, because with DNAT you also need to deal with SNAT too otherwise stuff won't come back to the client properly.

Best way to troubleshoot this would be to tcpdump on both ends, and see if packets are coming in, and if they're also coming out.

[-] SexualPolytope 1 points 1 year ago* (last edited 1 year ago)

Edit: Looks like I just needed to reboot the public server.

I was able to get it to work using redir but I do need masquerading.

load more comments
view more: next ›
this post was submitted on 08 Jul 2023
10 points (85.7% liked)

Selfhosted

39683 readers
735 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:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. 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.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS
ruud@lemmy.world
Loki@lemmy.world
CannaVet@lemmy.world
devve@lemmy.world
HybridSarcasm@lemmy.world
HybridSarcasm@lemmy.hybridsarcasm.xyz