No technical expert advice can be found here ;)

After over one year working together with Danny Braniss and testing several thousands of options, settings and configurations, I managed to get the iStore iSCSI-device working together with FreeBSD.

Just to remember. The following error occured, when trying to write an UFS filesystem to the device:

newfs -O2 /dev/da0s1
/dev/da0s1: 782023.5MB (1601584044 sectors) block size 16384, fragment size 2048
using 4256 cylinder groups of 183.77MB, 11761 blks, 23552 inodes.
super-block backups (for fsck -b #) at:
160, 376512, 752864, … … …
1601377920
internal error: can’t find block in cyl 0

And in dangerously dedicated mode:

“# newfs -O2 /dev/da0“

Creating the lable in this mode fails with the message:

newfs -O2 /dev/da0
/dev/da0: 782023.5MB (1601584044 sectors) block size 16384, fragment size 2048
using 4256 cylinder groups of 183.77MB, 11761 blks, 23552 inodes.
super-block backups (for fsck -b #) at:
160, 376512, 752864, … … …
1601377920
internal error: cg 0: bad magic number

The important hint I got from a test with a PetaStor system, where everything worked perfectly. On the FreeBSD-FS mailinglist, I got the last part of the puzzle. Creating the filesystem works with these commands:

“# gpart create -s GPT da0"
# gpart show da0
# gpart add -b 34 -s 20971519 -t freebsd-ufs -l AnosLabel da0
# newfs -O2 /dev/da0p1


Important: Replace 20971519 by the size of your device, given by gpart show da0.

Building a SOCKS Proxy over SSH

All you need to realize a SOCKS5 tunnel over SSH is an openSSH on your “SOCKS-Server” and the already used “Proxifier”, as well as PuTTY on Windows-based systems.

First of all, you need to build up the secure tunnel (type the command into your OS X console):

ssh -2 -N -D 8080 user@<ip of your SOCKS5-Host>

for example:

ssh -2 -N -D 8080 myuser@192.168.1.11

On Windows, the configuration of PuTTY is the following:

Add the Hostname (for example: 192.168.1.11 – you need to add your SSH/SOCKS-Server IP there) under Tab “Sessions”
Then go to Tab “Tunnels” and enter Source Port 8080
Select “Dynamic” from the Destination Port
Click Open to buildup the tunnel

Now start the Proxifier and add the following Setting:

I find it usefull (but it is not neccessary) to add a rule to the Proxification Rules:

That’s all: openSSH has an integrated SOCKS-Proxy. Proxifier sends all traffic through the SSH-Tunnel (which is encrypted) and the SOCKS-proxy in openSSH on the other side sends the traffic to the destination hosts and returns incomming traffic to you.

Providing the SOCKS-Tunnel

After asking google for SOCKS I found a recommended implementation of SOCKS5: Dante
There is a very nice overview of SOCKS-implementations on wikipedia: http://en.wikipedia.org/wiki/SOCKS

Installation

Installation was quite easy: On SuSE it is a rpm you simply install, on FreeBSD you find it in the ports (cd /usr/ports/net/dante/; make; make install ). More interesting got the configuration of Dante, and that is what I want to explain today (since I did not find a howto and had to read the documentation):

Configuration

The config-file can be found in /etc/sockd.conf (/usr/local/etc/sockd.conf on FreeBSD). This you have to edit in the following way:

#define the logfile for dante
logoutput: /var/log/dante.log

#define the IP/Port Dante should listen for connections
internal: <IP address of your dante server> port = 80

#define the IP/interface Dante should use for outgoing connections
# Check the name of your interface using ifconfig
external: eth0
#Alternative: >external: <IP address that should be used>

#authentication: deactivated, since I will use a static IP-adress – that is auth enough now!
method: username none

#unprivileged user for Dante
user.notprivileged: nobody

Ok – that was the basic stuff – now the interesting part:

#Who can access this SOCKS Tunnel?
client pass {
from: <your ip here>/32 port 1-65535 to: 0.0.0.0/0
}

#Loopback may also access the tunnel
client pass {
from: 127.0.0.0/8 port 1-65535 to: 0.0.0.0/0
}

#Block all others
client block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

# Once connected, who may be connected then?
# block connections from anywhere to loopback
block {
from: 0.0.0.0/0 to: 127.0.0.0/8
log: connect error
}

# Allow connections from anywhere to client
pass {
from: <your ip here>/32 to: 0.0.0.0/0
protocol: tcp udp
}

pass {
from: 127.0.0.0/8 to: 0.0.0.0/0
protocol: tcp udp
}

#Block the rest
block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

Please note: this example will limit the access to one IP (/32), you can also allow more IPs. If you are not firm to subnetting, use the Subnet Cheat Sheet

Starting up Dante

After this simple configuration, your Dante-server should start without any problems, by typing:

/etc/rc.d/sockd start

(On FreeBSD first add sockd_enable=”YES” to your /etc/rc.conf, then type: /usr/local/etc/rc.d/sockd start ). Now you can watch your logfile under /var/log/dante.log to see what is going on.

Now let’s come to the complicated part: Make OSX work with the SOCKS5 tunnel we created.

Making OSX using the SOCKS5 tunnel

The first (and unsuccessfull) idea was, to configure it in in the network setup in the System Preferences. (Go to the Network preference pane, then click on further options and go to the “Proxies” tab. Enable SOCKS Proxy and fill in the IP of your server and the correct port, save the changes and activate the setting). Unfortunatly, this setting only works only for Cocoa and WebKit-based applications (and since not all of these applications use the System Preferences, you are covered only by 95% there too).

Screenshot Systempreferences network german

Thunderbird and Firefox for example doe not use the System preferences. You can both configure them to make them use the SOCKS tunnel, but to be honest: I do not want to reconfigure my applications on every new place. So I looked for a general SOCKS-Proxy.

After some search I found Proxifier – a commercial product, that is easy to setup easy to use and does everything you need with just a few clicks. There is also a version for Windows, that I did not check out, but I’m sure it will work as good as the OS X-version does.

The SetUp is easy and does not need the really good documentation that is provided on the Proxifier-homepage. If you feel better by watching the dosumentation, here you will find it: http://www.proxifier.com/mac/documentation/ProxifierHelp.html

After starting and configuring Proxifier, I got back online to the world, bypassing the firewall of my customer over port 80.

ATTENTION: Dante and SOCKS may not be confused with VPN, even if it is the same feeling! The data is send clear-text and my be visualized with any Packet-Sniffer!

Yeah – huge projects with different types of hardware always bring up many different type of problems: Today I had an INTEL Server Platform S7000FC4UR  (really a fantastic System: 160GB of RAM, 4x INTEL Xeon X7350 with 4 Cores, 2,93Ghz, so the system has 16 Cores!) to boot up with FreeBSD 7.1.

The boot-process hang up at several points, but went further after a delay of 20 to 30 secs, till the following point was reached:

md0: Preloaded image 4194304 bytes at 0xffffffff80c4be40
Trying to mount root from ufs:/dev/md0

The boot process is stuck

After trying different boot-options and kernels, I disabled USB2.0 support in the Bios and – *whoop* FreeBSD was booting without any problems. ACPI also seems to have some influences – but the mainproblem is the USB 2.0 support. Due to the fact, that a keyboard is nearly as fast on USB1.0 as on USB2.0 the solution to this problem was quite ok for the customer

The solution for this problem you can find: here

Ok – today comes a nice problem, that cost me about 80 hours of work, 2,8 liters of coffee and several kilometers for the pizza-guy:

I started with a very detailed tutorial from Vivek Gite, that can be found on cyberciti.biz FAQ site.

Vivek is using a i386 FreeBSD, that makes (I tested with i386 too) no difference to the amd64. Up to the part

“# mount /dev/da1s1 /iscsi“

everything is fine, but when trying to mount my device, I got the following error:

“mount: /dev/da0s1 : Invalid argument“

Ok – that is what I expected to happen, since no filesystem / labels has been installed on the device. So I tried to write a label with the command: newfs -O2 /dev/da0s1

After a while, the newfs command failed with the following error:

newfs -O2 /dev/da0s1
/dev/da0s1: 782023.5MB (1601584044 sectors) block size 16384, fragment size 2048
using 4256 cylinder groups of 183.77MB, 11761 blks, 23552 inodes.
super-block backups (for fsck -b #) at:
160, 376512, 752864, … … …
1601377920
internal error: can’t find block in cyl 0

So I tried the same in dangerously dedicated mode:

“# newfs -O2 /dev/da0“

Creating the lable in this mode fails with the message:

newfs -O2 /dev/da0
/dev/da0: 782023.5MB (1601584044 sectors) block size 16384, fragment size 2048
using 4256 cylinder groups of 183.77MB, 11761 blks, 23552 inodes.
super-block backups (for fsck -b #) at:
160, 376512, 752864, … … …
1601377920
internal error: cg 0: bad magic number

I spent a lot of hours in reading Mailinglists, Manuals and FAQs and finally started a thread in the freebsd-scsi Mailinglist. The thread can be found here: Problem with disklabel and filesystem over iSCSI.

Danny Braniss is now trying to get some SCSI-specialists and the guys from iStor at one table, to find a solution to this problem. As soon as there will be more information on this issue, I’ll post it here.

The solution for this problem you can find: here