When you need to install View agent on a physical box or an unmanged desktop source. When you don’t control the VM infrastructure or maybe the VDI is in the cloud. When you don’t have vCenter or license for vCenter managing the ESXi, one would argue that if you have license for VDI you have license for all the component to run VDI. For my special use case, my View Connection Server is not going to be able to talk to the backend vSphere management Infrastructure for it is in a complete separate network. In other words the virtual machine network and the vSphere network is physically separated and they don’t talk to each other. There is one nic from each ESXi to the virtual machine network to expose the Win7 VMware View vm’s. There would be zero attack footprint from the virtual machine network to the vSphere network infrastructure. The only way to attack the vSphere infrastructure is through some kind of VMware tools to hypervisor vulnerability exposed on the VM itself that can attack the underlying hypervisor. I don’t know of such vulnerability but it doesn’t mean there’s none and does not guarantee the future. The possibility of such attack exist. I don’t know what kind of sandboxing techinique VMware has for their vmtools for protection. The other attack is, pretty obvious, if you are in the vSphere network itself, duh!! Enough blablabla, this will take you to the GUI install and prompt you to supply the View Connection Server IP or FQDN.
For the past couple of weeks a newly created site-to-site VPN has been showing inconsistency. Some of the machines you can not ping through the VPN when more than half you can. I can ping from one direction yet the ping from remote end coming back is bad. There was one that I ran a continous ping and it did not succeeded until 2 minutes had passed. Another weird part is typically you can issue “clear crypto isakmp sa” to reset all VPN connection but with this particular one, the only course of action was to reboot one or both the ASA endpoint. Which you can imagine it is not a pretty fix and would be frown upon. The only thing special on this config is I am specifically using IKEv2 on both ends. I mean why not, they are both 5520 using the same latest firmware so there should be no conflict or compatibility issue.
After wresting with the debug for days, and looking at the cyphertext side from Wireshark, I finally narrow it down to one error “Need to send a DPD message to peer” in which there is zero to no information on the web. After reading a couple of sources I realize that IKEv2 has a built-in feature to detect neighbor state. DPD and keepalive are just product birthed by the shortcomings of the original IKEv1. I change my VPN config:
“tunnel-group 18.104.22.168 ipsec-attributes
isakmp keepalive threshold infinite”
“clear crypto isakmp sa” to reset the VPN
“sh crypto isakmp sa detail | in DPD” to check the changes
Some might ask if I tried “isakmp keepalive disable”. Yes, I tried the disable but the output of “sh crypto isakmp sa detail | in DPD” still shows it is on to its default threshold 10 and retry 2 even after reboot. And even with the disable keepalive I am still getting inconsistent VPN behavior.
In summary, “isakmp keepalive threshold infinite” fixed it for me. Cheers.