Site-to-site VPN connections are a common way to connect a branch office to the corporate network. In the Netherlands it is still common to have a internet connection at a branch office with a dynamic IP address. The usage of dynamic IP address is not ideal when configuring a site-to-site VPN connection, because the configuration almost always relies on static IP addresses.
I recently configured an IPSec VPN between two FortiGate appliances and the branch appliance is using a dynamic IP address. I used Fortinet’s DDNS feature to configure the VPN.
To configure the branch FortiGate for DDNS, I had to configure the WAN interface to retrieve its IP address via DHCP. Next I configured DDNS.
config system ddns
set ddns-server FortiGuardDDNS
set ddns-domain “branche01-booches.fortiddns.com”
set monitor-interface “wan1”
This can also be done in the GUI.
The VPN configuration on the hub firewall for dynamic DNS support is the same as the configuration of a regular VPN connection. The only difference is the configuration of the peer IP address. Instead of a static IP, you configure the DDNS FQDN.
config vpn ipsec phase1-interface
set type ddns
set interface “wan1”
set proposal 3des-sha1
set dhgrp 2
set remotegw-ddns “branche01-booches.fortiddns.com”
set psksecret P$k-VPN!
And as you can image, this can also be done via the GUI.
Check the status of the VPN connection via the regular methods like cli (get vpn ike gateway or get vpn ipsec tunnel name <tunnel-name>) or via the GUI.
In different scenario’s it is required to configure some kind of routing protocol between two offices, but the routers should be configured to look directly connected to each other. Normally I always configure an IPsec VPN between the two offices and configure an additional GRE tunnel over the IPsec VPN tunnel. In that way the routers look directly connected and adding a routing protocol is no problem.
In the past I noticed several times that the GRE tunnel doesn’t come up, when using a Cisco PIX firewall or a Cisco ASA firewall. When using IOS 6.x on the PIX or 7.x on both hardware platforms, there is a workaround by using the following command:
clear local-host <remote peer>
Cisco has reported this bug in BugID CSCse36327:
The IPSEC tunnel was previously working and either one of the following events occured:
1. the crypto map and/or isakmp has been removed and reapplied to the interface
2. the PIX/ASA is upgraded from version 6.x to version 7.x
3. the PIX/ASA is rebooted
4. The remote IPSEC peer/s is rebooted
All events except 1 occur when a dynamic crypto map is used without a match address statement.
This typically affects only GRE traffic.
In PIX/ASA 7.x, GRE encryption may stop working (GRE packets are sent in clear) after removing and reapplying the encryption. This behaviour is by design in 7.x. If encryption is disabled but GRE packets are coming to the PIX in this time, GRE session is created on the PIX and marked as clear-text one (“do not encrypt”). When encryption is applied back, non-encrypted GRE session still exists on PIX and GRE packets that should be encrypted still bypass crypto map until old session is timed out or deleted. If there is a dynamic routing (OSPF/EIGRP/etc) running over GRE, this GRE session may never timeout and should be cleared manually.
In PIX/ASA 8.0.2, new functionality was introduced with new CLI command: “sysopt connection reclassify-vpn”. Default state is disabled. If this command is enabled, then enabling encryption causes non-encryption sessions to be dropped and reestablished with encryption.
Looks like there is a new command introduced in IOS 8.0.2 as mentioned above, by using sysopt connection reclassify-vpn.
There is also an entry on the Cisco SupportWiki about this problem. So the next time I will try this new command.