Sometimes it is necessary to change IP address used to talk with the internet that the internal client is using. For instance it is always important to make sure your SMTP server is using the same outbound IP used for inbound traffic. I have seen this cause a good many mail servers to be blacklisted by ISPs. In the following entry we will change the IP the client is using for outbound nat.

This technique has many awesome benefits, you can nat into this IP (IP pool) only when going to a certain destination.. etc. For example, if you had to change your source IP when accessing a destination across a VPN tunnel. That example might be very important in a medical field where I have found you almost always have to nat your private traffic to a public address when accessing the VPN hosts.

The internal client address is 10.64.16.10, external IP is 1.1.1.1. In this example I only want this one internal client to be natted out of 1.1.1.1

So we have to create a Virtual IP pool . We create the Virtual IP pool by going to Policy and objects – objects – IP Pools

We then can setup the pool. Notice the options

– Overload allows PAT, so many ip addresses, to one public.
– One-to-One allows one IP to that public IP
– We also have the option to nat into a Public Range of addresses

We also want this device to answer VIA Arp for 1.1.1.1

Now lets create our IPv4 Policy to allow our private IP address to be allowed to the internet (WAN1) and to be natted VIA this IP pool. I created the address object for my private host already.

So after creating our IPV4 policy, we have one thing left to do – make sure this is one of our first policies hit when 10.16.64.10 tries to access the internet. So lets make sure its at the top of our list, or at least above our default nat rule.

That’s it! if you now go to a site such as ipchicken.com or whatismyip.com you will see 1.1.1.1 if you are coming from 10.16.64.10.

A GRE (Genereic Routing Encapsulation) is a tunneling protocol that allows data to be encapsulated and sent over a simulated point-to-point link. The beauty of it is that it will encapsulate many different types of traffic and De-encapsulate it on the other. This basically means any traffic sent to the tunnel interface will be stuffed it in a envelope and sent to the remote gateway, removed from the envelope,  and forwarded normally. The network which the traffic is being routed across  only sees GRE and not the individual IP header. A GRE tunnel can be used with or without IPSEC for encryption. This blog entry creates a tunnel WITHOUT IPSEC.

This is not only a one of the only ways to get Routing updates/traffic such as OSPF across a IPSEC VPN, but also is a wonderful troubleshooting option.I have seen this be a great troubleshooting tool when an MPLS might be blocking traffic.

Recently I have utilized a GRE tunnel  to tunnel all multicast traffic across a MPLS network that does not support multicast. By tunneling all the Mulicast data, the MPLS only saw GRE packets and the multicast streams worked great.

In this post I will demonstrate how to create a GRE tunnel between two Fortigate firewalls. Traffic will then be encapsulated from the source and de-encapsulated and forwarded normally on the remote end point. Most of the GRE configuration within the Fortigate is CLI only and not something that can be configured in the GUI.

Steps needed

• Create System GRE tunnel, Assign local and remote gateways (WAN IPs)
• Modify system interface GRE settings and assign local/remote tunnel IPs (Tunnel IPs)
• Create Firewall policies to allow traffic
• Create routes to remote side of the tunnel , and select GRE tunnel as destination interface
• Test

The process is relatively straight forward and simple. First we need to create our GRE tunnel. The two sites we will be creating the tunnel on are Site-A, and Site-B.

Here is an overview of the network

Site A

CLI commandsconfig system gre-tunnel
edit “GRE-to-SITEB”
set interface “WAN1”
set remote-gw 2.2.2.1    — Remote firewall WAN IP
set local-gw 1.1.1.1          — Local FW WAN1 IP
next
end

config system interface
edit “GRE-to-SiteB”
set vdom “root”
set ip 192.168.254.1 255.255.255.255    — Local Tunnel IP
set allowaccess ping
set type tunnel
set remote-ip 192.168.254.2                  — Remote Tunnel Endpoint IP
set snmp-index 65
set interface “WAN1”
next
end

Route Creation

Now we can create the static route pointing my remote traffic (10.2.2.0/24) through the GRE-to-SiteB GRE tunnel.

