Monday, June 28, 2010

FortiAP - First Review

Review by Ben Boysza

I’ve just received the long-awaited and much overdue Fortinet dedicated Access-Point, dubbed the FortiAP 220A. Though Fortinet has had WiFi capable devices in the past, they have always fallen short when it came to a wireless cloud solution – actually, they’ve had none. I’ve been using Cisco Aironet products for years with success, despite the usual non-ergonomic configuration options of both the CLI and GUI. But they work, most of the time – and they offer me features that frankly our beloved FortiWifi’s could not.
And this market is getting more and more crowded, with priced-to-sell solutions from Meraki and Ruckus competing for your building-wide wireless needs. This has certainly been an area where Fortinet has fallen behind, way behind. One FortiWifi device is just not enough. And paying for additional FortiWifi 50B UTMs to use solely as Access Points just did not make sense, even though they can be powered conveniently by PoE.


With the introduction of FortiOS 4.0, we’ve been teased with a new menu option labeled Wireless Controller. Even without the new hardware, we’ve been able to create Virtual Access-Points (VAPs) and get an idea of how this new FortiWifi Cloud solution was going to work and be managed. Embedding a Wireless Controller into an existing Firewall or UTM is pure convenience and efficiency. Though the FortiAP 220A is not officially supported until FortiOS 4.2 (rumored), they are being distributed. However, even though we are seeing the Wireless Controller option on our existing installations of FortiOS 4.0, a special branch version of FortiOS is required. From the release notes:

The FortiAP device must be supported by a special FortiOS branch image for FortiGate model 60B and above, excluding any FortiWiFi models.
The officially released image of FortiOS to support the FortiAP device is based off of FortiOS v4.0 MR2 – fg_4_thin_ap_openssl/build_tag_6322.


You can find the special version on the Fortinet FTP site under the FortiAP directory


Now that I’ve had a few hours with this new line, here’s what I’ve found:

  • No PoE support. WHAT? It’s an AP with no option for PoE. Though, Fortinet does say you can use the Linksys WAPPOE12 adapter with the 220A power supply.
  • No SSID->VLAN Interface bridging. Still, an enormous thorn in my side. Though, the pain is dulled when you realize now that you can implement a true cloud solution consisting of many FortiAPs and have roaming clients, you will just dedicate a wireless network. But bridging is still required or preferred by some installations.
  • Doesn’t run FortiOS. Well, that’s fine and was expected – it’s a completely new piece of hardware running BusyBox. You can shell in and browse the directory structure as well as manually update network settings (even cat cpuinfo to see it is running an Atheros AR7100 MIPS 24k)
  • Telnet disabled when Registered. When the AP is discovered by your WC, and you set Admin level to Enabled, you can no longer Telnet to the AP. Security feature; you’re already managing the device from a WC at this point, and there are remote execute options from the WC CLI.
  • Has 4 “Do not use these ports” Ethernet Ports. That’s right, of the 5 ports, 4 are 100Mbps Ethernet ports that are apparently not for use. This really leads us to believe that the hardware used is off-the-shelf and not engineered from scratch by or for Fortinet.
  • Reset Button. The first Fortinet device to have a Factory Reset button. Reset it and then re-discover the AP on your Wireless Controller and away you go. This again indicates the use of generic appliance hardware (which, don’t get me wrong, is NOT new to Fortinet)
  • Limited WEP SSIDs. You are limited to no more than 4 WEP-Enabled SSIDs; WEP is supported only as a ‘legacy feature’. WEP has long been “de-secured”, and shouldn’t be anywhere near a Corporate or Enterprise environment anyway. If you’re running WEP, use this as a ‘goose’ to migrate to WPA.
  • Useless Button. There is a button in the center of the housing on the front of the AP that has apparently no function.
  • Dual Radios. Great support for all the bands, including N and G. Like others, you can assign your SSIDs to specific radios/bands using Access Point Profiles. These profiles are then applied to the physical Access Point registrations. This is nice and will really help flexibility in larger implementations.
  • Limited Documentation. Actually, besides the Quick Start guide there isn’t much. Since it’s managed by a FortiGate (FortiWifi models cannot be Wireless Controllers), you’ll find most of the necessary information in the FortiOS 4.0 Administration Guides.
  • Manual or Automatic Firmware Upgrade. When the AP is not ‘Enabled’ by the WC, you can telnet in and manually TFTP in new firmware. Better yet, upgrading the WC’s firmware will update the AP’s firmware if necessary as long as the AP is ‘Enabled’ by the WC.
