Wednesday, 3 February 2016

"Connection Failed: Enforce Firewall Policy failed" - on OSX Yosemite

According to SK106293 - this problem can be fixed via a hotfix from Check Point TAC.
I've tried the hotfix and it doesn't appear to perform any different. You still get the same error pop up and in the logs.
There is a workaround though - you need to manually disable the firewall on the client (if your policy allows for it).

First, shutdown the CP client from your menu bar.

Stop the CP services


 sudo launchctl unload /Library/LaunchDaemons/com.checkpoint.epc.service.plist  

Edit your Trac.defaults file at /Library/Application Support/Checkpoint/Endpoint Connect/Trac.defaults

The top line should read something similar to

OBSCURE_FILE INT  1 GLOBAL 0


(the formatting of this file is horrible - I've removed loads of spaces / tabs to make it more readable).

Change the value of '1' to '0'.

Restart the CP services then stop them again

 sudo launchctl load -w /Library/LaunchDaemons/com.checkpoint.epc.service.plist
 sudo launchctl unload /Library/LaunchDaemons/com.checkpoint.epc.service.plist  

This will start the services and decode your Trac.config file so you can edit it (make sure you stop the services again to be able to edit the decoded file!).

Find the line like <PARAM enable_firewall="true"></PARAM>  and edit the value 'true' to 'false'. You might have another like showing the name of your policy - I'm not sure it's required with the policy disabled but I edited mine from "desktop_policy" to "".

Save and close the file then finally start the services again.

 sudo launchctl load -w /Library/LaunchDaemons/com.checkpoint.epc.service.plist  

Start the Endpoint VPN application again from Launchpad and try to connect. If it works for you too - awesome! If it doesn't - sorry, best speak to TAC to get a proper solution.

Tuesday, 26 January 2016

How to recover X-Raid (Netgear) drives after a chassis failure.

A while back I used to have a Netgear ReadyNAS Duo. For the time, it was pretty good value for money and proved to be a reliable little NAS for streaming and backing up files.
What I never really considered was what I would do should the chassis fail and I'm left with numerous drives running a 'proprietary' RAID type (X-RAID) and potentially no source for a replacement chassis other than eBay or CEX.
I assumed it would be a matter of plug drives in through a number of SATA > USB adapters and just dragging the files off once the OS magically picked up and decoded whatever X-RAID was.
Luckily, I never had to find out but a friend's house recently caught a lightning strike which took out his router and the ethernet port on his NV+ (the NAS took the lightning, not the friend). The drives looked to be safe in the NAS but with no way to access them - the only solution was to put them in something else and see what we could do.

The thought was to add all the drives to machine with plenty of SATA ports available (four for the drives from the NAS plus one for the OS and restoration drive) and see what happens, X-RAID seems to be pretty close to RAID-5 so I doubt Netgear / Infrant messed around with it so much as to make it unreadable by anything else.
Ubuntu 14.04 is my go to OS here - so I installed that on a spare drive (at this point the NAS drives were absolutely nowhere near this machine for fear of overwriting them accidentally).
When your'e happy it's installed and running, power down and add the old X-RAID drives in. Once connected, boot up again.

*****
WARNING: Don't run DF once you've mounted your drives with Fuse. There appears to be a bug that causes the fuseext process to crash and consume 100% CPU time. The 'du' command is slow (like, really slow) but won't crash your system.
*****

Next, we'll need to make sure we've got the FUSE module installed for Ext2 filesystems. First we'll cheat a little and go into a root shell.

 sudo bash  

(Warning: this will put you in to a root shell. Be very careful what you type outside of this list as you can cause serious damage to things).
Next install the Fuse Ext2 package.

 apt-get install fuseext2  


Then, load the fuse module.

 modprobe fuse


Next, we'll scan our connected drives for LVM volumes with

 vgscan  


Now we'll activate the volume we need

 vgchange -ay c 

(vgchange will search for all LVMs, '-ay c' will activate any volume named 'c' which is the name for the main volume on a ReadyNAS).


Make sure you have a mount point created to mount the reassembled volume in

 mkdir -p /mnt/readynas 

(just an example, call your directory whatever you like under /mnt/)


Then finally (fingers crossed here)

 fuseext2 -o ro -o sync_read /dev/c/c /mnt/readynas


All being well, you're data will all be available under /mnt/readynas (or whatever you called it). You're free to copy it off to a non RAID drive, thumb drive or whatever you have to hand.

Thursday, 14 August 2014

APM1 (Arduino 1280 based) Arducopter software

I've just acquired an older Arducopter quad and not had much luck with putting the newer versions of Arducopter onto the board because of its limited memory capacity. With a lot of digging and searching for the right Arduino IDEs and software versions - I've managed to build a couple of versions; one as per the source and one with some modules removed to make it fit onto the board. The hex files are attached below to hopefully save someone the pain of searching, compiling and failing. I'll also attach the IDE if you want to verify the code and compile yourselves.

Arducopter 2.3 and Arducopter 2.5.5 with NO CLI

The 2.5.5 firmware also has a few other modules removed as per this thread on DIY Drones.
Please be aware I've not tested the 2.5.5 version (yet) but the 2.3 release seems to fly perfectly well but again I've not tested the flight modes.


 # define GPS_PROTOCOL GPS_PROTOCOL_MTK16  
 # define CONFIG_RELAY      DISABLED  
 # define CAMERA         DISABLED  
 # define MOUNT         DISABLED  
 # define CLI_ENABLED      DISABLED  

The other files I've used to compile with and from are here:

Arduino 0022 (Relax Patch)
Arducopter firmware sources

Thursday, 29 May 2014

Fiddler SSL interception not working

Fiddler has been my go-to web application debugging tool for as long as I've needed one. Yesterday - it simply decided it didn't want to decrypt any more SSL traffic for me. No settings changed (no, really) or anything and I started seeing this error for every site I tried connecting to:

fiddler.network.https> HTTPS handshake to www.google.com failed. System.Security.Cryptography.CrytpographicException Cannot find the requested object.




Not a particularly helpful error message (at least not to someone who isn't the developer) so off to Google I went. A few hours of searching through various Google Group discussions mentioned some recent changes to the .NET framework which has changed certain cryptographic behaviours and broken things. The solution is to go to C:\Users\[your username]\Documents\fiddler2 and rename the file ClientCertificate.cer to something else. I'm not 100% certain on why this certificate would cause the problem in the first place but it fixed my SSL interception so I'm happy again. Full discussion from here.

Wednesday, 26 February 2014

F5 LTM Virtual Edition in Virtualbox

The F5 LTM Virtual Edition is a great way to get some experience with the product if you can't get your hands on any physical kit. If you're working your way way through the new certification path you'll need all the exposure and experience you can get so a local VM on a desktop hypervisor is ideal for practicing or having a poke around the web interface or CLI when you have some spare time.
I tend to use VirtualBox for my desktop virtualisation needs as it's cross platform and free, but there are no officially supported images provided by F5. After a bit of trial and error,  I've found the following setup to work nicely. Bear in mind though that you will need to acquire a trial license / base registration key. I don't know that F5 will be able to provide you this directly if you are an end user but your reseller or partner should be able to get you a 30 or 45 day evaluation license.

Firstly - download the Hyper-V VHD files for TMOS 11.5.0. (Link - registration required).
Extract the two VHD files into a folder wherever you like to keep your VMs.
Create a new virtual machine with the following properties:
Linux 2.6 / 3.0 Kernel (64-bit)
At least 2048MB of RAM (the more you have, the more modules you can potentially enable).
When prompted to add disks, skip this part and accept the warning.
When complete, edit the virtual machine settings and go to the storage tab.
Under store, find the SATA controller, add the largest of the VHD files first, then the one which has DATASTORE in the name.
Under network, add one interface (we'll add the rest later but this way we can make sure the management interface is eth0). I use host-only for my management network as it doesn't need internet access usually. Feel free to use whatever you need but the interface type should be PCNET PCI-ii. There's some stuff on F5 DevCentral that hints at there being VirtIO support in 11.2 but I've not tested it out yet.
Start the VM up from Virtualbox and check POST for errors / kernel panics but you should be fine. If you get any errors about MCP not running, go make a cup of tea and then try again. It'll load eventually :)

Once you've configured an IP address - check you can access it from a web browser on https://x.x.x.x. If you can, shut down the VM and we're ready to add some more interfaces.
Back in the network settings of your VM, add in as many interfaces as you need but make sure the type is the Intel PRO/1000 MT Server type.
Something to watch is the order of the interfaces; they might not match the order you've specified them in. You can use something like...

watch "ethtool ethX | grep detected"

and then disconnect and reconnect the virtual cable to see which interface maps where. Your finished VM settings should be similar to this...

That should be your lot - just activate your license and then start playing!