NAT Forwarding mini-challenge

Hi all,

Quick question, there might be a very easy way around this but I haven’t found it yet :slight_smile:

I run OpenVPN server on a server on an internal subnet on port 443:TCP (so I can access it from fire walled locations). How can I create a dst-nat mapping that forwards incoming VPN connections on the WAN interface to the internal server. If I create a dst-nat mapping that matches port 443 and protocol TCP it works fine. However, internal machines are no longer able to open HTTPS pages on the internet because all the returning packets are getting directly NAT’ted to the internal server because of the NAT rule I created.

I thought about using the connection-state to keep the 2 types apart, NEW connections which do not have a NAT entry yet would be VPN traffic and EXISTING connections could just be processed by NAT table as normal as both the VPN traffic and HTTPS traffic would have acquired proper NAT table entries. Unfortunately I connection-state is not available when using dst-nat.

Anyone any idea’s? Perhaps some connection-marks or something and then NAT’ting based on those? Wonder if anyone actually manages to decipher my explanation lol :laughing:

specify in-interface=wan on that nat rule.

That won’t help I guess (think I have already done that). Both returning HTTPS traffic from the internet that belongs to a client’s browser session and incoming VPN connections on port 443:TCP on the WAN interface will match that rule. Hence, all traffic destined for users trying to logon to a secure webpage will be forwarded to my VPN server.

Will try you suggestion now to be sure.. Thanks.

O wow, that seemed to have worked, thought I would have put WAN on there by default.. Seems I hadn’t. So now all NEW connections on 443/TCP will be NAT’ted to my VPN server and all existing HTTPS sessions that belong to clients will be properly NAT’ted back into the LAN according to the NAT tables? (Seems so as it looks like everything is still working)

THANKS!

Right ok.. Yes I think I get it now. Because I didn’t specify the interface, it was not actually the returning packets being NAT’s but the initial connection from CLIENT → HTTPS WEB PAGE.

I have added the interface WAN (stupid I forgot) and it seems to be working now.

Thanks again.! :sunglasses: