Nov 23 2011

Troubleshoot Wireless Station Connection Issues on the FortiAP

Applies to FortiAP v4.0 MR2 and above.

These steps provide basic troubleshooting for wireless station connection issues with the FortiAP.

1. Check whether the Wireless Station entry has been created on the Access Control Wireless Controller (FortiGate). Enter the following CLI command on the FortiGate that is used for Access Control:

FG600B3909600253 # diagnose wireless-controller wlac -d sta
* vf=0 wtp=70 rId=2 wlan=open ip=0.0.0.0 mac=00:09:0f:db:c4:03 rssi=0 idle=148 bw=0 use=2
vf=0 wtp=70 rId=2 wlan=open ip=172.30.32.122 mac=00:25:9c:e0:47:88 rssi=-40 idle=0 bw=9 use=2

2. Enable the wireless MAC diagnostics filter on the Access Controller and try to determine which wireless station is failing:

FG600B3909600253 # diagnose wireless-controller wlac sta_filter 00:25:9c:e0:47:88 1
Set filter sta 00:25:9c:e0:47:88 level 1
FG600B3909600253 # 71419.245 <ih> IEEE 802.11 mgmt::disassoc <== 00:25:9c:e0:47:88 vap open rId 1 wId 0 00:09:0f:db:c4:03
71419.246 <dc> STA del 00:25:9c:e0:47:88 vap open rId 1 wId 0
71419.246 <cc> STA_CFG_REQ(34) sta 00:25:9c:e0:47:88 del ==> ws (0-192.168.35.1:5246) rId 1 wId 0
71419.246 <cc> STA del 00:25:9c:e0:47:88 vap open ws (0-192.168.35.1:5246) rId 1 wId 0 00:09:0f:db:c4:03 sec open reason I2C_STA_DEL
71419.247 <cc> STA_CFG_RESP(34) 00:25:9c:e0:47:88 <== ws (0-192.168.35.1:5246) rc 0 (Success).

3. Open a Telnet or SSH session on the FortiAP and collect the following debug. Do not use a console session.

FAP22B3U10001989 # cw_debug app cwWtpd 0x7fff

It is recommended to collect this output via Telnet or SSH rather than by using a console session. This is because using a console session could impact the performance of the device.
Once the debug has been collected then proceed to stopping the out put with the following debug command :-

FAP22B3U10001989 # cw_debug app cwWtpd 0x0

4. Collect a sniffer trace between the FortiAP and the Access Control Wireless Controller (FortiGate). The related article provides information on using the FortiOS in-built sniffer.
5. Collect a trace capturing the wireless traffic using a WiFi adaptor (For example: Airpcap or Omnipeek) and compare with the trace collected in step 4.

http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD33214&sliceId=1&docTypeID=DT_KCARTICLE_1_1&dialogID=26359510&stateId=0%200%2026361167


Jul 27 2011

How to Upgrade a Juniper HA Netscreen or SSG Firewall

These notes assume that the bootloader is already up to date, and that we’re just upgrading the ScreenOS software.

Standalone Firewall

1) Download the latest ScreenOS release and release notes from Juniper support.
2) Backup (save) the config via GUI:
Configuration -> Update -> Config File -> Save to File
or Save Config via CLI: "save config to tftp ?"
3) Configuration -> Update -> Firmware/ScreenOS -> Load File. The Netscreen or SSG will now reboot and come back up at the new version.

——————————————————————-

Upgrade HA NSRP Pair – IN ATIVE/STANDBY Mode