Firewall Policy creation

Next we need to create the Firewall policies allowing traffic from the GRE-Tunnel and to the GRE-Tunnel from the LAN interface or whichever interface your traffic originates on.

SITE B

GRE Tunnel creation

config system gre-tunnel
edit “GRE-to-SITEA”
set interface “wan1”
set remote-gw 2.2.2.1
set local-gw 1.1.1.1
next
end

config system interface
edit “GRE-to-SITEA”
set vdom “root”
set ip 192.168.254.2 255.255.255.255
set allowaccess ping
set type tunnel
set remote-ip 192.168.254.1
set snmp-index 8
set interface “wan1”
next
end

Route Creation

Now we can create the static route pointing my remote traffic (10.1.1.0/24) through the GRE-to-SiteA GRE tunnel.

Firewall Policy creation

Next we need to create the Firewall policies allowing traffic from the GRE-Tunnel and to the GRE-Tunnel from the LAN interface or whichever interface your traffic originates on.

That should be it.

Now lets see if we can ping across our tunnel. As shown below pings work great! Pinging both the tunnel interface and across the tunnel are great ways to check if this tunnel is actually working. Odds are if you have enabled ping on the tunnel interface, and cannot ping it from the other side then the tunnel is not working. Also, check the Firewall policy count to make sure it is increasing with traffic – if so everything is working .

Thanks!

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.

Fortigate has done a great job with the 5.4 firmware. Its a big change from 5.2 but once you get going with it, you will find things are structured very well. For example the “Monitor” category is a great way to get everything you need, instead of going through each individual category.

One feature of 5.4 that really “Grinds my gears” is the named policy feature. The feature itself is awesome, great way to put in a name on a policy such as “Students to internet”.. etc.  But, they make it mandatory to put in a name by default. What’s so aggregating about this is that if you upgrade to 5.4 from 5.2 all of your policies are unnamed, so when you modify one of those existing policies you HAVE to put in a name. The following will show how to turn that feature off, so it is not mandatory you put in a name. You still can, just don’t have to.

Below you will see what happens when you try to create that policy , and the the feature has not been disabled. You get the “This field is required.” error. It will not let you create or modify the policy until that is filled in.

To disable this feature, go to system-Feature select- then check “Allow unnamed policies”. Once you press Apply this will let you bypass the mandatory name feature.

I recently installed quite a few Brocade 6450 switches. Great switches by the way, easy to use, very full CLI, great hardware. Most of Brocades (given its a L3 switch) switches support both routing code and switching code. I mostly deploy the Routing code, just my preference. But, in this scenario the 6450 was being deployed for a very small classroom, and no need to setup the routing interface, etc. so the instructions are for a switch running Switching code – you can check VIA show version command.

In this case we have a very specific vlan for management of networking gear, so I need the IP/GW to be on the vlan – in this case vlan 255. Below is how

Lets first create the vlan in CLI:

config t

vlan 255 name MGMT
 tagged ethe 1/2/1   (My uplink port)
 management-vlan
 ip address 10.44.255.100 255.255.255.0
 default-gateway  10.44.255.1 1

Lets run over a few things here.

• First the vlan has to be tagged on a port, or untagged to actually show up in the config. Here I am tagging my uplink port 1/2/1
• The management-vlan command has to be used on the Vlan you want for management, otherwise its the default vlan setup in the switch which by default is 1.
• the default gateway commands needs the metric of the IP at the end. You can specify a value from 1 – 5. There is no default. The software uses the gateway with the lowest metric.

Recently we were troubleshooting some network issues with a Cisco 1242  AP that suddenly stopped communicating with our WLC.

Controller firmware is 8.0.133

We consoled into the AP and found logs that looked like below. Then we logged into the WLC and saw similar logs.

