Allowing Incoming WAN Connections for WireGuard Client Listed in Director

[Nick B]

Hello,
I've searched high-and-low for a specific answer to my problem here, but I wasn't able to find any. I'm trying to route incoming connections (in this case, 443) that come in over the WAN to my NAS, but the packet never seems to arrive. Here's a diagram of the flow:

Client not expecting packet from different IP; drops.
               ┌───────────────────────────────────┐
               │                                   │
               │             ┌──────────────────┐  │
               ▼             │    GT-AX16000    │  │
 ┌───────────────┐           │     (Merlin)     │  │
 │ Internet Host │  Outgoing ├───────┐   ┌──────┤  │
 │               ├──────────►│  WAN  │   │ WGC1 ├──┘
 └───────────────┘   to 443  └───┬───┴───┴──────┘
                                 │           ▲
                                 │           │
                                 │           │
                                 │           │
                                 │           │
                                 │  ┌─────┐  │
                                 └─►│ NAS ├──┘
                                    └─────┘ Traffic Gets
                                            sent over WG
                                            instead?

I have no evidence to suggest that the packets are going out over WGC1, but since that's the usual problem, and the issue only starts when I turn on the VPN connection, I assume that's the issue. The only other possible problem is that I use YazFi, although just out of the box.

Enable NAT is Yes
Inbound Firewall is Allow

I've tried adding numerous entries into netfilter via iptables, like connection tracking, and adding the port forwarding / INPUT ACCEPT rules into WGCI, and even adding the DNAT entry into both (not at the same time) PREROUTING and WGCF. Nothing works. I tested that it wasn't some kind of issue with the target machine by testing a different machine, which still doesn't work either.

My VPN Director is setup with one entry: the target NAS as the local IP, set to go over WGC1.

Having the port accessed via the VPN is not only unacceptable, but it's technically impossible.

My current iptables:

