Technical Insanity of JFINLEY

Came across the need to allow SSL VPN clients access to remote networks beyond the SPOKE Firewall. In this instance, we have an IPSEC LAN-2-LAN VPN Tunnel between two points, we’ll use the name HQ & Sister-Company. A remote user accessing the HQ Firewall needs access to the Sister-Company file server. Instead of configuring another instance of a user on the Sister-Company firewall or another instance in the SSL VPN Client, we can allow access from the HQ Firewall.

HQ Fortigate LAN2LAN VPN MUST be configured in interface/route mode. SSL_VPN clients connect to the HUB FGATE ie. HQ

FW-Policy(s):

* ssl.root:(source subnet) -> VPN_Interface:(destination subnet)
* WAN:(source subnet) -> VPN_Interface:(destination subnet) (ACTION) SSL-VPN (identify “interesting traffic” on the SSL Client. Make sure to set the group access under this policy.

Route(s):

* Destination_Network:VPN_Interface

Connect using the SSL_Client and ping a host on the far side and see if your COUNT SEND/Receive increment with each ping on the SSL VPN Client.

For some time now, we were looking for a quality dependable name brand “server”. The sole purpose of this server is for backup/DR storage. We use ShadowProtect for our customers and hanging 2TB USB drives off each server was becoming a hassle and a limitation. After a bunch of reading on the HP Proliant Microserver, I’m pretty impressed. For us, it hits a sweet spot. Not too big, not too small – smaller than a sheet of typical printer paper (height and width) but capable of housing 4 hotswap drives & possibly two more without much modification in the CDROM bay.

The server came with 1GB Ram and a 250GB harddrive. After burning FreeNAS 8.x ISO to CD, I plugged in a USB CDROM and 16GB USB memory stick. Booting off the CDROM and installing FreeNAS onto the USB stick took 15 minutes. Upon booting and initial configuration, FreeNAS could not detect the stock 250GB HD. Not sure why, but I read the same elsewhere. Also, integrating into ActiveDirectory did not seem to work so after much reading I decided to try FreeNAS 7.2.

FreeNAS 7.2 proved fruitful. ActiveDirectory integration was sound, the stock 250GB HD was detected; perfect. I decided to pull the 250GB and install (4) 1TB WesternDigital RE3 Drives. I prefer enterprise drives vs desktop for the MTBF. FreeNAS picked up the new drives after performing a RESCAN. Formatted each drive as “software-raid”. Plan is to use RAID5 yielding a 2.7TB volume. Initializing took about 2 hours.

Simple CIFS copy tests with its current configuration yielded 40MB/sec. After changing the “Send and Receive buffer sizes” from default 16MB (16384) to 128MB (131072) my performance improved by 20%.

A crazy idea I had was to boot from a USB VMware Stick, install FreeNAS as a VM and format 80% of space for storage. If for any reason a physical server melted, the ability to P2V on this server would be ideal; for temporary purposes obviously. A must, however, would be to upgrade the memory from 1GB to it’s maximum, which is 8GB.

But that’s not all that crazy is it?

I recently upgraded my ESXi host to 4.1u1 and forgot to enable SSH. In the past, from what I know, you can only enable SSH on a vmware host by the hidden feature or via menu on the console requiring you to be there or depend on a IP-KVM device.

Apparently, you can enable it remote!

1. Fire up vSphere Client
2. Go to Configuration Tab (vmhost must be highlighted not a vm)
3. Select Security Profile (You should see a few services listed ie Remote Tech Support (SSH)
4. Click Properties to the top right of the list
5. Another box will appear – Select Remote Tech Support (SSH)
6. Click Options
7. Select your preference (Start Automatically)
8. Click Start
9. Click OK – That’s it!

You should be able to log in now via SSH

Per an email blast

Today Fortinet announced the acquisition of Ottawa, Canada-based TalkSwitch®, the developer of owner-friendly® phone systems for remote offices and distributed enterprises. With tens of thousands of customers and a network of 1,500 resellers and distributors, TalkSwitch delivers owner friendly phone systems to companies, home-based businesses, institutions and franchises.

Looks like Fortinet is diversifying their product line by adding a more stable “voice” solution. Hmm, this appears as if they’re positioning to take on Cisco directly.

I’m starting to hear some rumblings about CentOS releases and updates taking longer and longer thus stalling. You can applaud Larry Ellison of Oracle for that because of Unbreakable Linux. To summarize real quick; my opinion and my others, Unbreakable Linux is nothing more than RedHat with some language changed. RedHat releases source to comply with GPL and other licenses. Oracle grabs the source, makes changes and compiles it as “Unbreakable Linux” – TADA!

Here’s a conversation that inspired this article

Connect to console via serial cable (typical 9600,8n1) using a terminal type program (HyperTerm, PuTTY, ZTERM, TerraTerm)

Username: maintainer
Password: bcpb + serial number of the firewall

Note: Some devices after booting, may only give you a window of 14 seconds to type in the username & password.

#config system admin
#edit admin
#set password
#end

All credit to Soni Hacker for this information.

I started playing with the latest FortiAP220b device. Plugging in my trusty ultra-cool USB Bluetooth Serial adapter powered by the USB port on the FortiAP I noticed the following:

FAP22B3U1XXXX314 login: admin
Mar 1 12:12:03 login[606]: root login on `ttyS0′

BusyBox v1.01 (2010.08.28-00:38+0000) Built-in shell (ash)
Enter ‘help’ for a list of built-in commands.

FAP22B3U1XXXX314 # help

Built-in commands:
——————-
. : alias bg break cd chdir continue eval exec exit export false
fg hash help jobs kill let local pwd read readonly return set
shift times trap true type ulimit umask unalias unset wait

FAP22B3U1XXXX314 # .

Ok, so we know it’s running an embedded type of Linux called Busy-Box. At this point the AP is NOT administrated by the Fortigate. Not sure how much I can do with it until I tick manage – more to follow…

I’m always looking for ways to lighten the load I carry on my back every day. That load being my backpack. I carry enough equipment to perform daily and semi-annual duties. Beside the absolute essential (MacBook Pro 15″ 2010), power supply & wireless mouse, I carry cables such as (funny I have to list it!)

• 7 ft Ethernet patch cable
• 7 ft Ethernet cross-over patch cable
• 25 ft Ethernet patch cable
• Ethernet couplers
• serial cables (2 types)
• gender changers (25 to 9 & male/female)
• null modems
• Cisco adapters
• Numerous USB cables (mini to normal)

So the other day, out of the blue I found out there’s blue-tooth serial adapters! I was like sliced-bread. I immediately ordered one:

The adapter defaults at 19200 baud so I had to connect my Serial-2-USB and set baud rate. If you are from the MODEM days 70′s-early 90′s), it’s very similar to the HAYES AT command set. Once I paired the adapter on my MAC, I loaded ZTERM and connected – voila! I have console on my Cisco from 40 ft away! Awesome I say and this will eliminate about 80 feet of cable I used to carry around!

If you work with customers who use multiple internet carriers, how do you handle an ISP outage in regards to name resolution?  You’ve probably ran into the situation where a LINK reports up, but the actual route is down on the other side of your gateway thus the ISP’s DNS servers are unreachable.  Now days, DNS servers published by ISP’s are only reachable with in “their” network.  Sure, you can  distribute each of the ISP’s DNS as first/second/third, but what happens to the end users browsing experience?  It’s slow, not working, down – waiting for that first, second or even third DNS server progression to resolve.

One solution I’ve employed is to use an outside DNS source beyond the ISP such as OpenDNS or Google’s public DNS.  To provide redundancy, be sure to push both to PC’s via DHCP.

Fortinet has the same ability to ping from a particular interface.  On a Fortigate, simply enter in the CLI

Assumptions:

Internal: 192.168.42.1
DMZ: 192.168.100.1
WAN1: 10.10.100.254
Customer Side Network: 172.15.30.1

# exec ping-options source 192.168.100.1
(The interface IP you want to source from – in this case the DMZ interface)

# exec ping 172.15.30.1

Pings to 172.15.30.1 on the customer side network will now originate from the DMZ interface.