Hello,
I tried to forward port to lan client through my VPS with wireguard server but it's impossible.
I did a test with wwan connected to my phone in hotspot and it work flawless.
schematic:
public address VPS 1.1.1.1:8081 ---> NAT to VPN WG 10.6.6.9 (ip assigned for openwrt) ---> assigned port 8081 with PBR to lan client ---> openwrt port forward.
Same configuration wwan it work, not with PPPoE wan.
If it works using the wwan interface, then it should work the same way over the wan interface.
The problem would be difficult to debug without comparing the ip rules, routing tables and the pbr status in both cases. You may also need to use tcpdump.
This generally works, but better change the subnet mask something larger (like /24) to have a route to the hole wireguard network through the wg0 interface.
You have multiple masquerading rules on the VPS and it is not clear what they do, because you posted the configuration without using the -v option and the in/out interfaces are not listed.
Does port forwarding (when using wan) still work if you move the SNAT rule to the end of the chain?
I found an explanation on the internet on the use of SNAT and NAT
The reason you need the SNAT is because otherwise your VPN client will send its return packets straight to the host which initiated the connection (z.z.z.z) via its default gateway (i.e. Verizon 3G), and not via the VPN. Thus the source IP address on the return packets will be your Verizon 3G address, and not x.x.x.x. This causes all sorts of problems, since z.z.z.z really initiated the connection to x.x.x.x.
In most port forwarding setups, the SNAT is not needed because the host performing the port forwarding is also the default gateway for the destination host (e.g. a home router).
Also note that if you want to forward port 6000 to a different port (say 7000), then the SNAT rule should match on 7000, not 6000
the strangeness is that it only occurs with the wan set to PPPoE
The problem is not that the return route is different the problem is that the router ( the connection tracking system) can be setup to classify this trafic as invalid and can block it.
DNAT is almost always used in conjunction with SNAT. SNAT is a requirement for any LAN to share one IPv4 address from an ISP or VPS. DNAT establishes a known NAT relationship for one port in order to allow incoming connections to pass backward through SNAT. The replies from the internal server are then given SNAT to change their source IP back to the public one that the Internet user knows.
The fact that there is also a VPN tunnel involved is actually only a minor concern if you can set up symmetric routing between the sites. This means that the VPS has a static route to your home LAN 192.168.1.0/24 through the Wireguard tunnel, and also that 192.168.1.0/24 is an allowed_ip on the VPS end of Wireguard. Then at the home end, do not NAT from the LAN into the Wireguard tunnel. Packets will traverse the tunnel with their original 192.168.1.X source IP and then be NATd out to the Internet by the VPS.
Then when you configure the VPS to forward (DNAT) a port to for example 192.168.1.20, that IP is internally known to the VPS. The packet from the Internet will reach your LAN server via VPN automatically without further configuration of OpenWrt, and the reply packet will go into the tunnel and be de-DNATd and returned to the Internet in the VPS.
Configuration of a VPS not running OpenWrt to do this is outside the scope of this forum.
All of this can work without PBR. Once this is working you can add PBR to make other uses of the VPN tunnel conditional, for example having some home hosts go direct to the Internet via the local ISP instead of via the VPS. Run without PBR at first in order to get the basic connection going. That would mean installing a default route via Wireguard (route_allowed_ips on the 0.0.0.0/0 allowed_ips) at home, so all Internet use goes to VPS. In any case, traffic from the public port on the home server must be returned to the VPS so that Internet users of the service get the same source IP that they used as the initial destination.
There isn't a security implication to this other than that of course anyone on the Internet can now reach a port on your server at home, so it needs to be internally hardened against that. A good security practice is to sequester that server into a separate LAN which is firewalled off from reaching https / SSH of your router and VPS, anything on your main LAN (and in some cases, even from making unrelated outgoing connections to the Internet) so that if the server is hijacked it can't be used to do internal damage.
