Can't get SNAT/MASQ to work.

[k.alle]

I think I'm missing the point of this statement. Everything that follows seems to be about using NAT loopback on the WAN DDNS address to access an internal server. So I fail to see the relevance of tun11 in this scenario.

You don't describe how you have configured tun11 or any related policy routing rules so perhaps they have a bearing. But ignoring that for the moment, to get NAT loopback to work you would need to create a standard port forwarding rule for port 80 under "WAN - Virtual Server / Port Forwarding" which as far as I can see you haven't done.

The DDNS is pointing at tun11 IP, not the WAN/ISP connection.
It is an OpenVPN client which has port forwarding enabled from the VPN service provider.
Hence tun11 -> LAN.
Not WAN -> LAN.
And this works perfectly from the outside.
I can see how this might cause confusion though, most people don't use a VPN client as a "WAN" connection like I do.


Hmm the Port Forwarding in the GUI is strictly related to WAN right?
I have no intention on opening ports on my WAN.

I don't know what related policy routing rules I need or how to show them?

 

[k.alle]

Hang on a minute...

I just realized that if I connect to the server using DDNS on a local machine the packets never arrive at the server (verified with TCPDUMP on server).
They seem to be dropped by the router.
This maybe can explain the connection refused message?

If I think about it, shouldn't the request 'time out' if server response got lost on the way back due to no NAT loopback?

Am I having a DNAT issue?

 

[ColinTaylor]

Hang on a minute...

I just realized that if I connect to the server using DDNS on a local machine the packets never arrive at the server (verified with TCPDUMP on server).
They seem to be dropped by the router.

Have you confirmed that the packets are coming back down the tunnel at all, let alone being forwarded to your server?

What you're trying to do is use NAT loopback on the VPN provider's server, the one that has the public IP address and is doing the forwarding. I doubt it is setup to do that.

 

[k.alle]

Status update.

NAT loopback working through tun11.
Finally found the magic bullet, this rule was missing which caused the router to drop the packages coming from LAN.

iptables -t nat -I PREROUTING -s 192.168.1.0/24 -d EXT_IP -p tcp --dport 80 -j DNAT --to-destination 192.168.1.23

Public cert is accepted by the browser and the service I tried seem happy about it.
Gonna do some more testing but so far so good.

I need to script this so that EXT_IP always is up to date in PREROUTING.

 

[eibgrad]

Let's remember here that the DNAT is what triggers the NAT loopback. The NAT loopback rule only NAT's the traffic headed back inbound to the LAN so it's returned to the router before finally being routed back the client. But in this case, the DNAT rule is NOT based on the public IP of the WAN. It's NOT even based on the assigned IP on the OpenVPN client side of the tunnel. It's based on traffic coming into the interface tun11. That means from the LAN side, redirection will never take place since it can't possibly trigger the rule. ONLY remote traffic actually using tun11 can trigger the rule.

IOW, the DNAT rule has to be constructed in such a way as to actually cause the redirection from the LAN side, which at present it does NOT. It works for the WAN because the basis for the DNAT rule in that case actually is the public IP.

Case and point, consider the following port forward over the WAN, and how the *trigger* is the public IP (192.168.63.102, it's private because it's an internal router in my lab, but you get the point).

Chain PREROUTING (policy ACCEPT 62 packets, 12399 bytes)
pkts bytes target     prot opt in     out     source               destination    
...
   13   780 GAME_VSERVER  all  --  *      *       0.0.0.0/0            192.168.63.102 
   13   780 VSERVER    all  --  *      *       0.0.0.0/0            192.168.63.102 

Chain VSERVER (1 references)
pkts bytes target     prot opt in     out     source               destination    
   12   720 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8443 to:192.168.1.1:8443
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:9999 to:192.168.1.100:8888
...

Again, this is NOT the situation w/ your present DNAT over the VPN.

EDIT: Looks like you discovered the same problem just seconds before I posted. LOL