*spamApTask0:  %LWAPP-3-PAYLOAD_MISSING: spam_lrad.c:6433  Join request does not contain BOARD_DATA payload
*spamApTask5:  %CAPWAP-3-DECODE_ERR: capwap_ac_sm.c:4702 Error decoding Join request from AP 00:26:0b:10:34:70
*spamApTask6:  %DTLS-3-HANDSHAKE_FAILURE: openssl_dtls.c:844 Failed to complete DTLS handshake with peer 10.192.112.241
*spamApTask2:  %DTLS-3-HANDSHAKE_FAILURE: openssl_dtls.c:844 Failed to complete DTLS handshake with peer 10.10.91.20
*spamApTask6:  %CAPWAP-3-DECODE_ERR: capwap_ac_sm.c:4702 Error decoding Join request from AP 00:26:0b:10:34:70
*spamApTask5:  %DTLS-3-HANDSHAKE_FAILURE: openssl_dtls.c:844 Failed to complete DTLS handshake with peer 10.10.75.23
*spamApTask0:  %LWAPP-3-DECODE_ERR: spam_lrad.c:2364 Error decoding join request from AP 00:19:aa:35:10:88
*spamApTask0:  %LWAPP-3-KEY_ERR3: spam_crypto.c:1630 The system is unable to free public key for AP 00:19:aa:35:10:88
*spamApTask0:  %LWAPP-3-PAYLOAD_ERR: spam_lrad.c:7931 Join request does not contain valid certificate in certificate payload – AP 00:19:aa:35:10:88

Seems the AP cert had expired. To get around this we had to enable a command in the WLC that ignored the AP cert. The happened because the Manufacturer Installed Certificate (MIC) has now become older than ten years and has expired. This will not be accepted now.

I SSH’d into the controller and ran the below command:

config ap cert-expiry-ignore mic enable

This allowed the AP to come back online immediately.

As always docs.fortinet.com has the best information.

Firewalls almost always interface with the internet, and most of the time we enable remote access from the internet to make our lives easier when troubleshooting an issue, and maybe not being behind the firewall at the time. The best why to secure the device is just not enable access from insecure locations, but some times we have to enable it.

There are a few simple things we can do to help elevate vulnerable spots when allowing access from the internet.

• Enable a password policy
• Modify lockout policy/duration if needed
• Allow admin access from only Trusted hosts
• Modify default access ports
• Create a new admin account named something different, and then delete the default admin account.
• Make sure a log in banner is active – Certain cyber laws need explicit notification that the user attempting login should have authorization.
• Use dual factor authentication to gain admin access to the device.
• Logging , always logging!

This blog is written with both 5.2 and 5.4 firmwares.

Enabling a password policy

This is great to do if you have multiple accounts on the device. This way a user cannot change their super complex password to something with 3-4 letters. A password policy enforces certain specifics to the password. For example you can set the character requirements as well as password reuse/expiration. Check out the below images for 5.2 and 5.4. Notice you can enable this for VPN accounts and admin accounts.

5.4

5.2

Login failure lockout duration and Threshold

When you mistype your password 3 times by default you are locked out of the firewall for 5 minutes (All docs say 60 seconds though). This is a great defense against applications that attempts to brute for the firewall user/pass. Increasing the time the user is locked out can be a good idea to keep the bad guys from knocking, but could also really put a damper in your day if you lock yourself out for X amount of time.

But the commands to lower or increase it are the same in both firmware’s:

config sys global

set admin-lockout-duration X (seconds)

end

To increase the threshold (how many incorrect login attempts you can have)

config sys global

set admin-lockout-threshold (1-10 attempts)

end

Only allow logins from Trusted hosts

Why allow logins from anywhere on the internet, when you know if you logged in it would come from only a few sources.

5.4

Under the administrators options, you can select the trusted hosts (IP networks) that can login with the Mirazon account in this case. You could also modify the default admin account.

 5.2

Change default port numbers used for logins

I was in a debate one time about the security of changing default port numbers, and a friend said “Changing your login port numbers is as secure as hiding your keys under the front door mat.” He was most certainly correct, but security by obscurity is better than nothing. By changing the default port numbers from 443,80 some bots that try to log in will not find the open login due to different ports that are not in its scanning script.

In the following examples I am changing the default port of 443 to 8081.

