Fortigate – Ping and Traceroute options

Within the Fortigate firewall you can modify many ping and traceroute options to suite what needs you might have. For example, if you need to modify the source IP address for a ping or trace you have that option and many more. Both ping and traceroute are crucial network troubleshooting  tools. Many times I need to ping through a VPN tunnel  using my internal interface, which is in the encryption domain to make sure the tunnel is up and working. or make sure the source of my ping or traceroute are on a local subnet to rule out routing/gateway issues.

The list below shows the table of ping options available:

Fortigate-Firewal # exe ping-options
adaptive-ping Adaptive ping <enable|disable>.
data-size Integer value to specify datagram size in bytes.
df-bit Set DF bit in IP header <yes | no>.
interface Auto | <outgoing interface>.
interval Integer value to specify seconds between two pings.
pattern Hex format of pattern, e.g. 00ffaabb.
repeat-count Integer value to specify how many times to repeat PING.
reset Reset settings.
source Auto | <source interface IP>.
timeout Integer value to specify timeout in seconds.
tos IP type-of-service option.
ttl Integer value to specify time-to-live.
validate-reply Validate reply data <yes | no>.
view-settings View the current settings for PING option.

So to highlight a few of these options – Lets modify the source address we are pinging from, increase the amount of pings and then show the settings to confirm all is set.

Fortigate-Firewall# exe ping-options source 192.168.1.1
Fortigate-Firewall# exe ping-options repeat-count 1000
Fortigate-Firewall# exe ping-options view-settings

Ping Options:
Repeat Count: 1000
Data Size: 56
Timeout: 2
Interface: auto
Interval: 1
TTL: 64
TOS: 0
DF bit: unset
Source Address: 192.168.1.1
Pattern:
Pattern Size in Bytes: 0
Validate Reply: no
Adaptive Ping: disable

I removed the default settings it spits out for brevity. That’s it though, we now have changed the source and the repeat count. Lots of other cool settings like ToS and size available.

Now on for Traceroute – You have less options, but the main two that I use – modifying the source IP or interface and setting the amount of hops it will go.

Fortigate-Firewall # exe traceroute-options
device Auto | <ifname>.
queries Integer value to specify number of queries per hop.
source Auto | <source interface IP>.
view-settings View the current options of traceroute.

Lets set the source for the traceroute to 192.168.1.1 and then check the settings.

Fortigate-Firewall# exe traceroute-options source 192.168.1.1

Fortigate-Firewall# exe traceroute-options view-settings
Traceroute Options:
Number of probes per hop: 3
Source Address: 192.168.1.1
Device: auto

Thats it! now we are modifying our source IP for both ping and Traceroute.

Advertisements

Cisco ASA – E-SMTP

I recently had an issue with a Office 365 deployment. This was a hybrid deployment, and as we were trying to start syncing to Office 365 we were getting an error in our logs :

(Retry : Must issue a STARTTLS command first)

This was causing mail not to flow. This site happened to be behind a Cisco ASA. After some research the cause of this problem is that the ASA is inspecting ESMTP in the policy map, which is stripping the STARTTLS packets.

To bypass this you have to create a new policy map to make sure the parameters of the inspection allow encrypted connections – the default is to not allow this, and it does this by removing the STARTTLS packets.

First lets create our policy map

policy-map type inspect esmtp esmtp_map
parameters
allow-tls action log

Then we will modify the global policy and match this policy for inspection. In the following example, the service policy is all default – the global_policy.

policy-map global_policy
class inspection_default

inspect esmtp esmtp_map

Thats it – now it will allow TLS . I had one other issue when applying I kept getting this error – ERROR: Inspect configuration of this type exists, first remove
that configuration and then add the new configuration

I was getting this error because by default the “Inspect esmtp” option is enabled in the global_policy map. So first remove this inspection and then reapply.  After modifying the ESMTP parameter mail started flowing. The follow shows that whole step.

show run

policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
!

config t

NHS-ASA(config-pmap)# policy-map global_policy
NHS-ASA(config-pmap)# class inspection_default
NHS-ASA(config-pmap-c)# inspect esmtp esmtp_map
ERROR: Inspect configuration of this type exists, first remove
that configuration and then add the new configuration

NHS-ASA(config-pmap-c)# no inspect esmtp
NHS-ASA(config-pmap-c)# inspect esmtp esmtp_map

show run :

policy-map type inspect esmtp esmtp_map
parameters
allow-tls action log
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect esmtp esmtp_map
!
service-policy global_policy global

 

 

