Policy-Based VPN vs Route Based VPN

When we are planning for VPN solutions, we should have an understanding of 2 VPN solutions (Policy Based and Route Based). 

Policy-based VPNs encrypt a subsection of traffic flowing through an interface as per configured policy in the access list. The policy dictates either some or all of the interesting traffic should traverse via VPN.

A Route-based VPN works on routed tunnel interfaces as the endpoints of the virtual network. All traffic passing through a tunnel interface is placed into the VPN. Rather than relying on an explicit policy to dictate which traffic enters the VPN, static and/or dynamic IP routes are formed to direct the desired traffic through the VPN tunnel interface.

To summarize, let’s see a comparison table with the main differences between Policy-Based and Route-Based VPN solutions.

Policy-based VPN Route-based VPN

Supported on most network devices (Cisco Routers, Cisco ASA, other vendors, etc)

Supported only on Cisco IOS Routers. Very limited interoperability with other vendors

Routing Protocols cannot pass through the VPN tunnel

Routing Protocols can pass through the VPN tunnel

Strong Security natively

 Need additional configuration

Complex Configuration

Simplified Configuration
Supports P2P network topology while Hub and Spoke topology is not supported Supports Hub-spoke , P2P and P2MP network topologies
Traffic flowing through the VPN tunnel can’t be NATTed Traffic flowing through the VPN tunnel can be NATTed since it passes through either the tunnel interface or gateway IP address specified as next-hop in routing.
VPN failover group provides redundant VPN tunnels. SD-WAN policy routing with backup gateway configuration provides redundant routes.
Small networks with limited network expansion. Large networks experiencing rapid growth.

How to generate a full memory DUMP of a VM

Windows DUMP file provides information about the cause of the system crash. But generating a DUMP file on the ESXi system is a bit different. So, will look at the steps. We have divided the process into 2 main steps.

Step 01 – Create and download a VM snapshot

  • In the VMware environment, select the virtual machine that has issues.
  • Replicate the issue on the virtual machine.
  • Right-click the virtual machine and click Snapshots → Take snapshot.

  • Type the name, select the check box next to Snapshot the Virtual Machine’s memory and click OK.

  • Select the virtual machine and click Datastores and click the datastore name.

  • Select the virtual machine, select the .vmsn file (VMware Snapshot file), click Download and save the file locally.

Step 02 – Use the vmss2core tool to create a memory dump from the virtual machine snapshot

  • Download Vmss2core.
  • Select the check box next to I have read and agree to the Technical Preview License I also understand that Flings are experimental and should not be run on production systems. Select the file for your operating system from the drop-down menu (for example, if you want to run the tool on Windows, select vmss2core-sb-8456865.exe) and click Download.
  • Place the vmss2core tool and the VMware snapshot file into the same folder.
  • Run the vmss2core (vmss2core-sb-8456865.exe) in the command line with the following parameters.
  • Specify the guest operating system from which the snapshot was created.

Use quotes if the filename contains blank spaces.

vmss2core-sb-8456865.exe -W8 “virtual_machine_name.vmsn”

  • -W8 —Windows 8 and later or Windows Server 2012 and later.
  • -W —Windows 7 and older or Windows Server 2008 and older.

Finally, you may use the WinDbg tool to analyze the generated Windows DUMP file.