-A INPUT -j YazFiINPUT
-A INPUT -p icmp -m icmp --icmp-type 8 -j INPUT_PING
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j logdrop
-A INPUT ! -i br0 -j PTCSRVWAN
-A INPUT -i br0 -j PTCSRVLAN
-A INPUT ! -i lo -p tcp -m tcp --dport 5152 -j logdrop
-A INPUT -i br0 -m state --state NEW -j ACCEPT
-A INPUT -i lo -m state --state NEW -j ACCEPT
-A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A INPUT -p icmp -j INPUT_ICMP
-A INPUT -p gre -j ACCEPT
-A INPUT -j WGSI
-A INPUT -j WGCI
-A INPUT -j OVPNSI
-A INPUT -j OVPNCI
-A INPUT -j logdrop
-A FORWARD -j IPSEC_DROP_SUBNET_ICMP
-A FORWARD -j IPSEC_STRONGSWAN
-A FORWARD -i br0 -p udp -m udp --dport 123 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i br0 -p tcp -m tcp --dport 123 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -p tcp -m tcp --dport 853 -j YazFiDNSFILTER_DOT
-A FORWARD -j YazFiFORWARD
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j WGSF
-A FORWARD -j OVPNSF
-A FORWARD ! -i br0 -o eth0 -j logdrop
-A FORWARD -i br0 -o br0 -j ACCEPT
-A FORWARD -m state --state INVALID -j logdrop
-A FORWARD -m conntrack --ctstate DNAT -j ACCEPT
-A FORWARD -i br+ -p tcp -m tcp --dport 853 -j DNSFILTER_DOT
-A FORWARD -j WGCF
-A FORWARD -j OVPNCF
-A FORWARD -i br0 -j ACCEPT
-A FORWARD -j logdrop
-A OUTPUT -p udp -m udp --dport 53 -m u32 --u32 "0x0>>0x16&0x3c@0x8>>0xf&0x1=0x0" -j OUTPUT_DNS
-A OUTPUT -p tcp -m tcp --dport 53 -m u32 --u32 "0x0>>0x16&0x3c@0xc>>0x1a&0x3c@0x8>>0xf&0x1=0x0" -j OUTPUT_DNS
-A OUTPUT -j OUTPUT_IP
-A DNSFILTER_DOT ! -d 192.168.1.1/32 -j REJECT --reject-with icmp-port-unreachable
-A FUPNP -d 192.168.1.20/32 -p tcp -m tcp --dport 32400 -j ACCEPT
-A FUPNP -d 192.168.1.20/32 -p udp -m udp --dport 41641 -j ACCEPT
-A FUPNP -d 192.168.1.20/32 -p tcp -m tcp --dport 16881 -j ACCEPT
-A INPUT_ICMP -p icmp -m icmp --icmp-type 8 -j RETURN
-A INPUT_ICMP -p icmp -m icmp --icmp-type 13 -j RETURN
-A INPUT_ICMP -p icmp -j ACCEPT
-A INPUT_PING -i eth0 -p icmp -j logdrop
-A OUTPUT_DNS -m string --hex-string "|10706f697579747975696f706b6a666e6603636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0d72666a656a6e666a6e65666a6503636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|1131306166646d617361787373736171726b03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0f376d667364666173646d6b676d726b03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0d386d617361787373736171726b03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0f3966646d617361787373736171726b03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|1265666274686d6f6975796b6d6b6a6b6a677403636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|086861636b7563647403636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|076c696e77756469056633333232036e657400|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0f6c6b6a68676664736174727975696f03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0b6d6e627663787a7a7a313203636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|077131313133333303746f7000|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|057371353230056633333232036e657400|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|077563746b6f6e6503636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0e7a786376626d6e6e666a6a66777103636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0a65756d6d6167766e627003636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0b726f75746572736173757303636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|037777770b726f757465722d6173757303636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0377777709617375736c6f67696e03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0d72657065617461722d6173757303636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|037777310b726f757465722d6173757303636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 1/sec -j RETURN
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j logdrop
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j RETURN
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -j logdrop
-A SECURITY -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j RETURN
-A SECURITY -p icmp -m icmp --icmp-type 8 -j logdrop
-A SECURITY -j RETURN
-A WGCF -o wgc1 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
-A WGCF -o wgc1 -j ACCEPT
-A WGCF -i wgc1 -j ACCEPT
-A WGCI -i wgc1 -j ACCEPT
-A WGSF -o wgs1 -j ACCEPT
-A WGSF -i wgs1 -j ACCEPT
-A WGSI -p udp -m udp --dport 51820 -j ACCEPT
-A WGSI -i wgs1 -j ACCEPT
-A YazFiDNSFILTER_DOT ! -d 192.168.1.1/32 -i wl3.1 -j YazFiREJECT
-A YazFiFORWARD -d 192.168.1.18/32 -i wl3.1 -o br0 -j ACCEPT
-A YazFiFORWARD -d 192.168.1.251/32 -i wl3.1 -o br0 -j ACCEPT
-A YazFiFORWARD -d 192.168.1.209/32 -i wl3.1 -o br0 -j ACCEPT
-A YazFiFORWARD -d 192.168.1.128/32 -i wl3.1 -o br0 -j ACCEPT
-A YazFiFORWARD -d 192.168.1.108/32 -i wl3.1 -o br0 -j ACCEPT
-A YazFiFORWARD -d 192.168.1.101/32 -i wl3.1 -o br0 -j ACCEPT
-A YazFiFORWARD -d 192.168.1.60/32 -i wl3.1 -o br0 -j ACCEPT
-A YazFiFORWARD -d 192.168.1.59/32 -i wl3.1 -o br0 -j ACCEPT
-A YazFiFORWARD -d 192.168.1.56/32 -i wl3.1 -o br0 -j ACCEPT
-A YazFiFORWARD -d 192.168.1.23/32 -i wl3.1 -o br0 -j ACCEPT
-A YazFiFORWARD -i wl3.1 -p udp -m udp --dport 123 -j REJECT --reject-with icmp-port-unreachable
-A YazFiFORWARD -i wl3.1 -p tcp -m tcp --dport 123 -j REJECT --reject-with icmp-port-unreachable
-A YazFiFORWARD -i wl3.1 ! -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A YazFiFORWARD ! -i eth0 -o wl3.1 -j ACCEPT
-A YazFiFORWARD -i wl3.1 ! -o eth0 -j YazFiREJECT
-A YazFiFORWARD -i wl3.1 -j ACCEPT
-A YazFiINPUT -i wl3.1 -p udp -m udp --dport 53 -j ACCEPT
-A YazFiINPUT -i wl3.1 -p tcp -m tcp --dport 53 -j ACCEPT
-A YazFiINPUT -d 224.0.0.0/4 -i wl3.1 -j ACCEPT
-A YazFiINPUT -i wl3.1 -p udp -m multiport --dports 137,138 -j ACCEPT
-A YazFiINPUT -i wl3.1 -p udp -m multiport --dports 67,123 -j ACCEPT
-A YazFiINPUT -i wl3.1 -p icmp -j ACCEPT
-A YazFiINPUT -i wl3.1 -j YazFiREJECT
-A YazFiREJECT -j REJECT --reject-with icmp-port-unreachable
-A logaccept -m state --state NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logaccept -j ACCEPT
-A logdrop -m state --state NEW -j LOG --log-prefix "DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop -j DROP
-A logdrop_dns -j LOG --log-prefix "DROP_DNS " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop_dns -j DROP
-A logdrop_ip -j LOG --log-prefix "DROP_IP " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop_ip -j DROP
COMMIT
# Completed on Tue Mar 14 16:31:43 2023