802.11 – WIFI IFs

Inter frame spacing is some of the magic in WiFI. Its also one of the more confusing aspects of studying and understanding how WMM, and processes like Point coordination function work. Inter frame spacing is used to help avoid collisions on the wireless spectrum.

When a station wants to send a frame there are two methods that have to be OK before it can do this. 1 – Physical Carrier sense. Physical Carrier Sense is the process of checking to see if the wireless medium is busy. It does this my checking the wireless medium for RF energy, if it is above a certain threshold then it will wait to send.

The second check is Virtual Carrier sense. This method looks at passing wireless frames and sets a local MAC layer timer called the Network allocation vector or NAV to the amount of time found in the passing frame’s Duration field. When this reaches 0 it attempt a Physical Carrier sense. If the NAV is 0 and Physical Carrier sense shows RF energy below its threshold – the station will then wait the length of a Interframe space, then wait through the random backoff algorithm time (decided by the contention window), run through the carrier sense process again – then will actually send the frame.

The importance of the IFS is that the station has to wait that given amount of time. In the section below all the different IFS are listed with the its length of time. When studying for the CWAP exam I had a hard time remembering them, so hence the blog entry.

Once the station has the okay to send (Carrier sense is good) then it will wait the given IFS length. This is a big deal because not only does the STA wait the length of time before attempting to send the frame, but it can be used to give priority to certain frames over others. We do this by having that station wait less time then others based on the type of frame they are sending. By Priority I mean it asks the client to wait a smaller amount of time before sending the packet with a higher priority – This is called Probabilistic priority.

The following is a quick list of interframe spacing methods and are ordered by the duration time – shortest to longest time.

RIFS – Reduced IFS – Shorter than SIFS. Came out in 802.11n , to help minimize overhead. RIFS are used when one transmitter is sending packets when no SIFS reponses are expected. This IFS is not used in 802.11ac.

SIFS – Short Interframe Spacing – Shortest of all IFs . Used for ACKs, CTS in response to RTS, and the first data frame following the CTS.

PIFS – Point Coordination interframe space. – Used by the Point Coordination function to gain access to the medium. Used when switching from Distributed Coordination to Point Coordination

DIFS – DCF (Distribution coordination function) Interframe spacing– used with normal data frames. After the completion of sending a data frame the duration of a DIFS must be waited before attempting to send another.

AIFS – Arbitration IFS – Used in a kind of QoS manner. When a QoS station send data frames it waits an AIFS. Also used on a few control frames such as PS-Poll, CTS when not responding to a RTS (Thats a SIFS), BlockACKs, and RTS frames. A neat thing abou the AIFS is that the time is configurable on the AP, and then transmitted to clients by the Beacon frame.

EIFS – Extended IFS – Extended for a reason – When a frame is received with errors or corrupted the receiver will respond with  EIFS which tells the sender to wait for a longer period so it can see if the packet was delivered correctly. Once this happens, it will start go back to using a normal DIFS or AIFS .

Inter frame spacing gives us another mechanism to help avoid collisions in 802.11. It does this by having the Station wait a given amount of time (IFS) according to the type frame being sent.  We do this by utilizing Carrier sense, random back off timer, IFS and contention windows.

802.11 Spectrum Analysis – useful graphs

Spectrum analysis in 802.11 design is extremely important. Detecting which channels are in use in 2.4 and 5 gig spectrum’s as well as the channel density is a great help when channel planning or troubleshooting wifi issues. There are lots of graphs within any spectrum analyzing software.  Below are a few that I feel really help narrow down issues within spectrum.

FFT Graphs

FFT stands for Fast Fourier Transform – Which is an algorithm that samples signals over a period of time. One of the most usable graphs when looking at the spectrum is the FFT density graph and the real time FFT graph. I am currently using Fluke’s or now NetScouts SpectrumXT.

The below images shows the FFT of our office. As you can easily see just from the FFT graphs that channel 124 and 128 is heavily in use. This is because of a few reason – 1 we are using 40 MHZ channels so channel 124 and 128 are combined.  2 – the AP using these channels are the closest to me, the other APs are pretty far away.

fft-density

So why is this important during a survey or just checking to see whats going on – its important because it shows the amount of energy used on those channels. An abundance of energy will cause slowness and clients to defer sending as well as packet loss. Understanding and viewing spectrum is also extremely important in channel selection and design.

So lets compare the above with the Real time FFT – the Real time graph changes as the name states very often. But the Density and Real Time should be pretty similar. For channel planning purposes you can easily recognize that channels 124 through 136 should not be used. Lots of channels are open and can be used in this range that will not cause any interference.