5.4

5.2

Summary

In summary there are tons of things to do to increase device security. One of the most important, if you don’t need to allow remote logins to the device, why even enable it? Disable the login options under the interface. I believe the best practice is to have an out of band management PC that might connect directly into the MGMT port. To access the FW you have to access this machine.

Changing Port numbers and implementing the other options are great ways to help reduce login failure attempts, or unauthorized access. Another great option, not explained here is using dual factor authentication. By default you get two licenses for two factor – why not use it for admin access!

The importance of logging is one thing that cannot be underestimated. When logging is enabled you know exactly what happened – if someone tried to log in, from where, what username, and if they failed or were successful.

These were just a few of the many ways to increase device security.

Link to login banner blog: https://www.mirazon.com/how-to-implement-a-fortigate-login-banner/

This is an ongoing blog, and one that I will update often will things that come up in security audits.

Companies are always getting external audits to make sure they comply with policies and have no outstanding vulnerabilities with their systems. This is great, but sometime the Fortigate will get pinged on SSL/SSH encryption level issues. The following blog is a few helpful commands that can get the Fortinet to pass inspection by disabling the lowest or least secure SSL and SSH protocols. Also below I have put in excerpts from a few scans.

Issue 1:

Error: TLS Version 1 Protocol Detection – So the above was an issue with TLS Version 1.0 being enabled on port 443 (My SSL VPN port). So, we need to remove TLS 1.0 from the accepted protocols on the VPN.

The commands to do that are:

config vpn ssl settings
    set tlsv1-1 disable
end

The disables TLSv1 from the SSL VPN

Next issue

• Vulnerability Details 116818

This host is susceptible to the SSL version 3 POODLE (Padding Oracle On Downgraded Legacy Encryption) attack. By using SSL version 3 and CBC Mode ciphers this host can allow an attacker to expose encrypted data in a connection between the client and server. Impact: Over time, an attacker can steal sensitive information between the client and the server using this man in the middle attack. Hosts may default to a more secure protocol (TLS 1.2, for example), but a network attacker could potentially trigger a reconnection causing the browser to retry older protocols (SSL version 3).

The above error basically says that SSL Version 3 was enabled on SSL VPN port. Just like before we will disable that

config vpn ssl settings
    set sslv3 disable
set tlsv1-0 disable
set tlsv1-1 disable
end

This turns of SSLV3 from the SSL VPN supported protocols.

This Entry will be updated as I find more from going through audits.

I decided to write up the steps so I could always refer back to this if I get hit in the head really hard and forget, which is very likely to happen. Remember to always read the release notes of the firmware you are installing.

In this case I have Cisco ASA 5505 running newer 9.X firmware, and just want both the ASA and ASDM images to be the latest suggested. In this scenario I am using TFTP64 to copy the files over but if I had a Flash drive handy I would have went that route.

First I downloaded the newest images from Cisco, both for the ASDM and the ASA firmware.

Then I moved those over to my TFTP server directory. On the ASA I will run these commands to copy the files to flash, then set options to boot to those images.

VIP-ASA# copy tftp flash
Address or name of remote host: 192.168.19.10
Source filename: asa917-12-k8.bin
Destination filename:asa917-12-k8.bin

Accessing tftp://192.168.19.10/asa917-12-k8.bin…!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!                                                                           !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
26709020 bytes copied in 33.860 secs (809364 bytes/sec)

Now to copy over the ASDM image

VIP-ASA# copy tftp: flash
Address or name of remote host: 192.168.19.10
Source filename: asdm-771.bin
Destination filename: asdm-771.bin
Accessing tftp://192.168.19.10/asdm-771.bin…!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
26709020 bytes copied in 33.860 secs (809364 bytes/sec)

Great, our images are on the flash, now we need to set our boot variables.

VIP-ASA(config)# boot system flash:/asa917-12-k8.bin
INFO: Converting flash:/asa917-12-k8.bin to disk0:/asa917-12-k8.bin

Remove the old boot variable

VIP-ASA# show boot

