Archive for the ‘Networking’ Category

Fortinet FortiOS firmware upgrade – Upload file is too big or invalid

Sunday, June 5th, 2011

If you receive an “Upload file is too big or invalid” error message when trying to upload a new FortiOS image to your Fortinet device via the web interface, then the first thing to try is giving the device a quick reboot in order to free up memory to hold the uploaded copy of the firmware image.

If this doesn’t fix the problem, then I’ve had much more success with running the update process from command line, although this does require you to have the new FortiOS image on a TFTP server so that the Fortinet device can download it. Once you have issued the command, the device will download the new image and reboot.

The exact command varies depending on the deice type, for example FortiGate devices have the option of FTP or TFTP downloads, whilst FortiMail devices can only download new FortiOS images via TFTP.

For a FortiGate device:

exec restore image tftp

For a FortiManager device running FortiOS 3.x:

exec restore image

For a FortiManager device running FortiOS 4.x:

exec restore image tftp

For a FortiAnalyser device running FortiOS 3.x:

exec restore image

For a FortiAnalyser device running FortiOS 4.x:

exec restore image tftp

For a FortiMail device running FortiOS 3.x:

exec restore image

For a FortiMail device running FortiOS 4.x:

exec restore image tftp

Depending on the device and FortiOS version, you may have other file transfer options such as FTP available to you. Devices registered with a FortiManager can also update their FortiOS image by downloading a new one from the FortiManager unit.

If you are still having problems getting the new FortiOS firmware image onto your Fortinet device, then you can also download a FortiOS image via TFTP from within the Fortinet bootloader/BIOS using the serial console.

Connect a serial console to your device and reboot it, then interrupt the boot sequence when prompted. In the menu, select the option to download a new FortiOS firmware image and provide the file name, server IP address and local IP address.

Right at the start of the bot process, you should see a message along the line of:

Press any key to display configuration menu…

Once you have pressed a key, then the following configuration menu should appear:

[G]: Get firmware image from TFTP server.
[F]: Format boot device.
[B]: Boot with backup firmware and set as default.
[I]: Configuration and information.
[Q]: Quit menu and continue to boot with default firmware.
[H]: Display this list of options.

Enter G,F,B,I,Q,or H:

At the configuration menu, type “G” and press enter and you will be asked to enter the details needed to TFTP a new image to your Fortinet device:

Enter TFTP server address [192.168.1.168]:
Enter local address [192.168.1.188]:
Enter firmware image file name [image.out]:

You will need to be on the same subnet as the TFTP server in order to do this.

Tags: , , , , , ,
Posted in Fortinet | No Comments »

RouterOS slow learning BGP routes with Winbox open

Thursday, April 28th, 2011

After banging my head against a wall waiting for a RouterOS powered router to re-learn the 330,000 routes that currently make up the global routing table, I was surprised to find that seemingly Winbox slows the learning of BGP routes to a crawl. Closing Winbox allowed the router to process the entire global routing table in the normal minute or so, including passing through some complex filters.

It would seem that in RouterOS 4.x at least, the router is pushing details of all learned routes to any Winbox clients connected and slowing itself to a crawl in the process. I haven’t had a chance to verify if this affects all versions of RouterOS 4.x yet or test it on RouterOS 5.x

Tags: , , ,
Posted in Mikrotik RouterOS | No Comments »

Fortinet SSL VPN interface limitations

Saturday, March 26th, 2011

There seem to be some interface related limitations with the SSL VPN implementation on Fortinet’s FortiGate firewall devices which prevent you from connecting to the Fortinet SSL VPN on the IP address of an interface other than the one which your traffic enters the firewall on.

In other words, even with the appropriate rules configured in the firewall policy to allow your traffic to pass through the FortiGate between the interface that it is received on and the interface which that SSL VPN traffic is destined for, the FortiGate unit doesn’t respond.

I have been able to verify that this bug/feature is present in the latest build of FortiOS 3.0, but haven’t been able to test with any of the FortiOS 4.0 releases yet.

