Monthly Archives: September 2017

Redundant Cisco ASA VPN scenario

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.

 

layout

CONFIG

Branch ASA:

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

VPN CONFIG:

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

tunnel-group 3.3.3.1 type ipsec-l2l
tunnel-group 3.3.3.1 ipsec-attributes
ikev1 pre-shared-key password

 

Core Config:

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

VPN CONFIG:

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

Fortigate VXLAN Encapsulation over IPSEC

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.

layout

Here is a check lists of things that are needed:

  • Create VXLAN VPN
    • Local encap-local-gw4 is the public address on the local FW
    • encap-remote-gw4 is the peer address of the other side
    • remote-gw is the peer address of the other side
  • Then create a new Switch interface
    • Add both the local network, and VXLAN-VPN interface to this switch
  • Create firewall policies allow traffic

Thoughts and observations:

  • Lowering the MTU of the VXLAN/internal interface might be a good idea. The VXLAN encapsulation adds around 50-bytes. Most Cisco documentation will mention increasing the MTU, but since we are going over the net with this, increasing MTU means lots of fragmentation.
  • No IP address on the Switch interface is needed. Actually I have seen small issues when putting an IP address on the interface.
  • In CLI use the commands below to help get broadcasts (be careful) and ARP to go across.
    • config sys int
      • edit VXLAN
        • set l2forward enable
        • set broadcast-foward enable
        • end
      • end
  • In 5.6.2 VLANs tags will pass through the tunnel

CONFIG

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

60d-switch

Then lets check out the Firewall Policies

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

60-e interface

Next lets check out the Firewall Policies

fw-60e

 

Testing

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

 

Conclusion

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

802.11 Wireshark filters

Below are some examples of 802.11 wireshark filters. Have a reference to these helps a lot for quick troubleshooting. This will be an ongoing list.

 

wlan.fc.type_subtype== 0x08 – Beacon frames

wlan.fc.type_subtype== 0x4 – Probe Request

wlan.fc.type_subtype== 0x5 – Probe response

wlan.fc.type_subtype== 0xb — Authentication frames

wlan.fc.type_subtype==0x0 – association request

wlan.fc.type_subtype==0x1 – association response

wlan.fc.type_subtype==0x2 – reassocation request

wlan.fc.type_subtype==0x3 – reassocation response

wlan.fc.type_subtype==0x1b – RTS Frame

wlan.fc.type_subtype==0x1c – CTS Frame

wlan.fc.type_subtype==0x1d — ACK frame

wlan.fc.type_subtype==0x24  – Null data

wlan.fc.type_subtype==0x1a WMM PS Poll frame

Finding the source or DST of a wireless packet:

wlan.sa == dc:53:60:76:1d:21

wlan.da == dc:53:60:76:1d:21