BOOT variable = disk0:/asa917-12-k8.bin
Current BOOT variable = disk0:/asa917-12-k8.bin;disk0:/asa821-k8.bin
CONFIG_FILE variable =
Current CONFIG_FILE variable =
VIP-ASA# config t
VIP-ASA(config)# no boot system disk0:/asa821-k8.bin
VIP-ASA(config)# show boot

BOOT variable = disk0:/asa917-12-k8.bin
Current BOOT variable = disk0:/asa917-12-k8.bin
CONFIG_FILE variable =
Current CONFIG_FILE variable =
VIP-ASA(config)#

Set your ASDM image to the new one, and then check your ASDM boot image

config t
VIP-ASA(config)# asdm image disk0:/asdm-771.bin

VIP-ASA# show asdm image
Device Manager image file, disk0:/asdm-771.bin

Now save config, and reboot – That’s it!  Reading the release notes is super important to know what has changed, and if there is a certain firmware you need to be at before upgrading. In this example I upgraded to 9.1.7 and ASDM 7.7.1. If you were upgrading VIA USB it is basically the same config, except replace tftp with usb.

Recently I created a tunnel for a client between two Cisco ASAs, and they monitor VIA PRTG and make automated backups via Solarwinds. After the tunnel creation, all traffic worked great except traffic (SSH,SNMP,PING) directed to the device’s inside interface. There are a few simple command that fix this. In this entry I will point out those commands and explain why the commands actually fix the issue.

So the above images shows a simple layout of what I have going on. All is working with the VPN, its up and functioning everything is great accept access to the ASA itself from the remote subnet. The ASA in question is 192.168.19.1/24.

There are really two commands here. First:

Management access <Inside interface>

As Cisco States it:

“If your VPN tunnel terminates on one interface, but you want to manage the ASA by accessing a different interface, you can identify that interface as a management-access interface. For example, if you enter the ASA from the outside interface, this feature lets you connect to the inside interface using ASDM, SSH, Telnet, or SNMP; or you can ping the inside interface when entering from the outside interface”.

Awesome, so that allows us to actually use the inside for management when connecting through a different interface (VPN). For me this did not work, still could not access the device from the remote subnet.

The next command that resolved the issue for me had to do with my nat statement. The firmware version of this device is 9.x, so we use object based nat to do our NO-NAT statements.

nat (inside,outside) source static LOCAL-NETWORKS LOCAL-NETWORKS destination static 10.0.0.0/24 10.0.0.0/24 route-lookup

to note, local networks is a group that has my 192.168.19.0/24 subnet in it.

The route-lookup command on top of the NO-NAT resolve the issue. The reason being is that when packets are sent to a destination the device looks for the needed egress interface or in this case the interface specified in our NAT rule which is “outside”.  This makes a lot of sense. But, we don’t want to send this traffic out of the WAN interface, we want to send it out of the tunnel. So specifying the command route-lookup tells the firewall to look at the routing table for the entry and then forward the packet accordingly, basically overriding the identity NAT statement interface (interface listed int the NO-NAT). According to Cisco the ASA looked at the routing table by default in older firmwares but to make this more flexible with NAT, now you have to specify the keyword.

That’s it all communication to your ASA should now work.

Within ZD we might need to enable LDAP look ups to facilitate in using Active Directory logins to the firewall for administration, or authentication for Guest pass creation/ZeroIT.

Recently I had to do this, and it had been a while, so I decided to write a short entry on it.

So in this case I am configuring LDAP for use with Guest pass so domain users have to sponsor guest wireless accounts.

Below shows the options for our Test-AD LDAP server. There are some key things here.

Notice in this case we are not using TLS.

The Base DN and admin DN are the location of the user who can perform lookups in AD. The best way to find this info is going to AD user/computers and under “View” enable “Advanced features” then go into the details of the user account- you will have a “attribute editor” tab. The User DN is located, if you double click that attribute you can copy it directly.

Next key attribute is “sAMAccountName” under key attribute – that attribute is really just the windows user login account name.