In my case, this was a problem because the WAN interface has a private IP address on it with a block of public IP addresses routed to the unit and in use on the LAN interface. In the end I worked around this by routing a single additional public address to the unit and configuring it as a secondary address on the WAN interface with a /32 subnet mask. The SSL VPN could then be accessed from this public IP address.

Tags: , , ,
Posted in Fortinet | No Comments »

Cisco DHCP snooping with a Cisco DHCP relay (ip helper) and DHCP option-82

Wednesday, November 3rd, 2010

By default, the Cisco DHCP snooping code on the Cisco Catalyst switches inserts option-82 into the DHCP packet but sets giaddr to 0.0.0.0, which causes the Cisco DHCP relay (ip helper) to drop all DHCP packets from a Cisco switch configured with DHCP snooping.

To work around this, you can either disable the insertion of Option-82 on the switch performing the DHCP snooping with:

no ip dhcp snooping information option

Or alternatively you can configure the Cisco device acting as the DHCP relay to trust DHCP packets with giaddr set to 0.0.0.0. This can either be done on all interfaces with the global command

ip dhcp relay information trust-all

Or on a per-interface basis with

ip dhcp relay information trusted

Remember, if you are applying the trust to a specific interface then it has to be the layer 3 interface with the IP helper on it (such as an SVI) and not the layer 2 interface that the DHCP packets are received on.

Tags: , , , , , , , , , , , , ,
Posted in Cisco | No Comments »

SSH on a HP ProCurve

Sunday, July 4th, 2010

By default HP ProCurve devices (like most switches) use telnet and TFTP (Trivial File Transfer Protocol) for management access, firmware upgrades and config backups. As these are both unencrypted protocols, it is a good idea to switch to using SSH and SCP/SFTP in order to secure your management access and all important configuration, which you can do with the following commands from configure mode:

crypto key generate ssh
ip ssh
ip ssh version 2
ip ssh filetransfer

This generates the keys that SSH requires, forces SSH to use the newer version two of the protocol and enables SCP/SFTP support for copying files to and from the flash.

As soon as you enable SSH filetransfer (basically SCP/SFTP) support then TFTP is disabled, but you have to disable telnet access manually in configuration mode with:

no telnet-server

Tags: , , , , , , ,
Posted in HP ProCurve | No Comments »

Changing the MAC address of a VLAN interface in Mikrotik RouterOS

Saturday, July 3rd, 2010

Do you want to change the MAC address of a VLAN interface in Mikrotik RouterOS? Are you baffled by the fact that although the VLAN interface has a MAC address property inherited from the parent Ethernet interface, it isn’t editable?

Well, you’re in luck, it isn’t actually impossible to give your VLAN interface a different MAC address to it’s parent interface, you just have to go about it in a somewhat roundabout way by making what is effectively a virtual Ethernet interface and bridging it to the VLAN interface. You then add your layer 3 IP functions to the bridge interface instead of to the VLAN interface.

First, you need to create a bridge and give it a name, then add the VLAN interface who’s MAC address you want to change to the bridge as a port. Finally, set the “auto-mac” property on the bridge to “no” and then change “admin-mac” property for the bridge to be whatever you want your new MAC address to be

/interface bridge add name=newmac disabled=no auto-mac=no admin-mac=”00:00:00:00:00:00″
/interface bridge port add bridge=newmac interface=vlan1

Tags: , , , , , ,
Posted in Mikrotik RouterOS | 1 Comment »

RouterOS v4.x and BGP

Wednesday, January 20th, 2010

Just a quick heads up for those using upgrading from RouterOS 3.x to 4.x and using BGP to announce a default route to any of your peers; you need to set “default-originate” to “always” or “if-installed” for each peer you have configured in RouterOS if want to announce the default route to. This setting is off by default in v4.x so can cause havoc when you upgrade! :(

Tags: ,
Posted in Mikrotik RouterOS | No Comments »

On the warpath

Sunday, August 3rd, 2008

Hey, guess what? In typical Edward style, it has been ages since I updated this thing and I still haven’t got the site working fully or using a custom skin. I have an excuse… I am busy/lazy (take your pick!) ;-)

