Sorry, but I didn’t understand what you said. Can you please rephrase it.
Do you want me to run the following in the sys-net’s terminal?
nft add rule qubes custom-dnat-nginx iif == “wls6” ip saddr 192.168.0.0/24 tcp dport 80 ct state new,established,related counter dnat 10.138.18.170
nft add rule qubes custom-forward iif == “wls6” ip saddr 192.168.0.0/24 ip daddr 10.138.18.170 tcp dport 80 ct state new,established,related counter accept
yes, exactly 
you should have run it already, as you said it in the first post (the command was copied from that post), but the current ruleset does not seem to have the rules. So whether you did not type them (would be weird) or they failed and you overlooked the output (which can be hard to understand), or this is something else and we need to dig further.
This is what I have at the moment in my qubes-firewall-user-script:
if nft add chain qubes custom-dnat-nginx ‘{ type nat hook prerouting priority filter +1; policy accept; }’; then
nft insert rule qubes custom-dnat-nginx iif == “wls6” ip saddr 192.168.0.0/24 tcp dport 80 ct state new,established,related counter dnat 10.138.18.170
nft insert rule qubes custom-forward iif == “wls6” ip saddr 192.168.0.0/24 ip daddr 10.138.18.170 tcp dport 80 ct state new,established,related counter accept
fi
I have disposables so I use that file. But I did paste the commands directly now as you said, and it didn’t affect it
Actually, when I copy as you typed, it prints me an error:
Error: syntax error, unexpected junk
and it points on the == “wls6”
but I removed the " from it and it passed without errors, but still I can’t curl or access the nginx
what about the output of this now?
elements = { 10.138.18.170 }
elements = { "vif77.0" . 10.138.18.170 }
iif "wls6" ip saddr 192.168.0.0/24 ip daddr 10.138.18.170 tcp dport 80 ct state established,related,new counter packets 0 bytes 0 accept
iif "wls6" ip saddr 192.168.0.0/24 ip daddr 10.138.18.170 tcp dport 80 ct state established,related,new counter packets 0 bytes 0 accept
iif "wls6" ip saddr 192.168.0.0/24 tcp dport 80 ct state established,related,new counter packets 0 bytes 0 dnat to 10.138.18.170
iif "wls6" ip saddr 192.168.0.0/24 tcp dport 80 ct state established,related,new counter packets 0 bytes 0 dnat to 10.138.18.170
ip saddr 10.138.18.170 jump qbs-10-138-18-170
iifname != "vif*" ip saddr { 10.138.18.170, 10.138.20.195 } drop
oifname != "vif*" ip daddr { 10.138.18.170, 10.138.20.195 } drop
chain qbs-10-138-18-170 {
iif "wls6" ip saddr 192.168.0.0/24 ip daddr 10.138.18.170 tcp dport 80 ct state established,related,new counter packets 0 bytes 0 accept
iif "wls6" ip saddr 192.168.0.0/24 ip daddr 10.138.18.170 tcp dport 80 ct state established,related,new counter packets 0 bytes 0 accept
iif "wls6" ip saddr 192.168.0.0/24 tcp dport 80 ct state established,related,new counter packets 0 bytes 0 dnat to 10.138.18.170
iif "wls6" ip saddr 192.168.0.0/24 tcp dport 80 ct state established,related,new counter packets 0 bytes 0 dnat to 10.138.18.170
ip6 saddr fe80::/64 ip6 daddr fe80::/64 udp dport 546 accept
do these counters increase if you try to curl the LAN ip from sys-net or from the LAN?
I tried to curl the http://192.168.0.16 from another qube, that’s how I should curl from the LAN, right? And it hanged again and when I ran these commands again in the sys-net:
nft list ruleset | grep 10.138.18.170
nft list ruleset | grep 80
It printed the exact same thing. So I guess it didn’t increased.
do you have any output in sys-net if you run tcpdump -i wls6 -nn tcp port 80 and you do a curl on http://192.168.0.16/ from another system on the lan? (your phone may work)
I don’t think that curl from another qube will work, doing a port forwarding from the LAN to a qube is different than inter-qubes networking.
After trying lots of things eventually ended up with reinstalling the whole system.
I really appreciate you tried to help with all of these 30 replies, but can I ask you for a favor to just try what I did or what the documentation says and see if it’s working for you? I used disposable sys-net and sys-firewall and non disposable nginx with the defaults on everything.
I just followed the guide and it worked. I redirected port 1337 to a qube connected to sys-firewall, I was running python3 -m http.server 1337 in that qube.
Here is my commands from my shell history:
The LAN network is 192.168.1.0/24 and the ethernet interface is ens6
nft add chain qubes custom-dnat-dev '{ type nat hook prerouting priority filter +1 ; policy accept; }'
nft add rule qubes custom-dnat-dev iif == "ens6" ip saddr 192.168.1.0/24 tcp dport 1337 ct state new,established,related counter dnat 10.138.13.219
nft add rule qubes custom-forward iif == "ens6" ip saddr 192.168.1.0/24 ip daddr 10.138.13.219 tcp dport 1337 ct state new,established,related counter accept
nft add chain qubes custom-dnat-dev '{ type nat hook prerouting priority filter +1; policy accept; }'
nft add rule qubes custom-dnat-dev iif == "eth0" ip saddr 192.168.1.0/24 tcp dport 1337 ct state new,established,related counter dnat 10.137.0.18
nft add rule qubes custom-forward iif == "eth0" ip saddr 192.168.1.0/24 ip daddr 10.137.0.18 tcp dport 1337 ct state new,established,related counter accept
nft add rule qubes custom-input tcp dport 1337 ip daddr 10.137.0.18 ct state new,established,related counter accept
python3 -m http.server 1337
Testing should be done from a remote computer as the filter on the network interface in sys-net will prevent to easily test it locally.
curl http://192.168.1.100:1337
But can you access this server with your public IP?
I did exactly what you did and as before, I had it working on the destination qube and from sys-firewall, but that’s it, I can’t get it to work when I hit my public IP or doing whatever testing from sys-net to check on the connection with the destination qube.
I tested it using the computer LAN IP. If I wanted to expose this to the Internet, I would need to configure a forwarding at my ISP router level to redirect port 1337 to the public IP to port 1337 of my sys-net LAN IP.
But if I could install nginx before switching to Qubes and just use it with my public IP from outside, doesn’t it mean I should be able to use my public IP to access that python3 server we just created(in my case, without router as a blocker)? But I obviously can’t. And I really need that for work and can’t do a thing without it.
If it worked, make sure your qubes os has the same IP address over the LAN as the former nginx server. Double check the NAT from your Internet facing router.
Make sure that the forwarding at the router level matches the forwarding done in Qubes OS and the port used by the web server.
Usually, when there is a network issue, a solution is to draw a diagram and it should help you to figure what’s wrong, if you do such diagram, you could share it here if you want