That’s it! I will do another entry on setting up guest pass where domain users can sponsor accounts.

Unsupress maps in Cisco can really be a very helpful tool in situations where you might be summarizing a bunch of /24s to maybe a /20, but you need to leak out one of the /24s without summarization, and still advertise the larger summary route.

By default, once you use summarize all networks that fall under your summary route do not advertise any more.  In my situation I was testing ECMP and needed to advertise one /24 to each of my MPLS neighbors, so my hub router could get back on either path. I couldn’t test this with the full /24 due to outage concerns so we had to do this for a /24 that was not used that often. I am not going to show the layout of the Dual MPLS , but just one.

Below shows the topology

Great, now for config on the Cisco Routers.

Steps:

• Created Prefix list of subnets I need to be unsupressed.
• Create a new route-map to match those subnets.
• Add the BGP statement referencing my neighbor with the “unsuppress-map” keyword.
• clear routes soft, to force a refresh.

My Prefix list name will be UMAP and my route-map will be named UMAP-MAP

So lets take a look at our advertised routes to my neighbor 10.0.5.22 before making the changes.

Notice that just the /20 is being advertised. Now check out the config below, and lets apply.

config t

ip prefix-list UMAP seq 5 permit 10.32.39.0/24

route-map UMAP-MAP permit 10
 match ip address prefix-list UMAP

router bgp 64551
neighbor 10.0.5.22 unsuppress-map UMAP-MAP

Then clear update BGP

clear ip bgp * soft

So that’s it for the config.  Lets look at the advertised routes now.

Great! we are advertising our /24 and everything is now working perfectly. Unsuppress maps to the rescue!

The other day I needed to use the the blue mini-USB console cable that Cisco will now send. Its been around a long time, but I always have my normal console laying around and just use that. When I attempted to use it I first installed the USB driver provided by Cisco, everything seemed to work, but I could not open the com port. Today I did some research and got it working – I was just missing a small part, but thought I would write up the steps to try and help someone else. My OS is Windows 10.

So first we have to install the USB driver this can be downloaded from Cisco.com , using your CCO account.  Then install according to the computer, and then reboot. The problem comes in after the reboot – Windows will use the Windows USB driver, and not the Cisco one. So you have to manually change it.

So to walk through, after the install/reboot I connected the cable – Went into device manager to see what com port it was associated to. Com3. Great, then I tried to console to that port – and it would not work.

So, after a lot of troubleshooting I found that you need to update the driver to a locally install one, and when you do that Cisco’s driver will pop up. Those steps are below.

So, lets first change the driver.

Select “update driver software”

Then Select “Let me pick from a list of device drivers on my computer”

Bam! Now, select the Cisco driver.

Now, we see that Cisco serial driver is in use.

So, now we should be able to launch Putty and change it to COM3 and it should work.

Thats it!

I had the need today to setup DHCP on a Brocade 7450 Switch. I had never done this before, but very straight forward. Thought I would document how to/options if anyone ever needs it.

DHCP pool to create – TX-POOL, scope 192.168.6.0/24

config t

ip dhcp-server pool TX-POOL
dhcp-default-router 192.168.6.1
dns-server 192.168.1.183
excluded-address 192.168.6.1 192.168.6.10
lease 1 0 0
network 192.168.6.0 255.255.255.0
deploy

Notice the “Deploy” option – this puts everything into motion. Lots more options available like Domain-name, Options, lease times, etc.

To make sure everything is working you have some great show commands:

The best docs are always at docs.fortinet.com

Fortigate traffic shaping is awesome, lots of options and it all works really well. Going from 5.2 to 5.4/5.6 is quite different due to the creation of policies changing from within the firewall policy, to their own section. Either way, they all work great.

I did notice at least in 5.4 that the option to change how a policy is used do not seem to be in the GUI. Previously there were two options – “Per Policy”, and “all policies using this shaper”. Selecting “all policies using this shaper” would have all policies using that shaper object to share the guaranteed or Max bandwidth settings between all policies using that shaper. Selecting “Per Policy” allows you to dedicate those same settings to each policy referencing the shaper object.