Any help?

Thanks.

 

[ZebMcKayhan]

but the packet never seems to arrive.

Why do you have inbound access from your wgc1 while you state open ports this way is impossible?

So the packet arrives on wan and your port forwarding changes the destination address in nat PREROUTING. And off it goes to your nas.

Then the reply from your nas comes back, but the source address is not changed before routing (if my memory is correct). So the packet will be routed via the policy route table, where wan is not an option.

Because this packet does not appear to be replied over the same interface it is likely to be blocked by rp- filter in the router.

The only solution that comes to mind is to use connmarks and let conntrack track and mark this connection and transfer this mark to fwmark and route marked packages to wan. But its messy.

 

[ZebMcKayhan]

Something like this:
https://www.snbforums.com/threads/e...to-vpn-policy-based-routing.71993/post-785284
but instead of ipsets the initial conmarks should be put on packets cooming in from wan on your port.

 

[Rajjco]

I solved this problem by running an nginx reverse proxy on a local machine which sends https traffic to the device that's connected to the vpn.
The Internet Host in my case Is a Cloudflare ip.

My theory Is that the packets are not reaching the "nas" hence why you need a local reverse proxy with a lan ip to send the traffic to the "nas".

 

[Nick B]

I solved this problem by running an nginx reverse proxy on a local machine which sends https traffic to the device that's connected to the vpn.
The Internet Host in my case Is a Cloudflare ip.

My theory Is that the packets are not reaching the "nas" hence why you need a local reverse proxy with a lan ip to send the traffic to the "nas".

Thanks for the suggestion; however, I already have a workaround in place that is less complicated than a reverse proxy (since I host multiple sub domains).

As for the packets, we already addressed what the issue is most likely that the REPLY packets are going out the wrong interface, which is a typical wireguard problem due to it being one OSI layer lower than other VPN types.

 

[Rajjco]

Thanks for the suggestion; however, I already have a workaround in place that is less complicated than a reverse proxy (since I host multiple sub domains).

As for the packets, we already addressed what the issue is most likely that the REPLY packets are going out the wrong interface, which is a typical wireguard problem due to it being one OSI layer lower than other VPN types.

What about openvpn? I did face the same problem also with It.

 

[arkywein]

I solved this problem by running an nginx reverse proxy on a local machine which sends https traffic to the device that's connected to the vpn.
The Internet Host in my case Is a Cloudflare ip.

My theory Is that the packets are not reaching the "nas" hence why you need a local reverse proxy with a lan ip to send the traffic to the "nas".

Could you elaborate on how you’ve set i up please?

I have a similar issue. My RaspberryPi is connected to VPN through VPN Director. I want to host a Shadowsocks server there, so ideally it should work like this:
Connection comes through WAN IP, router forwards the packets to my RPi, the shadowsocks exit IP is the VPN IP, not WAN.
WAN isn’t behind VPN. I can’t get it to work, Shadowsocks just won’t connect. Once I take my RPi off VPN, then everything seems to be working just fine.

 

[arkywein]

Thanks for the suggestion; however, I already have a workaround in place that is less complicated than a reverse proxy (since I host multiple sub domains).

As for the packets, we already addressed what the issue is most likely that the REPLY packets are going out the wrong interface, which is a typical wireguard problem due to it being one OSI layer lower than other VPN types.

Hey Nick, what is your workaround?