Cisco ASA (Pre X series) are still extremely common.
This entry describes a redundant VPN setup of two ISPs on the Branch firewall (Cisco 5505), and one ISP on the Datacenter/hub side (Cisco ASA 5510).
The Branch office has a cable connection as their primary ISP and a backup 4G Cradle Point. We will be using SLAs to track the internet status of the Cable connection, and a floating static route to control backup route priority.
The idea behind the branch office is that two different Crypto Maps exist, one mapped to each of the interfaces. If the SLA fails and brings down the primary internet the traffic starts going out of the backup connection which has a backup Crypto map applied. When the primary interface comes back up, then traffic will start going over the crypto map applied to it. Therefore we do not have flip/flop VPNs and it solves the issue of having one crypto map applied to two different interface.
interface Vlan2
nameif PRIMARY
security-level 0
ip address 1.1.1.10 255.255.255.0
!
interface Vlan12
nameif BACKUP
security-level 0
ip address 2.2.2.10 255.255.255.0
object-group network CORE-SUBNETS — Object group for Core subnets
network-object 10.0.0.0 255.255.255.0
network-object 192.168.0.0 255.255.255.0
object-group network BRANCH-SUBNETS — Object group for Branch subnets
network-object 192.168.18.0 255.255.255.0
object network Any-Cable — NAT For Primary
nat (inside,PRIMARY) dynamic interface
object network Any-Backup — NAT For Backup Internet
nat (inside,BACKUP) dynamic interface
NO-NAT
nat (inside,any) source static BRANCH-SUBNETS BRANCH-SUBNETS destination static CORE-SUBNETS CORE-SUBNETS
SLA config:
sla monitor 123
type echo protocol ipIcmpEcho 8.8.8.8 interface PRIMARY
sla monitor schedule 123 life forever start-time now
route PRIMARY 0.0.0.0 0.0.0.0 1.1.1.1 1 track 2 – The Track statement maps that SLA to the route
route BACKUP 0.0.0.0 0.0.0.0 250 – Floating Static – Makes this a backup route. I set the distance to 250
access-list VPN-to-CORE permit ip object-group BRANCH-SUBNETS object-group CORE-SUBNETS
crypto ipsec ikev1 transform-set AES256SHA esp-aes-256 esp-sha-hmac
Primary Crypto
crypto map BRANCH_MAP 100 match address VPN-to-CORE
crypto map BRANCH_MAP 100 set peer 3.3.3.1
crypto map BRANCH_MAP 100 set ikev1 transform-set AES256SHA
crypto map BRANCH_MAP 100 set security-association lifetime seconds 28800
crypto ikev1 enable PRIMARY
crypto map BRANCH-MAP interface PRIMARY
BACKUP Crypto MAP
crypto map BRANCH-MAP-BK 100 match address VPN-to-CORE
crypto map BRANCH-MAP-BK 100 set peer 3.3.3.1
crypto map BRANCH-MAP-BK 100 set ikev1 transform-set AES256SHA
crypto map BRANCH-MAP-BK 100 set security-association lifetime seconds 28800
crypto map BRANCH-MAP-BK interface BACKUP
crypto ikev1 enable BACKUP
crypto ikev1 policy 10
authentication pre-share
encryption aes-192
hash sha
group 2
lifetime 86400
tunnel-group 3.3.3.1 type ipsec-l2l
tunnel-group 3.3.3.1 ipsec-attributes
ikev1 pre-shared-key password
object-group network CORE-SUBNETS — Object group for Core subnets
network-object 10.0.0.0 255.255.255.0
network-object 192.168.0.0 255.255.255.0
object-group network BRANCH-SUBNETS — Object group for Branch subnets
network-object 192.168.18.0 255.255.255.0
NO-NAT
nat (inside,any) source static BRANCH-SUBNETS BRANCH-SUBNETS destination static CORE-SUBNETS CORE-SUBNETS
access-list VPN-to-BRANCH permit ip object-group CORE-SUBNETS object-group BRANCH-SUBNETS
crypto ipsec ikev1 transform-set ESP-AES-256-SHA-TRANS esp-aes-256 esp-sha-hmac
crypto map outside_map 100 match address VPN-to-BRANCH
crypto map outside_map 100 set peer 1.1.1.10 2.2.2.10 —Notice both IPs
crypto map outside_map 100 set ikev1 transform-set ESP-AES-256-SHA
crypto map outside_map 100 set reverse-route
crypto ikev1 enable outside
crypto map outside_map interface outside
crypto ikev1 policy 10
authentication pre-share
encryption aes-192
hash sha
group 2
lifetime 86400
tunnel-group 1.1.1.10 type ipsec-l2l
tunnel-group 1.1.1.10 ipsec-attributes
ikev1 pre-shared-key password
tunnel-group 2.2.2.10 type ipsec-l2l
tunnel-group 2.2.2.10 ipsec-attributes
ikev1 pre-shared-key password
VXLAN is a Layer2 overlay scheme over a Layer 3 network. VXLAN uses MAC Address-in-User Datagram Protocol (MAC-in-UDP) encapsulation to provide a means to extend Layer 2 segments across a layer3 segment. This basically means the layer2 packet gets a VXLAN header applied, then that frame gets encapsulated into a UDP IP packet and sent over to the layer3 network.
In later FortiOS 5.4 firmwares VXLAN (Virtual Extensible LAN) encapsulation was added. This is a great technology that can help connect to sites at layer2 over layer3. Something to take note of – as of FortiOS 5.6.2 – lots of improvements and enhancements to VXLAN encapsulation have been made. For example, vlan trunking works well now. Mutlicast also will traverse the VXLAN!
So far I have set this up for two different clients. Both were situations where we had to have layer 2 stretched for a certain purpose. in the last case it was to two different data centers. Below is the scenario and config of the Fortigates as well as show ARP/MAC from the Cisco switch. Fortinet has some great documentation as well on this feature (Links below).
http://kb.fortinet.com/kb/documentLink.do?externalID=FD38614
http://kb.fortinet.com/kb/documentLink.do?popup=true&externalID=FD40170&languageId=
Below shows our simple layout. The red line indicates the VXLAN encapsulation path. Encapsulation only happens at Fortigate firewalls.
Here is a check lists of things that are needed:
Thoughts and observations:
SIDE 1 (60D)
config vpn ipsec phase1-interface
edit “VXLAN”
set interface “wan2”
set peertype any
set proposal aes256-sha1
set encapsulation vxlan
set encapsulation-address ipv4
set encap-local-gw4 1.1.1.1
set encap-remote-gw4 1.1.1.2
set remote-gw 1.1.1.2
set psksecret password
next
end
config vpn ipsec phase2-interface
edit “VXLAN_ph2”
set phase1name “VXLAN”
set proposal aes256-sha1
next
end
config system switch-interface
edit “VXLAN-SWITCH”
set vdom “root”
set member “internal1” “internal2” “VXLAN”
next
end
Lets look at the Switch in the gui
Then lets check out the Firewall Policies
SIDE 2 (60E)
config vpn ipsec phase1-interface
edit “VXLAN”
set interface “wan1”
set peertype any
set proposal aes256-sha1
set encapsulation vxlan
set encapsulation-address ipv4
set encap-local-gw4 1.1.1.2
set encap-remote-gw4 1.1.1.1
set remote-gw 1.1.1.1
set psksecret password
next
end
config vpn ipsec phase2-interface
edit “VXLAN_ph2”
set phase1name “VXLAN”
set proposal aes256-sha1
next
end
Lets look at the Switch in the Gui
Next lets check out the Firewall Policies
First make sure the VPN is up and working. Then a simple ping test between two devices on the same subnet will be enough to make sure things are working. TCP is always the best way to test . You can also check and make sure that the ARP/MAC address tables on each side show something on the remote side. For example the below shows the ARP/MAC of the Cisco 3650 switch at the Datacenter side (60D).
Datacenter-Stack#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.19.21 0 000c.291c.b2a5 ARPA Vlan1
Internet 192.168.19.51 0 000c.2918.b8be ARPA Vlan1 – 19.51 lives behind the 60E
Datacenter-Stack#show mac address-table
Mac Address Table
——————————————-
Vlan Mac Address Type Ports
—- ———– ——– —–
1 000c.2918.b8be DYNAMIC Gi1/0/1 — Fortinet 60D is connected to gig 1/0/1
Thats it! VXLAN is an open source protocol that is a great datacenter technology. Fortinet makes it very easy to get this up and going within a few minutes. EB
This configuration was in ASA 8.4
Spoke to spoke communication has always been super easy in ASA Site to Site VPNs. As long as your CRYPTO ACL has the remote subnets in it, and NO-NAT Statements are there everything pretty much works.
The other day I had an issue getting it to work. After some research I was still struggling. All of my remote sites were in my Crypto ACL, my VPN was up and working to the hub, and any subnet behind the hub would work, but access to other IPSEC tunnels connected behind were not working. See rough sketch of the network below.
I checked Nat statements, looked great, but my traffic was not flowing. I decided to debug via ASDM this is the error I received.
Routing failed to locate next hop for ICMP then my outside (Louisville), and inside (Italy) address.
Other examples are:
Routing failed to locate next hop for TCP then my outside (Louisville), and inside (Italy) address.
Routing failed to locate next hop for UDP then my outside (Louisville), and inside (Italy) address.
Well, 192.168.17.0/24 does not live inside my firewall – it should be connected to the outside (US-Signal) VIA the VPN. Boom, that’s when it clicked. My nat statement is wrong, well not wrong, just missing. Since these connections are connecting to my outside network, and then going to my outside network – I need to create the nat statement with the source interface and destination interface being US-Signal.
A few things to note about the below statement – I put it at the top of my manual nat entries, and notice the interface – both are US-Signal my outside interface.
object network Louisville-Subnet
subnet 10.26.0.0 255.255.0.0
object network Italy-Subnet
subnet 192.168.17.0 255.255.255.0
nat (US-Signal,US-Signal) source static Louisville-Subnet Louisville-Subnet destination static Italy-Subnet Italy-Subnet no-proxy-arp route-lookup
As soon as I added this statement everything worked great. All of my spoke to spoke communication flowed through the hub perfectly.
I thought I would blog on this. It could be useful for someone who might have an IOS router instead of an ASA and need to create a IPSEC Site-to-Site VPN to a remote peer, then NAT VPN traffic to a different address or subnet if needed, or the local subnets conflict with each other.
Here is a nice little Visio to kind of show what I am going for with the traffic:
Because of duplicate subnets on both sides, I need to nat traffic going to 172.90.0.20 from 192.168.10.10, otherwise traffic should flow normally. How can I achieve conditional nat? By using a route-map and then natting only the traffic in the Route-map. So, lets get our VPN setup first. Remember, we add the NAT network or host IP to our interesting traffic ACL that will be used to define our Phase2
These are my commands:
ip access-list extended VPN-to-Remote
permit ip host 10.255.232.10 host 172.20.0.192
crypto isakmp policy 50
encr 3des
authentication pre-share
group 2
lifetime 28800
crypto isakmp key … address 1.1.1.1 no-xauth
crypto ipsec transform-set Transform esp-3des esp-sha-hmac
crypto map Crypto 6 ipsec-isakmp
set peer 1.1.1.1
set transform-set Transform
match address VPN-to-Remote
That pretty much gets the VPN up and going. Now for the interesting part – we need to create a new ACL, match my private 192.168.10.10 address and the destination address of the remote server, then match that ACL in my Route-map.
ip access-list extended Nat-for-VPN
permit ip host 192.168.10.10 host 172.20.0.192
route-map VPN-to-REMOTE permit 10
match ip address Nat-for-VPN
!
Great! So, we now have the route-map created.. so now what? We need to create a NAT statement that references my Route-Map. Then of course with any VPN we need to modify the “NO-NAT” ACL to include the traffic for both the 192.168.10.10, and the 10.255.232.10 to my remote destination.
ip nat inside source static 192.168.10.10 10.255.232.10 route-map VPN-to-HCN extendable
ip access-list extended NO-NAT
deny ip host 10.255.232.10 host 172.20.0.192
deny ip host 192.168.10.10 host 172.20.0.192
Now, if we try to access the remote side, does it work? Yes it does, but lets check to see if our nat is really working. It is! As you can see, 192.168.10.10 going to 172.20.0.192 is being natted into 10.255.232.10, but all other traffic gets natted out of the WAN interface.
Lets just check for translations of 10.255.232.10
Bingo, everything works great. Lets make sure that we are getting hits on our Route-Map.
The Fortigate SSL is an amazing feature, but when users do not log in that often to any internal resources their AD password may expire and the user will not know. What really stinks is if that user has to post data for the month, and logs in at midnight for an 8 a.m. deadline! Luckily Fortigate has the ability to push the LDAP password expiration notification to the user, and can even let them change the password through SSL VPN login.
Steps:
– Get SSL VPN up and going with LDAP Authentication – This has to be an LDAPS connection to change the password, and your account to query LDAP has to be a domain admin!!!
– In CLI modify the LDAP server to allow password expiration notification, and change.
First create or modify your LDAP server in the GUI, and make sure its set to use LDAPS. The image below should be a good guide. Remember, the service account you use to query LDAP does not have to be an admin account, but if you want to change passwords then it does have to be a Domain-Admin. A good idea is to always create a service account to use for the Fortinet to query LDAP. That way if your admin password changes it will not affect this this account.
After that is configured, and tests/querys successfully then lets drop down to CLI and get the following configured.
Config user ldap
edit “Server name”
set password-expiry-warning enable
set password-renewal enable
end
For a look at all the options see picture below:
And that’s it, after this LDAP will push those messages to the client when they log in.
Remember, that the LDAP connection has to use SSL (LDAPS) to change the password.
After setting up a SSL VPN tunnel, one of the biggest complaints I get is “I cannot get to my shares”. This is because the Domain suffix has not been pushed out to their tunnel interface. This is easy to remedy, but seems to be in CLI only.
Within cli you have many options under the ssl vpn config that are not presented in the GUI.
You can edit the VPN tunnel with the command:
config vpn ssl settings
Here are a list of all the settings:
as you can see, the dns-suffix is an option, as well as DNS servers.
The Suffix option is not presented in the GUI, but the dns servers are.
The command to set the suffix is:
set dns-suffix corp.local
end
Make sure your DNS servers are also set for your internal network and it should now work without a problem.
There are multiple parts to the IPSEC SIte-to-Site VPN config.
– Create access list to specify what will be encrypted
– Create access list to specify what should go over the VPN, and not be natted
– Create Phase 1 (IKE) settings and apply it to the selected interface.
– Create our transformation set (what encryption settings we will use for phase 2).
– Create Phase 2 (ESP) settings otherwise known as a Crypto map.
– Apply Crypto map settings specifying interface.
– Create the tunnel object for peer.
Config:
ASA 1 Core
Create Objects
First create the objects representing what will be found on each side of the VPN.
config t
object network Local-Subnet
subnet 10.100.1.0 255.255.255.0
object network Remote-Subnet
subnet 10.100.2.0 255.255.255.0
Encryption Access-list
Next I will create the Access list to tell the firewall what to Encrypt
access-list VPN-to-Remote extended permit ip object Local-Subnet Remote-Subnet
Now we need to make sure traffic is not being forwarded out of our WAN interface, and that the firewall knows to send it over the VPN. We do this with a “No-Nat” statement. This is different than what it once was in 8.2 and below. We will specify this with a different kind of nat statement.
No NAT
nat (inside,outside) source static Local-Subnet Local-Subnet destination static Remote-Subnet Remote-Subnet
IKE Settings
Now its time for the VPN settings!
First lets create our IKE settings and enable it on the outside interface.
crypto ikev1 enable outside
crypto ikev1 policy 1
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
Create the IPSEC transformation
crypto ipsec ikev1 transform-set transfrom esp-3des esp-sha-hmac
Crypto MAP (Phase 2)
Now lets create our Crypto map and put it all together.
crypto map VPN 10 match address VPN-to-Remote
crypto map VPN 10 set pfs
crypto map VPN 10 set peer 1.1.1.2
crypto map VPN 10 set ikev1 transform-set transfrom
crypto map VPN 10 set security-association lifetime seconds 28800
crypto map VPN 10 set security-association lifetime kilobytes 4608000
There are a few optional settings like the lifetime, by default its 28800. In this config I am just making it known that’s what its set on. Also you can set “reverse-route” which will add the route to the remote subnet into the routing table. This way you can push it out in a routing protocol.
We will also need to apply the Crypto map to the interface.
crypto map VPN interface outside
Tunnel Group/PSK
Our last step is to create the tunnel group with our Peer IP/DNS name and set the PSK.
tunnel-group 1.1.1.2 type ipsec-l2l
tunnel-group 1.1.1.2 ipsec-attributes
ikev1 pre-shared-key presharedkey
Below is the config for the Remote side
config t
object network Local-Subnet
subnet 10.100.2.0 255.255.255.0
object network Core-Subnet
subnet 10.100.1.0 255.255.255.0
access-list VPN-to-Remote extended permit ip object Local-Subnet Core-Subnet
nat (inside,outside) source static Local-Subnet Local-Subnet destination static Core-Subnet Core-Subnet
crypto ipsec ikev1 transform-set transfrom esp-3des esp-sha-hmac
crypto ikev1 enable outside
crypto ikev1 policy 1
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
crypto map VPN 10 match address VPN-to-Core
crypto map VPN 10 set pfs
crypto map VPN 10 set peer 1.1.1.1
crypto map VPN 10 set ikev1 transform-set transfrom
crypto map VPN 10 set security-association lifetime seconds 28800
crypto map VPN 10 set security-association lifetime kilobytes 4608000
crypto map VPN interface outside
tunnel-group 1.1.1.1type ipsec-l2l
tunnel-group 1.1.1.1 ipsec-attributes
ikev1 pre-shared-key presharedkey
The best information available for anything fortinet is always found at docs.fortinet.com. This entry will show the needed steps to create a SSL VPN via the web interface.
Creating the SSL VPN has many working parts that come together to make one of the best Remote access VPNs out there. In this example we are creating a Split tunnel VPN, and enabling Tunnel mode.
The SSL VPN is one of the best features of the device, it has an open license, so you can have as many people connect as the device hardware supports. No crazy licensing for SSL VPN as with Cisco and Sonicwall. You can also utilize the VPN to get select information to users based on their AD security group. For example if you have a business with users traveling all the time, you might have a certain portal for one group of users and have their internal bookmarks and file shares, and completely different portal for office staff users. Another great benifit is in the protocol itself, SSL is almost never blocked by outbound firewall policies. A lot of companies (hotels, hospitals) and educational institutions block IPSEC from leaving the network which stops your remote access VPN from connecting.
Steps:
1. Create Address object for SSL Subnet and Internal networks
2. Create route for new subnet
3. Create Users/User group for user authentication
4. Config the VPN Portal
5. Config the VPN settings
6. Create the SSL VPN policy, including the projected subnet for Split Tunnel.
7. Create policy to allow traffic from the Lan to SSL, and from SSL to Lan.
1. Create Address object for SSL Subnet and Internal networks
We will create an address object with the Subnet of our SSL VPN clients. I would recommend using a crazy private IP subnet as to not conflict with Home/work local subnets.
Then we need to create another object for our Protected subnet. This is our internal network that we want the remote user to be able to access. If there are multiple subnets it might be better to add an address object group.
2. Create route for new VPN subnet
Since the SSL VPN is a “interface” we will route our subnet across of it. Notice our device is ssl.root, and that removes our needed gateway.
3. Create Users/User group for user authentication
There are many different ways to configure authentication within the device. You can authenticate VPN users against LDAP, Radius, or local accounts. In this example I am just using local accounts, but using LDAP or Radius is a much better option. You can use just individual users, or groups to authenticate to within the VPN policy. I would go ahead and create a User group so that you can add any local, radius, or ldap users into it in the future.
I am creating a user group call SSL_VPN and in this case its just local. If I wanted to add a LDAP/Radius server to authenticate against, I could just add the remote server. If I wanted to get even more specific and say authenticate against a security group within LDAP I would just modify the remote server portion of the user group to add that.
4. Config the VPN Portal
The portal is the landing page of the SSL VPN. It is a great place to add book marks, shortcuts for RDP, or info for users. For example, we have an internal sharepoint site for users, by placing a link on the portal, users they just have to click and Whola, instant access. This is great because installing the VPN client which allows tunnel mode requires admin access to the PC. If a user is traveling or at a hotel they might not have this access. Other great uses are RDP session, and file shares. Both will launch in a Java applet window and allow you access to RDP/SMB.
We are using the “Full-access” Portal, this is just a name. I added the IP Pool for the clients to get tunnel addresses. You can customize the page to any specification. A note, you can also fully edit your VPN login page to reflect your company logo, etc. You can do this by adding in the feature under system – admin- features and enabling it.
5. Config the VPN settings
The VPN settings consists of the IP pool, Port used, encryption strength, and of course DNS/WINs servers. If you want to push your domain name so that DNS will resolve to this interface, its a CLI command. I will do another entry on it.
6. Create the SSL VPN policy, including the projected subnet for Split Tunnel.
This is where we actually allow access from the internet to our VPN portal. It is also where we specify our Protected subnets, which are the subnets injected into the clients routing table. You can also specify what portal certain users will see. For example, if you had a group of teachers who needed to get to the Teacher portal, and an admins group that needs to have a different portal and ACL to get to all servers.
Notice we select VPN as type, then incoming interface. The Local protected subnets are what we are pushing into the routing table of our client.
Next create an new Authentication policy.
From here select your user group that we created earlier, if you want individual users select those as well. You can also enable UTM if you feel its needed.
Now just save all the settings
7. Create policy to allow traffic from the Lan to SSL, and from SSL to Lan.
For the last step we need to create policies to allow traffic in both directions. By default all traffic is blocked between interfaces int he firewall. The SSL VPN is an interface, so we need to allow traffic to it.
Just create a policy with Source interface being ssl.root, and allow all traffic to your LAN (or however you see is best to secure) and then another policy from LAN to ssl.root.
Thats it! There are some optional configs dealing with Certs on both sides, and much stronger encryption methods.
Notes*
If you have a MPLS, or DMZ interface where you need VPN clients to access you will have to create another VPN policy going from WAN to – DMZ, or WAN to MPLS and just mirror the WAN-to-lan SSL VPN policy. You will also have to modify the protected subnets with that interfaces network. If anyone has trouble with this feel comment and I will explain better.
On top of that you will need to create more ssl.root to DMZ and DMZ to ssl.root policies to allow access between the interfaces.