Overall, I’m still excited, though disappointed with Fortinets first stab at a cloud WiFi solution. The FortiAP 220A appears to be an off-the-shelf OEM piece that has been rushed into production. As I said, I’ve only spent a few hours with the device thus far. I have several to implement for customers in completely different industries, so we still have plenty of learning to do. The unit is priced middle-market, it’s light and is attractive enough to hang on a wall or ceiling without sticking out like a sore thumb. I look forward to the official release (rumored 4.2) and expect to see many features and improvements. It wouldn’t be a Fortinet product if it didn’t evolve in a matter of months with features we weren’t even asking for.

Friday, June 25, 2010

VPN Debug Enhancements

In newer versions of FortiOS (such as 4.0 MR1 and MR2) Fortinet has enhanced the capability of debugging individual VPN connections terminating on Fortigate firewalls.
Previously when debugging connections you only had the ability to filter IKE traffic by destination IP. The new "diag vpn ike log-filter" command has added several more filter criteria which you can use for troubleshooting VPN connections. Using this command is extremely helpful in cases where you have several active VPN sessions on your firewall. The console will most likely be spammed with log messages from tunnels which you are not interested in. To filter VPN connections use the following syntax:

diag vpn ike log-filter


Available options are:
clear erase the current filter
dst-addr4 the IPv4 destination address range to filter by
dst-addr6 the IPv6 destination address range to filter by
dst-port the destination port range to filter by
interface interface that IKE connection is negotiated over
list display the current filter
name the phase1 name to filter by
negate negate the specified filter parameter
src-addr4 the IPv4 source address range to filter by
src-addr6 the IPv6 source address range to filter by
src-port the source port range to filter by
vd index of virtual domain. -1 matches all


For example if you have a VPN tunnel from your firewall to a remote gateway with IP 1.2.3.4 you would use the following commands:
  • diag vpn ike log-filter dst-addr4 1.2.3.4
  • diag debug enable
  • diag debug console
  • diag debug app ike 200
Now only log messages matching a destination address of 1.2.3.4 will be displayed.

Also don't forget to reset your debug level when you are done to conserve system resources:
  • diag debug disable
  • diag debug reset

Friday, June 11, 2010

Packet Sniffers, Traffic Counters and NP2 Accelerated Ports

After switching from a FG800 platform (non accelerated network ports) to a 310B (NP2 accelerated ports) I noticed that the "diag sniffer packet" command is no longer very useful.

  • Packets are only displayed on the first pass through the firewall. Subsequent packets appear to be "flowed" and not displayed by the sniffer.
  • IP addresses are incorrect in certain cases. The sniffer shows packets as originating from the firewall's IP address. When performing a packet capture on the target host the source is that of the original sending host, so a discrepancy there.
  • The traffic counters in the firewall policy screen no longer show accurate values. We are receiving several gigs of log traffic through the firewall per day but after several weeks of uptime the counter only displays ~250 MByte of traffic. 
  • SNMP statistics do not show correct values due to fastpathing of packets
Solution:

For troubleshooting purposes and when it is desired to capture packets or check the flow on the FortiGate, you can bypass H/W acceleration with the following command on a specific port.

Be aware that this might affect performance and should only be used for troubleshooting purpose.

 "diagnose npu np2 fastpath-sniffer enable port(s)_number"

This now shows all traffic for all sessions to/from this or those port(s) when using the sniffer or the diag debug flow commands

The command below will re-enable H/W offloading :

 "diagnose npu np2 fastpath-sniffer disable port(s)_number"

Note that this is not saved in the configuration and will be lost after a reboot. 

(From Fortinet Knowledge Base)