Configuring my Wireguard Server to redirect incoming traffic

Networking Networking Software
21

This outgoing NAT over wg0 is good, lots of people do similar hairpin NAT setups, just be warned that it’s a big hammer…

… the issue is that it becomes impossible to differentiate clients based on source IP… to Plex they’ll all look like they’re coming from Linode’s wg0 IP.

Depending on how security concious you happen to be…this might or might not matter to you.

On the other hand, not doing this NAT, …

… while it may not bring you additional security by itself, provides the Plex host with one more piece of information (IP address) that can be used to differentiate clients and maybe do some additional firewalling or filtering in the future, should you choose to do so, in the future.

You can set Allowed IPs to 0/0 on both sides, and disabling all NAT-ing on either router on either side of the Wireguard link (with exception of your ISP interface), and just setting a static route on Linode to tell it to talk to your pfSense for your LAN IPs, it might be a bit better than what you have now with the hairpin (-ish) NAT over wg0. Security wise it’s about the same.

To reiterate, nothing wrong with your current setup, just a bit complex, maybe harder to secure.

22

so if I where to change the up script to the below

#!/bin/bash

iptables -A INPUT -i eth0 -j ACCEPT
iptables -A INPUT -i wg0 -j ACCEPT
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 32400 -j DNAT --to-destination 10.1.0.2
iptables -t nat -A POSTROUTING -s 10.1.0.0/24 -o eth0 -j MASQUERADE
iptables -A FORWARD -i wg0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o wg0 -j ACCEPT

with the wireguard config being this

[Interface]
Address = 10.1.0.1/24
ListenPort = 51830
PrivateKey = 
PostUp = /etc/wireguard/up.sh
PostDown = /etc/wireguard/down.sh

[Peer]
PublicKey = 
AllowedIPs = 0.0.0.0/0
PersistentKeepAlive = 25

would that route all traffic to the PFsense router preserving its original info? so that if i was to get bad traffic I could then block it there?

23 
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 32400 -j DNAT --to-destination 10.1.0.2

would be

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 32400 -j DNAT --to-destination 10.0.6.7

there’d be no masquerading or source nat

On Linode: AllowedIPs = 10.1.0.2/32, 10.0.6.0/24
On pfSense: AllowedIPs = 0.0.0.0/0

If AllowedIPs doesn’t bring up the route to 10.0.6.0/24 via 10.1.0.1 … You’ll need to add one manually - or add it to post-up.

Now, here’s the complicated part… because I just dislike having to deal with FreeBSD and pfSense… and also I’m too lazy to fire up pfSense in a VM just for this forum today (sorry :frowning: )

You’d disable nat on pfSense’s Wireguard interface, pick “Do not use” or something like that from the interface configs in the UI.

Also, there’s plenty of folks who use pfSense around on these forums,… one of them might try to make sense of pf for me and you

On pfSense, in pf.conf you’d have something like

pass in quick on wg0 reply-to 10.1.0.1 keep state

I’ve no idea whether this actually works and where to look for proper documentation other than source code (…and that’s way too much effort).

In general, I’ve always been stumbling through pfSense UI, and checking whether I got things right by looking at pfctl -s all; but as I said, there’s tons of folks who actually use pfSense for a living on these forums, one of them might know how to use reply-to properly.

What will happen after will be that on Plex logs you’ll see the source IP of your phone on 5G or whatever… if you tcpdump wg0 or Linode or pfSense, or anywhere really, like the Ethernet adapter of your Plex host, you’ll notice a connection between your 5G IP and 10.0.6.7 in all cases. That means you can apply smart filtering anywhere, even, for example, you can scrape Plex logs with fail2ban and apply filters on Linode in response to failed login attempts.

24

I went with

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 32400 -j DNAT --to-destination 10.1.0.2

As I prefer my PFsense to do routing within the network and I have set up this connection as a gateway for my network. I have tested it this morning and PFsense sees the correct incoming IP now and I am logging the incoming connections/packets just incase I do need to block someone.

1 Like
25

Some great information here guys, I am currently trying to do the same setup so i can access some of my services through cgnat.

I have a VPS with wireguard installed and an active tunnel to my pfsense box. I can access my internal servers / network through the WG tunnel using their internal IP addresses however i cannot seem to get the port forwarding working.

@target-bravo
Are you able to put up some screenshots of your NAT rules so i can check them out.
Also have you setup any outbound NAT rules to disable NAT on outbound traffic etc?

my VPS wg0.conf

[Interface]
PrivateKey = 
ListenPort = 55107
Address = 10.0.0.1/24

PostUp = /etc/wireguard/up.sh
PostDown = /etc/wireguard/down.sh

