710 likes | 759 Views
Learn how to troubleshoot issues, analyze diagnostic packages, and migrate to MSSQL/Oracle while ensuring Deep Security platform requirements are met. Explore tools for logging, configuration, and virtual appliances.
E N D
Deep Security TOI Session 3 – Ongoing Support Rick Abbot, Bilal Baig, Kevin Boyce
Agenda • Requirements (DB, Disk, CPU, Platform) • Troubleshooting Overview • Diagnostic Package • Agent Install logs • Deep Security logging • dsm_c configurations • Migrating from Embedded to MSSQL/Oracle • Deep Security Virtual Appliance (DSVA) • Tools (log viewer, debug view, bind view, Ratt tool and tbclean) • Admin Docs/KB Articles/ Old Issues/ Release Notes
Agenda • Performance • DSVA Demo
Requirements (DB, Disk, CPU, Platform) 1) Physical Memory (or memory designated for a VM) 2 to 4GBs or more 2) Processor Speed – 2 GHz or more 3) Operating System (any of the list): a. Windows 2000(SP4), b. Windows 2003(SP2), or c. Windows 2008 4) Database: a. SQL – Microsoft SQL Server 2005 SP2 b. Oracle – Oracle 10g 5) Database Size: a. This one is pretty hard to give a one size fits all answer, since there are a lot of variables; 4 Classification 12/3/2009
DSM HW The two factors that we recommend to customer when choosing their hardware for Deep Security Manager are : the amount of physical memory and processor speed. For a deployment of size (~ 250 - 500 hosts) we would recommend 2 to 4 GB of physical memory and a processor speed greater than 2GHz. If you use multi-processor machine, DSM will optimize and use all the available processors . 5 Classification 12/3/2009
Troubleshooting Overview • General Information • Install/Upgrade issues • Communication issues • Network connectivity issues • Other issues 6 Confidential November 2009
Troubleshooting General Information • When a customer reports a problem determine which category it falls under • Install/Upgrade • Communication • Network connectivity • Performance • Other • Determine exactly what the customer was doing when the issue occurred • Issues with the Deep Security product can sometimes be difficult to diagnose. Having as much information as possible is important. 7 Confidential November 2009
Troubleshooting General Information • Request a diagnostics package • This is one of the most important pieces of information you can get. The diagnostic packages contain a lot of information about the state the Agent and/or Manager was in at the time of the problem. • Read the manual • The install guide for Deep Security contains a troubleshooting section. Common problems and solutions are described in this document. • Check for a KM document • Marion Mora and his team have created a number of KM articles covering some of the more common problems. 8 Classification 11/29/09
Troubleshooting Install/Upgrade • Common problems • The agent installer won't run • Loss of connectivity after install/upgrade • Solutions • If the Agent installer won't run • Ensure the customer has the correct version of the agent installer for the required platform • Ensure the SHA-1 hash matches to ensure the downloaded package is correct • If there is a loss of connectivity to the Agent machine after an install or upgrade • The most common solution is to reboot the machine. In most cases the install/upgrade failure is due to the installer being unable to bind (or unbind in the case of upgrade) the driver. This can be caused by other 3rd party drivers. 9 Classification 11/29/09
Troubleshooting Install/Upgrade • Other install/upgrade notes • If there is a problem during install/upgrade and an error occurs, the DSM may report that the agent installation failed and/or a reboot is required. This alert does not clear itself. After a reboot of the agent machine you should clear all errors/warnings and do a check status to ensure the agent is reported as Managed (Online). • During a remote upgrade, if the old driver fails to unbind, you may see errors in DSM relating to Firewall engine offline or DPI Rule engine offline. In these rare cases the reboot may not be enough to solve the problem. If this happens and a reboot does not resolve the issue, you can attempt to re-run the installer on the local machine (in the Deep Security Agent folder). If the installer prompts you to repair or remove, choose repair. • The DSA does report errors back to DSM and these can be found in the DSM system events. 10 Classification 11/29/09
Troubleshooting Communication Issues • This was one of the most common issues encountered during the Beta. The DSA must be able to resolve the hostname of the DSM. • Common Problems • The DSA going offline and coming back online repeatedly • The DSA repeatedly reporting communication problems • Failure when attempting to deploy the Filter Driver or the DSVA (offline bundle.zip) • Solutions • If the DSA is going offline and coming back online repeatedly • This usually indicates a problem with the DSM contacting the DSA. Check the hostname in DSM and ensure that it can be resolved from the DSM machine exactly as it is shown in the DSM. 11 Classification 11/29/09
Troubleshooting Communication Issues • Solutions Continued • If the Agent is repeatedly reporting communication problems • This usually indicates a problem with the DSA contacting the DSM. Launch the Agent GUI and check the Manager URL entry. Ensure the DSA machine can resolve the hostname in the Manager URL exactly as it is shown. • If you get an “offline bundle.zip” error when deploying the Filter Driver or the DSVA • This usually indicates a problem with the ESX server contacting the DSM. Log in to the DSM and go to System->System Information. Under System Details the Manager Node shows the manager name. Log in to the ESX and ensure the ESX server can resolve the name exactly as it is in DSM. 12 Classification 11/29/09
Troubleshooting Connectivity Issues • Common Problems • Lack of connectivity to an Agent machine • “Random” disconnects when accessing a machine protected by the agent • Solutions • If there is a lack of connectivity to an Agent machine • The first thing to ensure is that the Agent installed successfully. If this is an install scenario see the Install/Upgrade troubleshooting section • If this is not an install scenario, perform a get events on the agent from DSM. Check the Firewall events for any events coming from the machine you are attempting to connect from. Check for an out of allowed policy firewall rule. In most cases this is an improperly configured profile issue and a firewall rule is blocking the connection 13 Classification 11/29/09
Troubleshooting Connectivity Issues • Solutions Continued • If there are “random” disconnects when attempting to access the machine (or access other sites from the machine) • Perform a get events on the agent from DSM. Check the Firewall events for any events coming from the machine you are attempting to connect from. Also check the DPI events. Many of the DPI rules require configuration and if they are not configured properly they can cause false positives. If there are DPI events being triggered determine if they need to be configured. 14 Classification 11/29/09
Troubleshooting Other Issues • Common Problems • Log Inspection is returning too many events • Log inspection or Integrity Monitoring databases are growing too large • Solutions • If Log Inspection is returning an unreasonable number of events • The first thing to do is check the rules. Are all the rules that are applied to the Agent necessary for that computer. If not remove any unnecessary rules. • If the rules are correct then view the log entries. Are there any that the customer does not wish to know about. Currently all of the LI rules provided by Trend can be configured. If you view the rule properties and select the configuration tab you can modify the severity levels for the various events related to the rule. 15 Classification 11/29/09
Troubleshooting Other Issues • Solutions • If Log Inspection is returning an unreasonable number of events • Finally there is a severity level setting for logging LI rules on the System->Settings Log Inspection tab. This is a global setting and will affect all rules. But it can be used to limit the amount of logs returned. There is also a host level override for this setting. • If the Log inspection or Integrity Monitoring databases are growing too large • The Log Inspection and Integrity Monitoring databases hold the events when the LI and IM rules are triggered. These events are returned to DSM and the database purged when the Agent does a heartbeat. If there are a large number of events and the heartbeat interval is high (24 hours for example) the database may grow. To reduce this you can follow the steps above to limit the events and you can modify the heartbeat interval for the affected host to heartbeat more often, thus returning events more often. 16 Classification 11/29/09
Diagnostic Package Common Files Agent package Under Manager folder dpievents.csv firewallevents.csv host.xml hostevents.csv integrityevents.csv loginspectionevents.csv manager_config.xml systeminformation.xml configuration.pdf 17 Classification 12/3/2009
Diagnostic Package Important files which support will be interested. dpievents.csv, firewallevents.csv, integrityevents.csv loginspectionevents.csv: Contains logs for the last one hour host.xml: Host export file hostevents.csv : Host related events for the last one hour systeminformation.xml: contains job, system ,threads, DB information configuration.pdf: Computer forensic Audit report 18 Classification 12/3/2009
Diagnostic Package Windows Agent folder Config.bin, config.p7, ds_agent.config, ds_agent.ini, ds_mpf, dsa_mpld, RunningProcesses.xml Msinfo, setupapi.log dsa_conn_states.txt dsa_stats.txt dsa_variables.txt dsa_tcp_conn.txt dsa_blacklist.txt 19 Classification 12/3/2009
Diagnostic Package Important files which support will be interested. Msinfo: Microsoft conputer system information setupapi.log: Microsoft setup api log contins driver installs. dsa_stats.txt: Ratt tool output which contain driver statistics dsa_variables.txt: Ratt tool output which contain driver advanced settings 20 Classification 12/3/2009
Diagnostic Package Linux/Solaris Agent Folder dsa-state-capture-output.txt proc-cpuinfo proc-dsa-configs proc-dsa-stats proc-dsa-interfaces proc-dsa-info proc-dsa-ignore_device proc-dsa-trace_ctl proc-meminfo proc-pagetypeinfo proc-slabinfo proc-zoneinfo 21 Classification 12/3/2009
Diagnostic Package DSM > System Information > Create Disgnostics Package Debug.xml Error.log Install.log/uninstall.log Installation.log serverX.log Service.log Files.log Output.log Filelist.txt Configuration.properties Dsm.properties Logging.properties 22 Classification 12/3/2009
Agent/Manager Installation logs Windows Agent Setupappi.log Install.log (not ON by Default) Msiexec /log install.log –I <install-package> Windows event log file Linux/Unix Agent Messages file. Make sure the package is correct w.r.t Solaris. Since we need different packages for different versions of solaris. DSM Installation.log in install directory. Windows event logs 23 Classification 12/3/2009
DSM Logging logging.properties file now uses multiple file logging with limits: java.util.logging.FileHandler.pattern = C:/Program Files/Third Brigade/Deep Security Manager/server%g.log java.util.logging.FileHandler.limit = 10000000 java.util.logging.FileHandler.count = 5 java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter java.util.logging.FileHandler.append = true 10 MB and 5 files. Default Behavior, configuration kept on upgrade All Third Brigade Logging: com.thirdbrigade.level = ALL All Database Logging: com.thirdbrigade.persistence1.level = ALL All startup information: com.thirdbrigade.manager.webclient.initialization.level = ALL com.thirdbrigade.manager.core.Core = ALL Host Updater Job (including agent security configuration XML) debugging: com.thirdbrigade.manager.core.scheduler.jobschedulers.jobs.HostUpdaterJob.level=ALL 24 Classification 12/3/2009
DSM Logging Agent Communication Protocol logging: com.thirdbrigade.manager.core.protocol.level = ALL Detection Engine (ie Recommendation) logging: com.thirdbrigade.manager.core.detectionengine.level=ALL Jobs logging: com.thirdbrigade.manager.core.scheduler.jobschedulers.HostJobScheduler.level=ALL com.thirdbrigade.manager.core.scheduler.JobQueuingThread.level=ALL com.thirdbrigade.manager.core.scheduler.JobCreationThread.level=ALL com.thirdbrigade.manager.core.scheduler.ManagerJobs.level=ALL 25 Classification 12/3/2009
DSM Logging error.log and output.log error.log and output.log are cleared on restarts. error.log may contain information related to startup and shutdown since the java logging isn't fully initialized. Install.log The installer's custom actions (done after installation) contains over 1000 lines of code and is not able to use java logging so it writes a log to install.log. This information is for diagnostic purposes. It is appended to on each install. Uninstall.log Like the install.log the uninstall.log records diagnostic information for troubleshooting uninstalls. It is appended to on each uninstall. Service.log The service log contains information on the service code before java.logging is initialized. It is appended to on each start and stop of the service. This information is for diagnostic purposes. 26 Classification 12/3/2009
Dsm_c command line tool The command line tool is used to perform actions not exposed on the Deep Security Manager. Un-lockout an administrator accountThis command is used to restore active state to an administrator that has been locked out. Normally this is done via the GUI but this command helps when all of the administrator accounts have been locked out. dsm_c -action unlockout -username USERNAME [-newpassword NEWPASSWORD] Give an administrator the full access rolehis command is used to change an administrator to have the full access role when no administrators are left with the ability to change roles dsm_c -action fullaccess -username USERNAME Change a settingSome settings are not exposed to the user on the settings page. These can be changed this way. dsm_c -action changesetting -name NAME -value VALUE 27 Classification 12/3/2009
Dsm_c command line tool Reset eventsThis action is available if the event tables becomes corrupt or too full. The tables are dropped and re-created n 7.0 + the command is resetevents and has options. The -type option can be followed by one or more of: all - All Event Types fw - Firewall dpi - Deep Packet Inspection im - Integrity Monitoring li - Log Inspection For multiple comma separate the values. dsm_c -action resetevents -type [all|fw|dpi|im|li] Reset counter dataThis action is available if the counter table becomes corrupt or too full. The logs table is dropped and re-created dsm_c -action resetcounters . 28 Classification 12/3/2009
Dsm_c command line tool Create Insert StatementsUsed to migrate from Embedded to SQL or Oracle dsm_c -action createinsertstatements [-file FILEPATH] [-generateDDL] [-databaseType sqlserver|oracle] [-maxresultfromdb count] Set Manager Port(s)Used to change ports post-install. dsm_c -action setports [-managerPort port] [-heartbeatPort port] Reindex Help SystemUsed to rebuild the index for help (and the keyword index for the search). dsm_c -action reindexhelp Trust directory CertificateThe command is used to trust the directory certificate for dsm integration dsm_c -action trustdirectorycert -directoryaddress DIRECTORYADDRESS -directoryport DIRECTORYPORT [-username USERNAME] [-password PASSWORD] 29 Classification 12/3/2009
Dsm_c command line tool Create diagnostics file Creates a diagnostic.zip for the system. dsm_c -action diagnostic This creates a full diagnostic.zip (Manager Diagnostic Package) which contains debug.xml. dsm_c -action debug 30 Classification 12/3/2009
Database Migration Steps to migrate from the embedded database to SQL database. 1. Open a command prompt (cmd.exe) 2. Navigate to the DSM directory. The default is C:\Program Files\Third Brigade\Deep Security Manager. 3. Type the command dsm_c -action createinsertstatements -databasetype sqlserver –generateddl -goparameter GO This will generate a SQL file called dsmData.sql in the DSM install directory. we can also run the following command: this excludes the Db tables for export. dsm_c -action createinsertstatements -databasetype sqlserver -generateddl -goparameter GO -excludetables packetlog,agentinstallers,integrityevents,loginspectionevents,payloadlogs 31 Classification 12/3/2009
Database Migration To insert this file into the database 1. Open a command prompt. 2. Type the command OSQL -U <username> -P <password> -d <databasename> -i <full path to dsmData.sql> Point DSM to the new database Open up the following file in notepad: [Install Directory]\webclient\webapps\ROOT\WEB-INF\dsm.properties It will look something like: database.name=dsmdatabase.directory=C\:\\Program Files\\Third Brigade\\Deep SecurityManager\\database.type=Embeddedmode.demo=false 32 Classification 12/3/2009
Database Migration See below for example dsm.properties file #Tue Dec 11 14:27:15 EST 2007database.SqlServer.user=sadatabase.name=dsmdatabase.directory=null\\database.SqlServer.password=$1$233305eea49844890d058d5109042f2bb9c2122c5d0e46cee1e310831810e01680cfea73aaf2663d3b255d96c25ab36b67b4e683d11727b68efcb851d8ddba9136cd41c0908e9413443bc3e64749ebd9mode.demo=falsedatabase.SqlServer.namedPipe=true (my named pipe is true because it was on the same box)database.type=SqlServerdatabase.SqlServer.server=bbaig-desktopmanager.node=1 33 Classification 12/3/2009
Database Migration Replace the contents of the file with the following: database.type=SqlServerdatabase.name=<database_name>database.SqlServer.server=<hostname>database.SqlServer.user=<username>database.SqlServer.password=<password>database.SqlServer.namedPipe=falsedatabase.SqlServer.appName=Third Brigade Inc.database.SqlServer.progName=Deep Security Managermode.demo=false 34 Classification 12/3/2009
Database Migration Restart the Deep Security Manager service Open the dsm.properties file to confirm the password is encrypted. If the password is still in clear text then open server0.log under dsm directory to see what are the exceptions. If the password is encrypted then it means the connection to sql server was successful. Login DSM is now using the new database. 35 Classification 12/3/2009
Deep Security Virtual ApplianceArchitectureTwo Components: Appliance and Filter Driver vNIC vNIC vNIC vNIC VMsafe API Vmservice vSwitch Filter Driver (Hypervisor) VM Network vSwitch Management Vswitch
Deep Security Virtual ApplianceAppliance-Vmsafe Connectivity • Vmsafe uses TCP networking to communicate from hypervisor to Appliance • Appliance has two Network Interfaces: • one (eth0) is on Management network for DSM • The other (eth1) is on internal/private vSwitch • The vmkernel has a vmkernelvnic on the same private vSwitch. • DSM ESX Prepare wizard sets all this up
Deep Security Virtual ApplianceAppliance-Vmsafe Connectivity Appliance VNIC Private vswitch (no adapters) Vmkernel NIC (to VMSafe)
Appliance Networking Appliance Version and UUID (must be present) MAC of Vmsafe NIC VMSafe NIC Must be on private vSwitch
Appliance Networking (Console) VMSafe NIC To access appliance command line, use ALT-F2 then login as user dsva, default p/w dsva To enable remote ssh access, type $ ssh-server start Enable SSH port in Firewall settings in DSM
Checking Appliance Connectivity • Check connectivity to VMKernel • dsva@dsva:~$ sudo ping 192.168.2.61 • PING 192.168.2.61 (192.168.2.61): 56 data bytes • 84 bytes from 192.168.2.61: icmp_seq=0 ttl=64 time=1.4 ms • 84 bytes from 192.168.2.61: icmp_seq=1 ttl=64 time=0.1 ms • Check interface: • dsva@dsva:~$ ethtool -i eth0 • driver: e1000 • version: 7.3.20-k2-NAPI • firmware-version: N/A • bus-info: 0000:02:00.0 dsva@dsva:~$ ethtool -i eth1 • driver: vmxnet3 • version: 1.0.0.32-NAPI • firmware-version: N/A • bus-info: 0000:03:00.0 • dsva@dsva:~$ echo `cat /proc/driver/dsa/ignore_device ` • eth1 • dsva@dsva:~$ DSVA knows which NIC is connected to the Vmsafevswitch because the driver is set to vmxnet3. It does not firewall this NIC.
Checking Appliance Connectivity • Appliance Connections to VMSafe will show up in netstat as TCP connections to port 2222. • dsva@dsva:~$ netstat -n -t • Active Internet connections (w/o servers) • Proto Recv-Q Send-Q Local Address Foreign Address State • tcp 0 0 127.0.0.1:47544 127.0.0.1:53264 TIME_WAIT • tcp 0 0 192.168.2.99:41289 192.168.2.61:2222 ESTABLISHED • tcp 0 0 127.0.0.1:47545 127.0.0.1:53264 TIME_WAIT • tcp 0 52 ::ffff:10.10.1.119:22 ::ffff:10.0.0.200:4020 ESTABLISHED • dsva@dsva:~$
Checking ESX Side • SSH or go to ESX console • [root@esx-cert-prim ~]# esxcfg-vmknic -l • Interface Port Group/DVPort IP Family IP Address Netmask Broadcast MAC Address MTU TSO MSS Enabled Type • vmk0 vmservice-vmknic-pg IPv4 192.168.2.61 255.255.255.0 192.168.2.255 00:50:56:72:1c:d4 1500 65535 true STATIC • vmk1 iomega-san IPv4 192.168.100.61 255.255.255.0 192.168.100.255 00:50:56:7b:b6:12 1500 65535 true STATIC • vmk2 vct-pg-vmotion IPv4 192.168.1.3 255.255.255.0 192.168.1.255 00:50:56:76:3d:6c 1500 65535 true STATIC • Check Vmkernel address matches, this is where Vmsafe (dvfilter) gets its configuration from: • [root@esx-cert-prim ~]# esxcfg-advcfg -g /Net/DVFilterBindIpAddress • Value of DVFilterBindIpAddress is 192.168.2.61 • Check Hypervisor FilterDriver Modules are loaded correctly: • [root@esx-cert-prim ~]# vmkload_mod -l | grepdvfi • dvfilter 0x418022dbd000 0xb000 0x417fe3ad04c0 0x1000 45 Yes • dvfilter-dsa 0x418022dc8000 0xa000 0x417fe3ad4020 0x1000 46 Yes Trend FilterDriver Hypervisor kernel module.
Check VM Protection Configuration • dsva@dsva:~$ ps -ef | grep ds_ • dsva@dsva:~$ ps -ef | grepds_ • root 4406 1 0 Nov12 tty1 00:45:32 /usr/bin/perl -w /opt/ds_agent/dsplash.pl • dsva 17279 1 0 23:25 ? 00:00:00 sudsva -c /opt/ds_guest_agent/ds_filter.sh "564de6ef-2cea-8aaa-4367-168d0f3a3fba" • dsva 17280 17279 0 23:25 ? 00:00:00 /opt/ds_guest_agent/ds_filter --id 564de6ef-2cea-8aaa-4367-168d0f3a3fba • dsva 17284 1 0 23:25 ? 00:00:00 sudsva -c /opt/ds_guest_agent/ds_agent.sh "564de6ef-2cea-8aaa-4367-168d0f3a3fba" • dsva 17286 17284 0 23:25 ? 00:00:00 /opt/ds_guest_agent/ds_guest_agent -w /var/opt/ds_agent/guests/564de6ef-2cea-8aaa-4367-168d0f3a3fba • dsva 18477 1 0 23:38 ? 00:00:00 sudsva -c /opt/ds_guest_agent/ds_filter.sh "421a994d-6d29-a028-1291-bd599e4b4272" • dsva 18478 18477 0 23:38 ? 00:00:00 /opt/ds_guest_agent/ds_filter --id 421a994d-6d29-a028-1291-bd599e4b4272 • dsva 18482 1 0 23:38 ? 00:00:00 sudsva -c /opt/ds_guest_agent/ds_agent.sh "421a994d-6d29-a028-1291-bd599e4b4272" • dsva 18484 18482 1 23:38 ? 00:00:00 /opt/ds_guest_agent/ds_guest_agent -w /var/opt/ds_agent/guests/421a994d-6d29-a028-1291-bd599e4b4272 Pair of Processes For Each Protected VM (ds_filter, ds_agent) Each runs in it’s own /var/opt/ds_agent/guest/<uuid> directory.
Check Appliance Protection of VM Interfaces • Use Ratt to check the VM’s interfaces are recognised. DSM will show interface-out-of-sync for any interfaces that are not being reported: dsva@dsva:~$ cd /var/opt/ds_agent/guests/564de6ef-2cea-8aaa-4367-168d0f3a3fba dsva@dsva:564de6ef-2cea-8aaa-4367-168d0f3a3fba$ /opt/ds_guest_agent/ratt if ratt 7.0.0.916 drv 7.0.0.916 id macmtu 0 1 00:50:56:9a:60:26 1500 1 2 00:50:56:9a:13:99 1500 MACs should correspond to those shown in vSphere client for the VM (or from ipconfig on the VM). Only Physical NICs are seen by appliance.
Check The VM UUID • [root@esx-cert-prim ~]# vmware-cmd –l • /vmfs/volumes/4add9755-7a0640b7-4d11-0022192aeba0/w2k3/w2k3.vmx • /vmfs/volumes/4add9755-7a0640b7-4d11-0022192aeba0/kbxu64_89/kbxu64_89.vmx • /vmfs/volumes/4a7c9f5c-51fcee8e-45d1-001517761286/mars_rover/mars_rover.vmx • /vmfs/volumes/49e73d8a-515b283c-1e3d-0022192aeba0/kbxatu/kbxatu.vmx • /vmfs/volumes/4add9755-7a0640b7-4d11-0022192aeba0/kbw2k8_ws/kbw2k8_ws.vmx • [root@esx-cert-prim ~]# vmware-cmd/vmfs/volumes/4add9755-7a0640b7-4d11022192aeba0/kbxu64_89/kbxu64_89.vmx getconfiguuid.bios • getconfig(uuid.bios) = 564de6ef-2cea-8aaa-4367-168d0f3a3fba
About Vmotion • When a VM is vmotioned from one ESX to another, the firewall configuration is migrated automatically with it in real time. A new virtual agent is created automatically on the new ESX. • The old virtual agent remains for a short period of time on the original ESX host. DSM is notified of the vmotion event and obtains the last event logs from the old virtual agent before destroying it. • With vmsafe it is currently not possible to Vmotion the connection state and the DPI configuration. Instead DSM updates the new virtual agent with the full configuration soon after receiving the event. • DSM must be available all the time for VMs to be fully protected • Open connections are not impacted during Vmotion. Instead the virtual agent enters cold start mode and rebuilds connections on the fly for any connections that have traffic in the first 5 minutes (defautl cold start period).
Vmotion Special Cases • VM is moved to unprotected ESX • We do not prevent this, the VM will lose protection if it does not have an in guest agent. • VM is moved from unprotected ESX • Will not automatically be protected • VM is moved between protected ESX where appliance has been shut down or is disabled for some reason. • The firewall state will not be moved but the VM will be protected soon afterwards • VM is moved between ESX nodes that have different agent versions. • This is allowed, it’s recommended that it be minimised and the vmotion direction be towards the higher version.
Vmotion and DRS • When multiple ESX nodes are configured in a DRS cluster, Vmotion can occur automatically or semi-automated e.g., when patching. • If the host in a DRS cluster is placed into maintenance mode for patching, all the VMs on it will be Vmotioned automatically to other hosts in the DRS cluster. • The Appliance is not vmotioned in this process, it always stays on the same ESX. The admin has to manually power down the appliance before the transition to maintenance mode operation completes (it will wait indefinitely) • If the ESX host is just moved back out of maintenance mode without a reboot the appliance must be restarted manually. • When the ESX host is rebooted the Appliance will restart automatically and be ready to protect VMs again • Appliance startup is configured on deploy but the automatic VM startup feature must be enabled on the ESX.