Multiple Source IPs in NAT rules

Hi @Zyxel_Melen,

No, I didn't try this, as it is not a publicly available website so doing this could be potentially quite dangerous. For clarity, our local web server is set up purely to communicate with an API from one of our suppliers, for use within the LAN, but should not be publicly available over the internet.

The external source is HTTPS because this is what we have been requested to allow through to our web server by the supplier - their Web API communicates on default HTTPS (TCP 443). I could potentially request that a unique external port is utilized for the API connection, but ideally the firewall would handle this for us.

The VPN thing appears to be a red-herring, apologies for that, the issue is wider and actually affects local network users as well, all recieving the same SSL certificate error.

The issue appears to be as follows… When a NAT rule is created from WAN to LAN to redirect HTTPS traffic from source 'any' to a local web server (in this case, for an API connection, but could just as easily be the case for if the customer had a locally hosted website), the inbound SSL certificates for web browsing also fall under this rule and are redirected to the web server instead of the local device that requested the web certificate, resulting in the invalid SSL certificate error on the client machine.

In our case, the multiple IPs in NAT rules would resolve this problem, as our web server only needs to be available from certain source IP addresses for the API connection to work. But it does raise the question, what would happen if the customer did have a local web server that needed to be available over the internet for 'any' source?…