[Peer]
#On Prem pfSense
PublicKey = 
AllowedIPs = 10.0.0.2/24, 192.168.1.0/24
PersistentKeepAlive = 25

VPS up.sh

#!/bin/bash

iptables -A INPUT -i eth0 -j ACCEPT
iptables -A INPUT -i wg0 -j ACCEPT
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 5001 -j DNAT --to-destination 10.0.0.2
iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE
iptables -A FORWARD -i wg0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o wg0 -j ACCEPT

tcpdump on vps when trying to navigate to VPS-IP:5001 from an external computer

image
image1314×66 4.64 KB

tcpdump from internal server

image
image1512×110 10.8 KB

Looks like it is doing some port re-mapping on the reply? Is that normal behaviour ?

26

[S] is a TCP syn, you’re redirecting it through wireguard

[S.] is a TCP syn,ack ; it exists, which is good, but it’s not coming through for some reason.

What about tcpdump on the pfSense Wireguard interface on pfSense?

Btw, no need to censor private 192.168./10./ IPs - we all have them. (oh, and when censoring public IPs, can you annotate the blurring with X / Y or similar?

You can pass -n to tcpdump to not resolve IPs into DNS names.

27

Ok lets try a couple of those again.
tcpdump of wg0 on VPS when trying to navigate to VPS-IP:5001 from an external computer

image
image1206×125 7.17 KB

tcpdump of wg0 from my pfsense box

image

Oh yep my bad!

28

Internal host is sending replies, pfSense is not sending them back through wg0… you’ll probably find the syn-acks going out to your ISPs interface… because that’s what routing tables on pfSense look like.

@PhaseLockedLoop you do lots of pfSense stuff…
…how does reply-to work - isn’t it supposed to be enabled by default, any way of dumping tracked connections? Does it require routes with a lower metric in addition to firewall rules?

(e.g. on Linux you’d add a second routing table with a default route through other end of the Wireguard tunnel, you’d mark incoming connections from wireguard using connmark, you’d connmark --restore the value to a packet in pre-routing packets coming from lan, and you’d use ip rule to make packets belonging to connections initiated through Wireguard use the routing table that sends things through Wireguard)

1 Like
29

OPNsense but its the same back end. Could you expound on what you are talking about. Potentially a screenshot?

The issue you discuss is related to routing. Make sure you have the routes and firewall rules set for it properly. Past that I’m not entirely certain. What software? What need? How is it using the WG interface. Things I kind of need to know to be accurate in my reply

30

Software is a 3CX PBX… I’m not even touching the SIP or RTP ports etc yet, just focusing on the HTTPS port for web console access - which runs on port 5001.

This is the NAT rule i setup to forward traffic from WG0 interface Port 5001 to PBX

image
image1455×1226 133 KB

This is a tcpdump from the PBX server. I know the NAT rule is doing something as if I disable it i don;t see this traffic reach the PBX.

image
image1521×65 6.28 KB

Is the PBX trying to communicate out of the WAN instead of sending traffic back through the tunnel ?

31

Yes, that’s how it looks.

But that shouldn’t be happening as per the docs:

Disable Reply-To
The firewall adds the reply-to keyword to rules on WAN type interfaces by default to ensure that traffic that enters a WAN will also leave via that same WAN. In certain cases this behavior is undesirable, such as when some traffic is routed via a separate firewall/router on the WAN interface. In these cases, check this option to disable reply-to only for traffic matching this rule, rather than disabling reply-to globally.

…

Can you screenshot wireguard interface settings?

32

image
image1154×1127 103 KB

33

Ipv4 upstream gateway, what if you added a new gateway/default route over 10.0.0.1

would that make pfSense treat this interface as a WAN-like interface, and would that cause it to render reply-to rules into pf ruleset (as per the docs)?

Would it allow you to set the metric field on that route to make that default route lower priority than the default route coming from your ISP DHCP cgnat?

34

I did try setting 10.0.0.1 as gateway as suggested however i saw the same behaviour. I have it set as 10.0.0.2 as per @target-bravo configuration above.

From what i can see, the request is making it to the internal PBX server and the internal server is responding.

image
image1421×61 5.37 KB

However, i think the return traffic from the pbx server may be going out the WAN instead of going out through the WG tunnel ?

image
image938×1278 123 KB

35

:person_facepalming: i have just worked it out…

Rules on the WireGuard group tab are matched first, so ensure rules on the group tab are removed, disabled, or do not match traffic which requires reply-to .

I had to disable the default allow all wg traffic rule on the WireGuard group interface as these rules are processed first even if the WG tunnel is assigned its own interface…

Thanks for the input @risk … it seems once again back to bascis and RTFM will yield results.

Cheers

1 Like