FFT

 

Spectrogram

The next graph is the famous Spectrogram. The Spectrogram graph shows the amplitude of a signal over time. Basically it shows how busy and strong the signals are on that channel. These are also know as sweep or waterfall graphs. This graph shows how much signal density is on that channel. For example, if you have a channel maybe 104 that has traffic on it (seen by FFT), but its usage is very low (Spectrogram) then we know that that channel even though used would have very low interference, where as Channel 124 has lots of traffic and usage.

In the following graph the darker color shows more usage, notice Channel 124 which my STA is on.

Spectrogram.

The following graph shows the spectrum after my station starts downloading a huge file on WIFI. Check out the difference in usage.

spec-after-download

 

There are a lot of spectrum analysis graphs some are very helpful. These are two graphs that I find that help a lot to pinpoint the usage and channel use/layout of a wireless network. There are many more helpful graphs such as the wifi integrated graphs that can collect retries, Channel SNR, etc.

Cisco ISR 4000 Bridge group with Vlans

The 4000 series does things a little differently with Bridge groups then older ISRs. The below is on a Cisco ISR 4331. In this case I needed to have a bridge group to go to two separate switches, one port would be blocked by spanning tree to keep loops out.

a Bridge-group,  Groups the physical interfaces into one logical group. and the Bridge Virtual Interface (BVI) is the layer 3 routing interface associated to that bridge group.

In this scenario I have two vlans 4006 and 4007, I will create a bridge group so basically the two ports of the bridge group are a switch. Spanning tree will pass through the bridge group and one of my ports will be blocked. The reason for the bridge group if that I have two Distro switches and I want to have switch redundancy (Yes, I know the router is still a single point of failure). If one of my core switches die, it should be only a few seconds and I will be back up and going at Layer2 to my core. In this scenario I have a reason to not use ECMP or routing on the router interconnects – I need to keep them at layer 2.

overview

Config:

bridge-domain 4006
bridge-domain 4007

interface GigabitEthernet0/0/0

description **Connected to Primary Core**
no ip address
negotiation auto
service instance 1 ethernet
encapsulation untagged
bridge-domain 1
!
service instance 4006 ethernet
encapsulation dot1q 4006
rewrite ingress tag pop 1 symmetric
bridge-domain 4006
!
service instance 4007 ethernet
encapsulation dot1q 4007
rewrite ingress tag pop 1 symmetric
bridge-domain 4007
!

int gig 0/0/2

description **Connected to Primary Core2**
no ip address
negotiation auto
service instance 1 ethernet
encapsulation untagged
bridge-domain 1
!
service instance 4006 ethernet
encapsulation dot1q 4006
rewrite ingress tag pop 1 symmetric
bridge-domain 4006
!
service instance 4007 ethernet
encapsulation dot1q 4007
rewrite ingress tag pop 1 symmetric
bridge-domain 4007
!
!

interface BDI1
no ip address
shutdown
!
interface BDI4006
ip address 1.1.1.1 255.255.255.0
!
interface BDI4007
ip address 2.2.2.1 255.255.255.0
no ip redirects

!

Thats, it. The Vlan and vlan interfaces are up and working. When I check spanning-tree on the switch I see the correct one blocked – which could totally be load balanced or modified.

 

 

Fortigate SSL VPN issues – Forticlient

Recently I had an issue with a SSL VPN user who could not connect to the Fortigate. This problem started after upgrading the Fortigate from a very old 5.2.3 to the latest 5.4 firmware – 5.4.7.

Everything went great with the upgrade,but the client would bomb out at 40 percent with “VPN server maybe unreachable” when attempting to connect. After some diagnostics on the firewall I found the user could authenticate, and reach the FW. I then debugged the SSL VPN application and found that the following logs appeared. Note – I changed the IP from the real to 1.1.1.1

[16143:root:2e2e] SSL state:before/accept initialization (1.1.1.1)
[16143:root:2e2e] SSL state:SSLv2/v3 read client hello A:(null) (1.1.1.1)
[16143:root:2e2e] SSL_accept failed, 1:unknown protocol

Unknown protocol .. hmmm. After some digging I found that before the upgrade the following protocols were allowed in the SSL-VPN settings in CLI.

Fortigate $ get vpn ssl settings
reqclientcert : disable
sslv2 : disable
sslv3 : disable
tlsv1-0 : enable
tlsv1-1 : enable
tlsv1-2 : enable
ssl-big-buffer : disable
ssl-insert-empty-fragment: enable

