Join the Conversation

To sign in, use your existing MySonicWall account. To create a free MySonicWall account click "Register".

Local 500v ESXi deployment, where is the best practices documentation?

I have seen a few sources that dictate just installing the 500v VM on the ESXi host using just the X0 interface. and no others. Just forward ports 80 and 443 to the X0 interface IP, and you are done. Simple, but is that really the safest implementation? I don't like the idea of putting my production network IP out there as the remote access address.

Assuming I want to use different public IP as the WAN interface, is there any documentation on the best practices on how to set up the ESXi host?

Category: Secure Mobile Access Appliances
Reply

Answers

  • BWCBWC Cybersecurity Overlord ✭✭✭

    Hi @tracer

    you mileage may vary, but I usually deploy the SMA in a DMZ-like zone, having it in the LAN zone is a bad idea. In that scenario you can assign IPs to your NetExtender/MobileConnect clients which can be controlled on the Firewall as well. But this general advice, whenever possible do not grant access from WAN to your LAN directly, if possible.

    VirtualOffice is used for Management only and any other Portal gets assigned to a specific new Portal. In the beginnings I had Management and user accessible Portal all-in-one, which was not a good idea. This requires of course multiple certificates or MDC or Wildcards.

    What do you mean by different IP for WAN, do you have multiple WAN addresses assigned from your ISP? Then you probably just need to do the NAT for it.

    --Michael@BWC

  • tracertracer Newbie ✭

    Michael,

    Yes, we have an IP stack of several public IP's available to us.

    I certainly agree that having the WAN traffic in the LAN zone does not sound like the right way to do things. Searching for information online I found a couple of people adopting the "keep it simple" approach and just using the X0 interface as I described above.

    I ask the question because we have owned the software for years, but have never found it to be robust. As we pushed users home over the past year, I had to stop using the SMA and we opted for a different remote access solution. As things are settling down, I am revisiting my options with SMA.

    My config was using the X0 interface on the LAN, which is of course behind a firewall on public IP x.x.x.1. I stood up a second firewall on public IP x.x.x.2, and connected that to X1. While troubleshooting issues with Sonicwall support, I went round and round. They were able to make things work for a while, just to have something else pop up. Management refused to renew support!

    I am weighing my options as to whether or not to go down this road again. Trying to look at this with a clean slate, so I am looking for best practices documentation for installing the 500V in the ESXi environment. If Sonicwall ever produced any, they did a good job hiding it!

  • BWCBWC Cybersecurity Overlord ✭✭✭

    Hi @tracer

    I can't see any fundamental difference between deploying behind X0 or let's say X2 (DMZ alike zone) from a technical perspective, securitywise is another story which you already know.

    I don't get your scenario, you're having multiple Firewalls (SNWL?) or is the 2nd just for testing? Either way, deploy your SMA single-armed (just X0) and connect it to the Firewall (individual Interface or VLAN). NAT the public IP you like to the SMA for HTTPS, allow ANY ZONE -> DMZ (SMA) from ANY to X2 IP (or the respective interface IP) for HTTPS and you're good to go.

    To allow your SMA access to the internal resources you have to create the Rules from DMZ (SMA) to LAN for example, allowring RDP etc.

    On the Firewall side it's pretty straight forward.

    --Michael@BWC

  • tracertracer Newbie ✭

    Michael,

    I appreciate your assistance, you guidance is helpful.

    Still wondering if Sonicwall ever issued a "best practices" paper specifically for the virtual deployments, other than Typical Deployment of SMA/SRA appliance | SonicWall .

Sign In or Register to comment.