– Upgrade Standby Unit First
– Configuration -> Update -> ScreeOS/Keys -> Firmware (ScreenOS) -> Load File -> Apply
– This will upload file, apply new image, and reboot. WebUI will time out while device is rebooting. WebUI should refresh back to Netscreen login page after it reboots – may take several minutes (after 5 min or so if it doesn’t refresh back to login page, hit the refresh button every 1-2 mins).
– Login and Confirm Home page shows new version
– Failover to secondary (On Primary: exec nsrp vsd-group 1 mode ineligible) – you can confirm group 1 is the correct VSD group through Network -> NSRP -> VSD Group
– Confirm Secondary is Master (from CLI prompt should change from (B) (backup) to (M) (master).

– Upgrade Primary
– Login to Primary Confirm home screen shows new version
– On Primary: exec nsrp sync rto all from peer (syncs objects with secondary)
– Primary may fail back to master after it upgrades/reboots (if preempt is enabled); if it does not, and secondary is still active after the primary upgrade, manually fail primary back to active/master from secondary by using: exec nsrp vsd-group 1 mode backup
——————————————————————-
Upgrade HA NSRP Pair – IN ATIVE/ACTIVE Mode
Similar to the above note, except:
Fail over master/B (Group # changes):
• If the preempt option is enabled:
exec nsrp vsd-group 1 mode ineligible
• If the preempt option is not enabled:
exec nsrp vsd-group 1 mode backup
Then fail over other device and upgrade.
Followed by SYNC: exec nsrp sync rto all
Note: Use "get nsrp" from the CLI (or viewed through the WebUI) to make sure you’re using the correct VSD group in the commands above. Also use "get system" after the upgrade to confirm the upgrade was successful and reflects the new version.

——————————————————————-
Upgrade using the CLI

To upgrade and downgrade ScreenOS via the CLI, perform the following steps:

  1. Log in to the security device using an application such as Telnet or Secure Shell (SSH) or Hyper Terminal, if directly connected through the console port. Log in as the root admin or an admin with read-write privileges.
  2. Before upgrading or downgrading a security device, save the existing configuration file to avoid losing any data:

    save config to tftp <ip_addr> <filename.cfg>
    For example:  save config to tftp 1.1.1.1 ssg5_date.cfg

    where:
    ip_addr is the IP address tftp server
    filename.cfg is the name of the Config File.

  3. For simplicity, copy the ScreenOS firmware file to the TFTP server root folder.
    Note: Important note:  Make sure that that the ScreenOS has been extracted from the ZIP folder.
  4. Start the TFTP server, by double-clicking on the TFTP server application.
  5. Save the ScreenOS firmware to flash by entering the command:

    save soft from tftp [ip_addr] [filename] to flash
    Where:
    ip_addr is the IP address of your computer
    filename is the name of the ScreenOS firmware.

    Following output is seen when the file is downloaded:

    ssg20-> save software from tftp 172.16.10.10 SSG5SSG20.5.4.0r10.0 to flash
    Load software from TFTP 172.16.10.10 (file: SSG5SSG20.5.4.0r10.0).

    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

    tftp received octets = 12427198
    tftp success!
    TFTP Succeeded
    Save to flash. It may take a few minutes ...platform = 20, cpu = 1, version = 18
    update new flash image (04aa4020,12427198)
    platform = 20, cpu = 1, version = 18
    offset = 20, address = 8000000, size = 12427120
    date = 71e0f038, sw_version = 71e0f03c, cksum = 41d65212
    software major version is not same, accept this firmware? y/[n] y <==== Enter Y here
    Program flash (12427198 bytes) ...
    ++++++++++++++++++++++++++++++++++++++++++++++++++done
    Done
    ssg20->

  6. When the upgrade or downgrade is complete, you must reset the security device.   Execute the reset command and enter y at the prompt to reset the device
    ssg20-> reset <<=========Reboot the firewall using 'reset' command
    System reset, are you sure? y/[n] y <<===Enter Y here
    In reset ...

  7. Wait a few minutes, and then log in to the security device again.
  8. Use the command 'get system' to verify the version of the security device ScreenOS firmware.
  9. Use the command ‘get config‘ to review the configuation.
  10. (Not required) If the existing configuration is incorrect, which can happen on a downgrade, upload the configuration file that you saved in step 3 by executing the command:
    save config to flash from tftp <ip_addr> <filename>

    Then execute the reset command and enter n at the prompt to save the config:

    ssg20-> reset <<=========Reboot the firewall using 'reset' command
    ssg20> Configuration modified, save? [y]/n n   <<=========Enter 'n'; otherwise you will overwrite the configuration you just copied to flash
    System reset, are you sure? y/[n] y <<===Enter Y here
    ssg20-> reset

    Wait a few minutes, and then log in to the security device again.
    Note:  If you inadvertantly entered y at the ‘Configuration modified, save?’ prompt, then simply repeat step 10 and enter n.

Also see:  http://kb.juniper.net/index?page=content&id=KB13672&pmv=print


Jun 10 2011

L2TP Over a NAT/VPN Device

By default, Windows XP SP2 no longer supports IPsec NAT-T security associations to servers that are located behind a network address translator. Therefore, if your virtual private network (VPN) server is behind a network address translator, by default, a Windows XP SP2-based VPN client cannot make a L2TP/IPsec connection to the VPN server. This scenario includes a VPN server that is running Microsoft Windows Server 2003.

This default behavior can also prevent computers that are running Windows XP SP2 from making Remote Desktop connections with L2TP/IPsec when the destination computer is located behind a network address translator.

Because of the way that network address translators translate network traffic, you may experience unexpected results when you put a server behind a network address translator and then use IPsec NAT-T. Therefore, if you require IPsec for communication, we recommend that you use public IP addresses for all servers that you can connect to directly from the Internet.

To create and configure the AssumeUDPEncapsulationContextOnSendRule registry value, follow these steps:

1. Click Start, click Run, type regedit, and then click OK.

2. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPsec

3. On the Edit menu, point to New, and then click DWORD Value.

4. In the New Value #1 box, type AssumeUDPEncapsulationContextOnSendRule, and then press ENTER.

5. Right-click AssumeUDPEncapsulationContextOnSendRule, and then click Modify.

6. In the Value Data box, type one of the following values:

  • 0 (default)
    A value of 0 (zero) configures Windows so that it cannot establish security associations with servers that are located behind network address translators.
  • 1
    A value of 1 configures Windows so that it can establish security associations with servers that are located behind network address translators.
  • 2
    A value of 2 configures Windows so that it can establish security associations when both the server and the Windows XP SP2-based client computer are behind network address translators.

7. Click OK, and then quit Registry Editor.

8. Restart the computer.