Typically this situation should never happen, you can always forward ports through at the other side. Right? As all you IT guys know, 3rd party software and complex networks will ask for some weird deployment tasks. This demonstration assumes you already have an existing Interface based IPSEC tunnel running between 2 fortinet appliances and they are talking like best friends. I've tested this on 4.0 MR3 P5, I would suggest you use the same or current.
--- WAN1: 220.127.116.11
--- Int1: 10.20.1.1
--- Port 36008 should be forwarded to 10.10.1.17 in Site B
--- WAN1: 18.104.22.168
--- Int1: 10.10.1.1
--- Server on 10.10.1.17 with port 36008 open and ready
IPSEC Interface Name: IPSEC-YKN1-SPG1
The idea ... when anyone on the internet connects to 22.214.171.124 on port 36008, they will be redirected up through the IPSEC tunnel and to the remote server. Let's get started!
1) FortinetA - Create a port-forwarding rule just like any other
2) Fortinet A - Create a firewall policy to allow the internet traffic in on WAN1 and out the IPSEC Interface to your port forwarding rule (remote server)
Do not forget to enable NAT!!!
3) Fortinet B - Create a reverse route to manage the WAN1 interace on Fortinet A
Without this, the fortinet will drop the incoming packets when it does a reverse path check.
"id=36871 trace_id=188 func=ip_route_input_slow line=1268 msg="reverse path check fail, drop"
I recommend you set the distance to 1 so that it takes priority, you should decide depending on your other routes.
Instead of using the /24, you could use the gateway the WAN1 port of the Fortinet A is using. For this demonstration to help keep your sanity, we've left it at the full subnet.
4) Test it out!
The best method to test this is to telnet to port 36008 from an EXTERNAL location to 126.96.36.199.
You can do this with any operating system.
Telnet 188.8.131.52 36008
If it connects to your service, you're good to go!
If you're having issues, I suggest changing the forwarding port to a port that you know is open on the server. Try using telnet from the inside of your network to verify the port is open, and then test externally.
Common server ports are 21, 22, 80, 110, 143, 3389
Check which ports are open on your server, head back to Step 1) and use this port instead.
Once you have it routing through to that port correctly, change it to the actual port you need.
Move or transfer Windows 2008/2008R2 virtual machines between vSphere/ESXi hosts using Windows Backup
Something to note, this will work regardless of your ESXi versions. Because we are relying on the windows backup instead of vMotion or other tools, the VM host/datastore is not relevant.
1) Create a network share
This share must reside on a server or PC accessible to you virtual machine, and the user you will be used to connect to it must have full/read.
2) Log onto your existing virtual machine
Verify you can access this network share by IP or hostname (ie. \\computername\sharefolder). Do not proceed further until you can see and write to this folder from 1).
3) Install the Windows Server Backup tools
Load the Server Manager > Features > Add Features > Windows Server Backup Features (everything) > install
4) Load the Windows Server Backup tools
Load the Administrator Tools -> Windows Server Backup
5) Create a backup and dump your image to the network share you created
Windows Server Backup > Backup Once > Full Server (recommended) > Remote Shared Folder > \\computername\sharefolder > Inherit
You will be prompted for credentials.
MAKE SURE you use credentials that have full read/write access to the folder your shared!
START the backup!
6) While the backup is running, create an empty VM on the new vSphere host
Load up your vSphere client ->CTRL-N
Name: You tell me!
Storage: Choose the location for the new VM
Guest OS: Windows 2008 R2 64bit
Network: Pick 1 network card, the correct network, and E1000 with Power On. DO NOT CHOOSE ANOTHER TYPE OF NETWORK CARD!
Windows 2008 R2 will recognize the e1000 with it's native drivers. You can change the network settings later.
Disk Provisioning: The size of your virtual disk size should be AT LEAST the size of the old VM virtual disk size.
I should note that you can also use this opportunity to INCREASE the size of your partitions. If your old VM is running out of space, crank it up here and Windows will increase the size of your partitions on restore.
Finish: Choose to "edit the virtual machine settings before completion" and click continue.
7) Verify your VM settings
Make sure the RAM, CPU and other settings are verified for your old VM. This would be an excellent time to beef it up if you need to.
8) Configure the CD/DVD to mount and boot off of a Windows 2008/2008R2 Server image
Click the "New CD/DVD (adding)" devices -> side window -> Datastore ISO File or Host Device or Client Device > Find the ISO or DVD for windows server 2008 / 2008R2
Enable the "Connect at power on" option at the top.
9) Check the status of the running backup from earlier. Do not proceed until the backup is completed and successful.
Once the backup is complete, power down the old VM. If you turn it back on, you run the risk of IP address, DNS and hostname conflicts.
10) Start the new Virtual Machine and start the Windows 2008 installation process
Choose your default language, time, keyboard -> next
Choose "Repair your computer" (bottom left)
Choose "restore your computer using a system image that you created earlier" > next
Choose "cancel" when it reports "Windows cannot find a system image on this computer"
Choose "select a system image" > next
Choose "advanced" > "Search for a system image on the network" > "yes"
You will now be provided a field to enter the network path to the backup share we created earlier. Make sure to type it in exactly as your testing value.
Click OK (it will now attempt to access that folder)
Enter the login credentials for the share you created.
If everything you entered and shared is correctly setup, you will be provided a populated table with the backup completed earlier.
Choose Next, Next
11) If you wish to increase the size of the partitions from the old VM, this is your chance.
12) Finish it up and get the restore started
This process could take minutes to hours depending on the size of your old VM.
13) Finish the new VM configuration and take it live
At this point, the snapshot of your previous VM is now live on the new VM.
The last steps include:
- Install the VMware tools using the built-in tools
- Adjust any network settings , network card types (i prefer the VMXNET3 drivers myself)
- Double check all services and applications are live after you reboot (vmware tools and network changes should be followed by a reboot)