I got back from going to see “The Dark Night” a couple of hours ago. It’s a bloody good film but ‘m annoyed that I saw the plot twist coming right from the start – being a bit of a batman fan, I recognised the character as soon as a bloke called Harvey showed up with what correctly I guessed a double headed coin that he uses to “make his own luck” ;-)

When I got back I set about unlocking Naomi’s old Sony Ericcson phone that she kindly gave me to replace my ageing Panasonic GD67 (circa 2003 and a hand me down via Matt) that does interesting things including randomly turning itself off.

6 weeks ago I requested a NUC (network unlock code) from Vodafone which they said would take between 5 days and 6 weeks to generate. So I patiently waited and when 6 weeks rolled around on Friday, I sent them a very angry e-mail telling them to pull their collective fingers out. This morning I got a reply telling me that they had generated a new code on the 24th of June (4 days after I had e-mailed them jumping through numerous hoops to prove that I hadn’t stolen the phone from Naomi) but that they “forgot” to e-mail it to me.

Incompetence or company policy not to co-operate with NUC requests? I’d go for the second one personally.

Phone unlocked, I set about learning how to use it and telling Naomi it was finally working. It seems quite nice but it’s such a change it’s going to take a lot of getting used to. At least it’s well built (unlike the Panasonic) and has fairly intuitive menus (unlike the Panasonic). It’s still not a patch on my 2G iPhone though ;-)

My good mood was destroyed shortly after my unlocking success when I attempted to order a pair of power supplies from Rapid Electronics (you don’t get a link you bunch of incompetent tits!). My order was very simple, 2 power supplies delivered to one address but billed to another. Yet, despite providing a text field for your billing address, it’s not editable. At first I thought this was a browser issue so I changed from Safari to Firebox but still it didn’t work, They seem to want me to call their sales line for what is clearly a complicated procedure for them (instead of standard everywhere else) so instead I sent them an indignant e-mail telling them to learn how to build web-sites. I don’t expect that it will make the blindest bit of difference but it calmed me down somewhat.

If anyone from Rapid is reading this, the solution to your problem involves a 9mm bullet and the head of everyone in your web design department ;-)

In an attempt to restore my mood (or possibly swing me ever deeper into a pit of despair) I set about the task of conducting a post-mortem on the two RouterBOARD 433AH boxes that were playing up when I tried to put them in Node4 almost a month ago.

At the time, one of the power supplies decided to fry itself and then the box running on the remaining power supply started behaving erratically. When setting it up I had been able to log into it fine but now my SSH session would hang as soon as the management shell spawned after authenticating.

Because of this we made the decision that we couldn’t trust any of the equipment and aborted the install until we had been able to examine what the problem was.

After about five minutes I managed to work out the really stupid and annoyingly simple reason for the SSH sessions hanging… there is an incompatibility between Mac OS X’s Terminal.app and the management shell in RouterOS version 3.x. The simple fix for this is to re-seize the Mac OS X terminal window as soon as you log in. This forces some kind of refresh which fires the RouterOS management shell back into life.

It seem that MikroTik have no intention of fixing this annoying bug and are blaming it on Apple instead :(

With that fixed (or at least explained), as soon a I can order some power supplies from a slightly more competent supplier than Rapid then maybe we can finally get this equipment installed.

One good thing did come out of the problems with the RouterBOARDs, I stumbled across the wiki page detailing the new support for Xen virtulization in RouterOS 3.11, a fantastic feature that I’ve been campaigning for for a long time but somehow missed the announcement for! I will have to have a play with it some time, but for now my bed beckons as tomorrow, more DIY awaits… :(

Tags: , , , , , ,
Posted in General, Mikrotik RouterOS | No Comments »