Archive for the ‘Networking’ Category

ProCurve SSH – no matching cipher found

Monday, September 24th, 2018

I recently ran into a strange problem where I suddenly couldn’t SSH to any of our HPE ProCurve 2800 series (2824, 2848) devices from either macOS or Linux. I’m still not really sure what started this as OpenSSH definitely hasn’t been updated recently on the Linux client device at the very least, so I don’t see any reason for the list of ciphers supported on the client to have changed.

Anyway, the error message given by the OpenSSH client was:

Unable to negotiate with port 22: no matching cipher found. Their offer: des,3des-cbc

These ProCurves are pretty old and their SSH support is rather limited (1024 bit keys for example), so it’s not hugely surprising that their supported ciphers are also old and crappy.
Luckily, with OpenSSH you can specify the cipher(s) that you want to use on the command line when you’re connecting:

ssh -c 3des-cbc

This fixed the issue and lets me connect, but isn’t particularly convenient. However, you can also specify this in your ~/.ssh/config file so that it is applied automatically:

Host <blah>
Ciphers 3des-cbc

Just enter one or more hosts to match against (separated by spaces) and OpenSSH will automatically apply the specified options when connecting to any of them.

CSF bugs and updates

Saturday, June 25th, 2016

ConfigServer Security and Firewall (CSF) is a great program for managing iptables/netfilter firewall rules on Linux servers and performing automated blocks based on various things such as brute force login attempts (check it out at and I really shouldn’t complain given that it’s free, but sometimes I really do wonder if ConfigServer/Way to the Web actually do any testing at all before releasing new versions!

7 issues fixed in 6 bugfix releases (9.01 to 9.06) in 2 days! It’s a good job that the automatic update feature works properly…

Cumulus attacks on Juniper (again)

Thursday, November 12th, 2015

I have a lot of time for Cumulus Networks – I think they’re doing some very cool and unique things with their Cumulus Linux operating system for switches and they genuinely have something different to offer, but when they publish blog posts like their one today ( I lose a lot of respect for them.

This seems to be nothing more than a thinly veiled attack casting FUD (Fear, Uncertainty and Doubt) at a competitor – a knee-jerk reaction to a threat to their business. It actually reads pretty similarly to their blog post when Juniper originally announced the OCX range ( They’ve probably attacked other vendors in a similar manner.

For example, just by going to the main QFX5200 page on the Juniper web site (, I find:

Open access to the standard Junos Linux kernel, enabled by the disaggregated version of the Junos software, allows users to install third-party Linux RPM packages and create guest containers and VMs with central resource management and programmable APIs.

Yes that still needs a little more detail, but it answers at least some of the questions and all it took was a couple of clicks! Imagine what you could find out by actually speaking to someone familiar with the details…

I have a few questions of my own for Cumulus Networks;

  1. Did Cumulus Networks actually attempt to find out the answers to any of these points yourselves? If so, were you unable to find the details, or did you just not like what you found so decided to feign ignorance?
  2. Will Cumulus Networks put their money where their mouth is and make sure that Cumulus Linux runs on the Juniper QFX5200 series of switches (assuming that Juniper are willing to co-operate)?
  3. Does Cumulus Linux currently run on any switches powered by the Broadcom StrataXGS Tomahawk chipset? It doesn’t seem to be listed anywhere on the Cumulus Linux HCL that you so helpfully linked to from your blog post.
  4. Does Cumulus Linux currently run on any switches which support 25G, 50G or 100G Ethernet ports? These also seem to be conspicuously absent from the Cumulus Linux HCL.
  5. When will Cumulus Networks offer a fully featured MPLS implementation on their Cumulus Linux control plane?

Upgrading to Junos 12.3 from before 10.4R2 on Juniper EX

Monday, October 19th, 2015

In the release notes for Junos 12.3 ( on Juniper EX series switches, it says:

Upgrading from Junos OS Release 10.4R2 or Earlier

To upgrade to Junos OS Release 12.3 from Junos OS Release 10.4R2 or earlier, first upgrade to Junos OS Release 11.4 by following the instructions in the Junos OS Release 11.4 release notes. See Upgrading from Junos OS Release 10.4R2 or Earlier or Upgrading from Junos OS Release 10.4R3 or Later in the Junos OS 11.4 Release Notes .

Unfortunately, Juniper don’t list any Junos releases older than 12.3R1 for the EX4200 (and possibly other EX series) on their download site.

After poking around the Juniper support site for a bit, I found technical bulletin TSB16151 (, which contains downloads for Junos 11.4R8-S1 on EX2200, EX3200, EX3300, EX4200, EX4500, EX6200, EX8200 and XRE-200.

With this and the jloader files from technical bulletin TSB15524 (, I was able to complete the upgrade successfully.

4GB of RAM on a Juniper J-Series router (J6350)

Wednesday, May 2nd, 2012

Officially the Juniper J-series routers such as the J6350 only supports a maximum 2GB of RAM. The J6350 comes with 1GB of RAM installed and if you want to add more then you have to buy your RAM from Juniper at inflated prices, however as the J-series are standard x86 machines with Netburst era Celeron and Pentium 4 processors you can simply install standard DDR400 RAM if you aren’t worried about being covered by JTAC support.

Not only does installing your own RAM save you a shedload of money compared to the Juniper equivalent part (JXX50-MEM-512M-S), but you can also exceed the “supported” 2GB maximum 4x512MB configuration, which provides additional memory to the control plane. The four memory slots present on a J6350 can take a 1GB DIMM each, however thanks to a 32bit architecture and mapping of the PCI bus into the same address space, you can only actually use 3.5GB of that 4GB.

The J-series routers are picky about what RAM they use however, so I like to stick to Crucial sticks; partly as that’s what Juniper use but mostly because I use Crucial elsewhere for their great customer service and a genuinely quality product. If you want to stick with a 2GB maximum then you can use Crucial part number CT2KIT6464Z40B, which provides 2x512MB sticks. Alternatively, Crucial part number CT2KIT12864Z40B provides 2x1GB sticks, allowing you to max the chassis out at 4GB across all four slots.

Once you’ve got all 4GB of memory installed in the chasis, boot the router up and from the JUNOS operational mode CLI issue the command “show chassis routing-engine” – you should see a total of 3584MB of memory split between 3008MB of control plane memory and 576MB of data plane memory. If you only opted for 2GB of memory then the 2048MB total will be split between 1472MB of control plane memory and 576MB of data plane memory.

Remember, you replace the RAM in your routers at your own risk and doing so will likely void your warranty as well as rending your system unspported by JTAC.

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 []:
Enter local address []:
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.

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

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.

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, 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 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.

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