• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 8556
  • Last Modified:

Sonicwall : How to forward port 443 to two different servers?

Hello All,

Currently I have two servers running that utilizes port 443 (Mac Profile Manager/WebHelp Desk).

I have the following configuration :
IP from ISP is Static

DNS Server/file server (win2k8 R2) :
webhelpdesk.abc.com ( on win2k8 r2)
profilemgr.abc.com ( on a mac)


Internally, I can access both webservers by navigating to their respective URL.

My question is, how do I configure my SonicWall so that I can access these two services via the INTERNET.

Basically, I want to be able to navigate to the URL outside of my internal network and still be able to access these services..

Thank you much in advance!
  • 5
  • 4
3 Solutions
Giovanni HewardCommented:
While you have a couple options, it's helpful to first understand that you generally cannot forward to multiple internal hosts using the same public ip address and same port number.  If you have more than one public IP address available, then you simply configure a port address translation (PAT) or network address translation entry (NAT), and appropriate access control rules, for each web server.  If you only have one public IP address, then you'll need to select an alternate port for one of the web servers on the public side (ie 444/TCP) which is then translated to private side on 443/TCP.  Another possibility is hosting both web servers on the same machine, and distinguishing between the two web sites via the host header.  In this way they can share the same IP address and port, however in the case of SSL/TLS you'll need a certificate issued which supports both FQDN's.  It's also possible an application layer SSL IPS/firewall/reverse-proxy could read the host header and forward accordingly.

All that being said, you'll need to identify and gain access to the public name servers for your domain (i.e. abc.com); from here you'll basically duplicate your internal DNS records, except you'll modify the IP addresses from private IP's to their corresponding public IP's.  The public IP's correlate to your PAT/NAT entries, which translate a given public IP to a given private IP.  Make sense?
Coupee46Author Commented:
Ahh ok that makes sense.  Well my ISP has given me a block of public IP address (5 addresses). Would this work? I assume I can reconfigure my DNS A record to point to another public IP that I am not currently using?
Giovanni HewardCommented:
Yes, select two public IP's from your block which aren't in use.  I'd recommend you create PAT entries instead of NAT entries.  This leaves open the possibility of assigning other ports in the future to other internal hosts, whereas a 1-to-1 NAT entry dedicates the entire IP address to a single host.

After you've created the PAT entries, modify your public DNS records to match the FQDN's:

webhelpdesk.abc.com (public IP 1)
profilemgr.abc.com (public IP 2)

Aside from convenience, another benefit of matching FQDN's is you won't need to reissue your web server certificates.
WEBINAR: GDPR Implemented - Tips & Lessons Learned

Join the WatchGuard team on Thursday, March 29th as we recount some valuable lessons learned in weighing the needs of a business against the new regulatory environment, look ahead at the two months left before implementation, and help you understand the steps you can take today!

Coupee46Author Commented:
Great! Thanks, I'll give that a try today. The profilemgr.abc.com I don't mind assigning the entire IP to it since the only thing it will be responsible for is my iOS and osx devices....

You wouldn't by chance know of any sonic wall tutorial on setting up te pat or nat?

Thank you again!
Just a heads up that the Sonicwall likely (by default on the TZ series) uses port 443 for its management https interface
This may cause a conflict with what you are intending
Giovanni HewardCommented:
Here's a video tutorial:

It would be best practice to only make your management http daemon available on the private side, not the public.  If this can't be avoided then restrict access on the public side, to the management interface, by IP address.

Additionally, best practice would be to create a separate private network for use as your DMZ, and to have all publicly accessible hosts reside there.  If one of these hosts are compromised, then only the DMZ network will be accessible to attackers as opposed to your entire primary private network.  You'd then create PAT/NAT entries from the DMZ to the primary private side as well, in order to make the DMZ hosts accessible to your private network.  This is another reason to consider PAT over NAT--- to limit the attack (and fingerprinting) surface attackers have access to.
Coupee46Author Commented:
Thank you x66,

I created a NAT policy for the MDM first to test if it works..

Original Destination : <one of my mpublic ip>
Translated Destination : (DMZ)
Original Service : <set to ANY>

I added modified the following DNS recrods :

name : profilemgr
Type : Host (A)
Data : public ip


1. atempting to open profilemgr.abc.com resulted in PAGE CANNOT BE FOUND
2. I went ahead and ping profilemgr.abc.com from a separate workstation on the same network, and was able to receive a REPLY with the internal IP
3. I performed a tracert to profilemgr.abc.com and verified it did ended at the MacMini server
4. I performed a port scan on the private IP and verified 80/443 is live on the profilemgr.abc.com
5. I verified I could access the profile interface on https via the private IP
6. I attempted a port scan on the public IP, but did not yield any result to any open ports

So basically, I am still unable to access the profilemgr.abc.com on the public IP, only on the private IP.  When I perform the ping and tracert on the public IP my results comes back with a reply from the PRIVATE IP

But when I attempt to ping or tracert te public IP outside of my network, I am given "RESULT TIMED OUT"


Thanks again.
Giovanni HewardCommented:
Yes, in addition to NAT you'll need to create an access control rule to permit the port and protocol you're testing (e.g. 80/TCP (http), 443/TCP (https)).  You'll also need to make sure the public DNS server is resolving the FQDN properly, meaning it's resolving to the public IP address (that is NAT'd to the corresponding private IP) and *not* the Private IP.  Are you using the same DNS server for private as you are for public?  If so, you'll need to use a separate DNS server on the public side.  CloudNS.net is a provider I use.

So both your ACL and your NAT rule should apply to the same public IP.  To temporarily eliminate DNS from the equation, test on the public-side of the firewall using the public IP address only.

Additionally, rather than PING (which uses the ICMP protocol), you'll want to test with a utility such as Nping (part of the Nmap package) using the actual port and protocol of the service you really want to verify.

nping --tcp -p 80

Open in new window

If you do want to test with PING, create an ACL to permit ICMP (specifically, Type 8 — Echo and Type 0 — Echo Reply) on the public IP address you used for your NAT address.
Coupee46Author Commented:

you're a blessing.. thank you sir/maddam.. Everything works great now :).  I also created an additional NAT policy as a loopback for internal workstations.
Coupee46Author Commented:
Amazing explanation!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 5
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now