Which gets to my point, in 5.2 you had the options below. Notice the options about how to apply the shaper.

In 5.4.5 at least notice that they are gone. Of course, if you upgraded from 5.2 the options are there.

So as with everything that does not show up in the GUI – you know it is in CLI. So I dropped down to CLI to check if the settings are still there. By editing the shaper, and using the “get” command I could see all settings and their values the policy had to offer. As I thought the option “Per-Policy” is there with the default settings of disabled. So by default, all Shaper policies have  settings shared between different traffic policies referencing that shaper.

So in this case, I want to give the same percentage of bandwidth to each of the traffic shaper policies referencing my shaper object. So I will modify that option.

Now, in the GUI lets check that policy again –

Awesome, now we have the actual options to change.

SNTP is used to synchronize time from a switch (HP in this case) with any time server. SNTP is actually fully compatible with NTP so life is easy in that respect . SNTP is a scaled down version off NTP. There are a few difference between the protocols – some being simplicity in how the time is synchronized between server and client, and processing of server failures.

I had to configure SNTP on a few HP Procurves (2500, 3800, 2900, 2500)  of all makes and models today and thought it would be good to document/share. I was setting SNTP on the switch to synchronize time with an AD controller within the network for timestamps in logs, etc.

On the 2530 Code is as follows:

config t

sntp server priority 1 10.44.130.10  — Sets the server priority, and the server IP/NAME

sntp unicast — changes from Broadcast to Unicast.

timesync sntp — Sets timesync to use SNTP instead of NTP or other options.

• On some older HP firmwares/switches I found that the priority command was not avaliable.

After these changes you can check the time with the “show time” command, and dig deeper with “Show sntp” commands.

I’ve blogged on using the SSL VPN to renew passwords if they expire before using LDAPS, but I have not blogged on doing this through Radius authentication.

One awesome aspect of this is that by default, the max LDAP servers you can configure on a Fortigate is 10 – so if you have a lot of different domains – as I do with one client – you might be pushed to go to Fortiauthenticator for the ability to have more, or use dual factor. Using Radius to authenticate can help remedy this issue because you can authenticate as many domains as you like behind 1 radius server. You can also have that server allow users to change their password if it expires, or if you set the policy in AD to make the user change their password.

To authenticate many different groups through radius for the SSL VPN you have to configure a vendor specific option. I wrote an entry not long ago on how to do this found here – https://travelingpacket.com/2016/01/26/fortigate-radius-group-authentication/  That was written for 5.2 but same stuff applies to 5.4 and 5.6 .

Once NPS is setup, the Radius server is created on the FGT, User groups are created on the FGT and of course SSL VPN policies are good to – you can modify the server in CLI and set the options to allow passwords to be change if expired.

In this case my server is called Presrv04 –  The below is the setup for that server

Then we need to modify the options in CLI

Next I changed my account to force me to change my password at next login – check this out.

There we go! once I change my password to something that meets the complexity requirements of my organization it will allow me directly into the VPN – and change my password.

The Dell FX2 is a pretty awesome piece of hardware. I mostly only work on it from the networking side.

From the CMC you can console to each of your switch modules. I had a hard time finding documentation on the very simple command to do this. From doing a quick ? and scanning through each command I found “Connect” Pretty fast, and knew that would be it …. but connect to what?

I finally found from searching a different help command that you can do

Connect switch-1

or

connect switch-2

This will allow you to access each of your switches from the CMC. Check the below screenshot out.

Recently I had the need to show the MTU of an interface. By default, if there are no changes the MTU will be 1500. But in this case I needed to be able to show that the MTU was 1500.

Few commands I tried did not show the exact info I needed, for example- Get hardware nic port1 – showed lots of great info but not the MTU.

To get this info I needed to do an Ifconfig from the Fortigate. to do this I ran the command:

fnsysctl ifconfig -a port1     Port1 being the port I needed to get the info for. Check out the screenshot below. Lots of other great info such as dropped packets and MAC.

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== 05 – 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