There are different schools of thought as to whether you should have SSH enabled on your hosts. VMware recommend it is disabled. With SSH disabled there is no possibility of attack, so that’s the “most secure” option. Of course in the real world there’s a balance between “most secure” and “usability” (e.g. the most secure host is powered off and physically isolated from the network, but you can’t run any workloads ).
As some of you read previously, I had been experiencing disk latency issues on our SAN and tried many initial methods to troubleshoot and understand the root cause. Due to other more pressing issues this was placed aside until we started to experience VMs being occasionaly restarted by vSphere HA as the lock had been lost on a given VMDK file. (NOT GOOD!!) The Environment:- 3x vSphere 5.1 Hosts2x 4port Nics 1GBe (allowing 2x iSCSi vmkernel ports per hostfor redundancy)Dedicated Switching (isolated from the LAN) for iSCSi and vMotion (on seperate respective VLANs)_MSA2312i SAN G2 (with 4 Shelves)The iSCSi Multipathing policy was set to Round Robin.
This article originally started off life as a record of how I managed to get this working, as a lot of my posts do, but this time it appears I am foiled. Last week, I had 3 vCenter Servers that appeared to be happily talking to each other in Linked Mode sharing a singe Multi-site SSO domain without any real issues. I had a single-pane-of-glass view of all 3 and I could manage them all from the one client.
Firewalls being used – Sonicwall 3500 & Cisco 506e Several months ago we relocated and it was then necessary to setup a Site to Site VPN tunnel with another network. (In this instance the other network was not directly managed by us) Upon the creation of the tunnel and after successful traffic tests all looked well. However after several hours or less in some cases traffic stopped flowing yet both firewalls reported the tunnel as “up”.
This is my current scenario: there are two existing servers in a stand-alone array - TMG01 and TMG02, and over in a DR site there is a new server (TMG03) that is in the process of being built. To comply with DR, all 3 servers must have their configurations up to date, however there is no direct communication allowed between the two DMZs, so simply adding to the new server as an array member is not possible.
It’s a fairly common requirement – setting up a guest WiFi network that is secure from the rest of your LAN. You need a secure WLAN access for the domain laptops which has full access to the Server and Client VLANs, but you also need a guest WLAN for visitors to the office which only allows internet access. Since the budget is limited, this must all be accomplished via a single Access Point – for this article, the access point is a Cisco WAP4410N.
SSTP or SSL VPN connections are great for people working on client sites or behind very restrictive firewalls – they only require HTTPS (port 443) to be open to be able to connect. Unfortunately, you need to be running Windows 7 or Server 2008 (or newer) in order to make use of them. Threat Management Gateway 2010 is one option for an SSL VPN endpoint. SSTP VPN Requirements Clients must be Windows 7/Server 2008 or newer Certificate – either commercial or an internal Certificate Authority Published CRL – SSTP clients check for the Certificate Revocation List of the CA If you already have an SSL listener (e.
In-depth: Installing and Configuring Threat Management Gateway 2010 in a Network Load Balanced Array
In this post I will be installing a TMG Array as a “back firewall” behind a hardware firewall. The Array will consist of two virtual servers, TMG01 and TMG02 which each have 3 NICs. One NIC will be dedicated to the LAN network, accessible internally. One NIC will be dedicated to the DMZ network, accessible to the outside world on a static mapped IP. The third NIC will be a dedicated intra-array communications NIC as per Microsoft’s recommendation.
vMA is available as a Virtual Appliance (OVF) from VMware. To install it on VMware Workstation 7, open Workstation and select Import or Export to import a new OVF, the URL for the latest OVF for vMA is on the vMA download page As per this article on virtualkenneth.com, you need to edit the VMX file to change the SCSI card and OS type, otherwise you’ll have a kernel panic on boot.
So, you’ve installed a new server with Server 2008 R2 Core – what next? Logging on, you’re presented with a shiny command prompt, you can run notepad or regedit…but aside from that, where do you go from there? In the next few series of posts I’ll hopefully point out the basics, and some not so basics! Using the Server Configuration Tool The server configuration tool (sconfig.cmd) is provided in R2 for some of the basic setup tasks, so you can run that by issuing the “sconfig” command.