After the upgrade here are the settings

Fortigate $ get vpn ssl settings
reqclientcert : disable
sslv3 : disable
tlsv1-0 : disable
tlsv1-1 : enable
tlsv1-2 : enable
ssl-big-buffer : disable
ssl-insert-empty-fragment: enable

Notice that TSLV1-0 is disabled – this great for security as TLS 1 and 2 are much more secure than 0, but in this case the client was not trying to use 1-2 but only 0.

RESOLUTION

So the Forticlient is using the security settings within Internet Explorer. The fix was to make sure that IE supported the necessary protocols. On the client that was not working I opened up IE – went to settings, then to advanced. Check the settings out –

Protocol

I enabled TLS 1.2 (you could also do 1.1) and and tried to reconnect – all worked great. Check out the debug after enabling:

 

[16143:root:2e39]SSL state:SSLv3 read client hello A (1.1.1.1)
[16143:root:2e39]SSL state:SSLv3 write server hello A (1.1.1.1))
[16143:root:2e39]SSL state:SSLv3 write certificate A (1.1.1.1))
[16143:root:2e39]SSL state:SSLv3 write key exchange A (1.1.1.1))
[16143:root:2e39]SSL state:SSLv3 write server done A (1.1.1.1))
[16143:root:2e39]SSL state:SSLv3 flush data (1.1.1.1))
[16143:root:2e39]SSL state:SSL negotiation finished successfully (1.1.1.1)
[16143:root:2e39]SSL established: TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384

Clearing sessions in FortiOS

Fortigate firewalls are stateful by design, this means that when a client behind the firewall talks to lets say Google a session is created – If all security policies are met.  Google’s return traffic can automatically come back into the client, following the same path (Session) without having to explicitly have an access rule that allows that traffic.  This is also very beneficial in security because the firewall keeps track of that session, makes sure all traffic is flowing on the session as it should, and will close the session if needed. When the session is closed Google cannot talk to our internal host anymore without following very specific rules that would allow communication from them.

With remote APs, Video streams, any many more (Specifically UDP streams) I see problems a lot with sessions getting created on the WAN (Default route) for RFC-1918 private subnets. When this happens internal clients – Maybe APs – cannot talk back to the controller or the UDP video encoder cannot find the decoder any more, but other clients can communicate with those devices just fine.

The reason this happens is that most of the time the IPSEC VPN tunnels or MPLS/E-LAN interfaces have static route assigned to them for getting to the other side subnets. If the physical interface or VPN interface drops then what routes exist in the routing table? Thats right – just the default which in turn sends all traffic even for private subnets out to the internet.  Lets take a UDP video Stream  between two locations for example -UDP never needs an acknowledgement of the traffic, so it keeps blasting traffic to the session – when the session gets created to the internet

When those interfaces or tunnels come back online all should work, and will unless traffic never stops flowing, which is where our problem lies.  When traffic tries to flow when all interface routes are down, then the only route left is the default – so the session gets created on the WAN interface.

To clear these sessions and fix the issues there are a few options.

1 – clear all sessions of the firewall

2 – create session filter and only clear the sessions you need to .

There are many other reasons to clear sessions than the reason I mentioned above.  So lets get to commands!

First you can show sessions on the firewall by using:

options1.JPG

Status will show you how many active sessions you have on the firewall and List will print out the individual sessions.

When you select list you get the following information

list1

So for this example lets check out the session created from my internal host 10.3.0.1 going to 104.197.225.108 (www.mirazon.com).

list 2

So we see that just by going to http://www.mirazon.com it opened 6 session, these are all going to the same destination IP/Port but coming from different source ports. Option 1 was we could clear all sessions from the firewall – the command to do that is:

diag system session clear

In this example, lets say I want to clear only sessions going to IP 104.197.225.108. We need to create a session filter and then clear only those. Here are the following options on creating filters

filter-1

Lots of options – one of the coolest in my opinion is matching on Protocol! But in this case lets match by destination IP.

filter-clear

Thats it! now we have cleared all sessions going to that IP.

NOTES

A few things to note – The firewall will clear out a session  if it does not see a keepalive. It will do that every 3600 seconds by default – this means if a voice call is going on through the firewall then it might close the session after 3600 seconds – this can be a big problem. The “dia system session list” is a great way to find a session and see when it will expire. Great way to troubleshoot – you can also use the GREP keyword to help find exactly what you want.

 

 

 

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