Monthly Archives: October 2014

Fortigate 5.2+ SSL VPN Address

You can use a different IP address to answer for the SSL VPN.

Lets say that your interface IP (The default IP address that is used with the SSL VPN) already has HTTPS (443) forwarded in to a internal server, and you really want the SSL VPN port to be 443. You have an option.

You can add a secondary IP  address under the WAN interface that does not have a reservation already for 443. Then use this IP address for the SSL VPN.

To do so:

secondary-ip

Add your secondary IP address – Note this has to be a public address, given to you by your ISP..

Then go into the VPN settings and modify the port for what you want. Notice that the address it says will work is still the primary IP, even though the secondary will work just fine.

ssl-settings-second

Fortigate – How to create a default route with a dynamic connection.

Recently I needed to make sure select traffic would flow over a certain ISP link. Unfortunately that link had a dynamic address, which meant the address and gateway of that route could change anytime. Also I wanted to have my primary ISP failover to this link if needed.

To accomplish these things I needed to have both default routes in my routing table at the same time. This means that they both have the same distance, but different priorities. One way to accomplish this is to configure a static default route, and just change the priority of the link , but how can you do this when you do not know the gateway?

You can create a dynamic-gateway static route in the Fortigate.

dynamic-route

Through CLI you can create a dynamic gateway route using the above syntax.  Remember, the higher the priority the less preferable the route.

You can also create basically the same thing under the interface of the WAN link by using the distance, and priority interface commands listed below:

cin-interface

So now if we check our route monitor:

cin-routes

We have both default routes, and can successfully use a policy based route to push the needed traffic out.

How to get Fortigate interface statistics such as errors/discards

There are two really good ways to pull errors/discards and speed/duplex status on FGT. One method is running the CLI command:

diag hardware deviceinfo nic X – Where X would be the port, for example wan1

Results:

Glass-B # dia hardware deviceinfo nic wan1
Description :FortiASIC NP6LITE Adapter
Driver Name :FortiASIC NP6LITE Driver
Board :100EF
lif id :2
lif oid :66
netdev oid :66
Current_HWaddr 00:09:0f:09:00:15
Permanent_HWaddr 70:4c:a5:1c:97:ee

========== Link Status ==========

Admin :up
netdev status :up
autonego_setting:1
link_setting :1
speed_setting :10
duplex_setting :0
Speed :1000
Duplex :Full
link_status :Up

============ Counters ===========

Rx Pkts :10168446
Rx Bytes :11555061952
Tx Pkts :7135911
Tx Bytes :1372048635
Host Rx Pkts :9869349
Host Rx Bytes :11069429016
Host Tx Pkts :6928881
Host Tx Bytes :1304248922
Host Tx dropped :0

On 1500D’s and other large devices the command is a little different. See the bottom.

on 1500D’s it seems the command changes a little bit to : “diag hardware nic port40“— this was the results from a 1500D that is running 10 gig. The output is at the bottom.

Second way

I started doing some research and found that there was a command that would drop you down to a very limited Linux shell. There are a few commands that are support such as “ifconfig”. This blew me away. I have been wondering if there was a command like this for a long time.

Log in through CLI, and run ” fnsysctl <command>” for example “fnsysctl ls”.

So to get the interface stats, I would just run: “fnsysctl ifconfig port16” or whatever port you want to look at.

fnsysctl

And there we go. I have search for some other ways to get this, and have not found anything. If someone finds something better please pass it along.

 

Output from 1500D

FGT# get hardware nic port40
Description :FortiASIC NP6 Adapter
Driver Name :FortiASIC Unified NPU Driver
Name :np6_1
PCI Slot :0000:0d:00.0
irq :40
Board :FGT1500D
SN :FG1K5D3I15800578
Major ID :3
Minor ID :0
lif id :19
lif oid :171
netdev oid :171
netdev flags :1303
Current_HWaddr 00:09:0f:09:00:24
Permanent_HWaddr 08:5b:0e:e3:45:1f
phy name :port40
bank_id :3
phy_addr :0x1f
lane :3
flags :804006
sw_port :8
sw_np_port :12
vid_phy[6] :[0x7f][0x29][0x00][0x00][0x00][0x00]
vid_fwd[6] :[0x7e][0x00][0x00][0x00][0x00][0x00]
oid_fwd[6] :[0xd9][0x00][0x00][0x00][0x00][0x00]
========== Link Status ==========
Admin :up
netdev status :up
autonego_setting:0
link_setting :1
link_speed :10000
link_duplex :1
Speed :10000
Duplex :Full
link_status :Up
rx_link_status :0
int_phy_link :0
local_fault :0
local_warning :0
remote_fault :0
============ Counters ===========
rx_error :0
rx_crc_error :0
rx_carrier :0
rx_oversize :0
rx_undersize :0
tx_collision :0
Rx Pkts :109497620
Rx Bytes :150634406914
Tx Pkts :74293345
Tx Bytes :42164760114
Host Rx Pkts :30734166
Host Rx Bytes :38611688664
Host Rx dropped :0
Host Tx Pkts :41309687
Host Tx Bytes :20219939267
Host Tx dropped :46
sw_rx_pkts :109497628
sw_rx_bytes :150634408123
sw_tx_pkts :74293361
sw_tx_bytes :42164761592
sw_rx_mc_pkts :301
sw_rx_bc_pkts :970
sw_in_drop_pkts :0
sw_out_drop_pkts:0
sw_np_rx_pkts :92470644
sw_np_rx_bytes :80482907648
sw_np_tx_pkts :143654631
sw_np_tx_bytes :183360431151
sw_np_rx_mc_pkts:136
sw_np_rx_bc_pkts:502
sw_np_in_drop_pkts:5708
sw_np_out_drop_pkts:0

 

Ruckus wireless – Stuck in provisioning

Sometimes when we deploy Ruckus APs remotley over a VPN, they will come up in the Zondirector but will stay on provisioning. then reboot after a bit, and then come back in as provisioning. The reason this happens is that the extra overhead of the added IPSEC header

The cause is the MTU on the Ruckus ZD. Sometime you will have to lower this due to the overhead added to the packet with the IPSEC tunnel.

To lower the MTU of the ZD (First step in troubleshooting APs across a VPN) is to go to configure – APs – and towards the bottom of the page you will see the MTU setting. I would lower this all the way for testing – Lower to 850 or 900. After lowing give the APs 5 minutes to show up in the ZD.

Capture

Vyatta out of space?

Today I had a vyatta that has limited HD space and could not  bring up VPN tunnels due to the lack of space. The below command is what I used to find the largest folder on the Vyatta file system :

find / -type f -size +20M -exec ls -lh {} \; 2> /dev/null | awk '{ print $NF ": " $5 }' | sort -nk 2,2

The command above searches the whole file system and reports back files larger than 20M.

I found that my wireshark folder had a lot of old captures. I navigated to the folder and removed all old captures and that freed up the missing space.