Setting up a branch office VPN between a Watchguard XTM505 and a Debian linux box.

Lets us say you have two sites and want to build a VPN between them. The first site has a Watchguard XTM device has a public IP address of 99.99.99.99 which protects a private IP address range of 10.0.1.0/24 and your second site has just a Debian Linux box which has a dynamic IP address that protects a private IP address range of 10.0.2.0/24


Debian side

Install needed packages:

# apt-get install ipsec-tools racoon

            Choose "direct" for racoon setup

Edit /etc/ipsec-tools.conf

#!/usr/sbin/setkey -f

# NOTE: Do not use this file if you use racoon with racoon-tool

# utility. racoon-tool will setup SAs and SPDs automatically using

# /etc/racoon/racoon-tool.conf configuration.

#

## Flush the SAD and SPD

#

# flush;

# spdflush;

spdadd 10.0.1.0/24 10.0.2.0/24 any -P in ipsec

           esp/tunnel/99.99.99.99-10.0.2.254/require;

spdadd 10.0.2.0/24 10.0.1.0/24 any -P out ipsec

           esp/tunnel/10.0.2.254-99.99.99.99/require;

Edit /etc/racoon/psk.txt and add the line

99.99.99.99   Somerandomkey

Edit /etc/racoon/racoon.conf

# Simple racoon.conf

#

#

# Please look in /usr/share/doc/racoon/examples for

# examples that come with the source.

#

# Please read racoon.conf(5) for details, and alsoread setkey(8).

#

#

# Also read the Linux IPSEC Howto up at

# http://www.ipsec-howto.org/t1.html

#

path pre_shared_key "/etc/racoon/psk.txt";

path certificate "/etc/racoon/certs";

remote 99.99.99.99 {

        exchange_mode aggressive,main;

        dpd_delay 20;

        dpd_maxfail 5;

        my_identifier user_fqdn "something@company.com";

        proposal {

                lifetime time 28800 second;

                encryption_algorithm 3des;

                hash_algorithm sha1;

                authentication_method pre_shared_key;

                dh_group modp1024;

        }

}

sainfo address 10.0.2.0/24 any address 10.0.1.0/24 any {

        lifetime time 28800 second;

        pfs_group modp1024;

        encryption_algorithm 3des;

        authentication_algorithm hmac_sha1;

        compression_algorithm deflate;

}

Watchguard side

I have simply taken screen shots for the configuration for the watchguard side:

You will need to ensure that the preshared random key is the same as you used in the /etc/racoon/psk.txt file you created above.

ESXi not accepting previously used volume

I recently had a problem on an ESXi 5.0 box I was trying to add a iscsi target to. I had set up a 6 TB  iSCSI LUN but everytime I tried adding it to ESXI I got the following error:

Call "HostDatastoreSystem.QueryVmfsDatastoreCreateOptions" for object "ha-datastoresystem" on ESXi "ESX HOSTNAME" failed. 

It turned out that the setup wizard on the device had happily created a volume and formatted it with ext4 before I realised what it was doing. Although I removed this volume the partition information wasn't removed from the array and this was upsetting ESXi.

How do you fix it? As there was no obvious way to wipe the partition info from within the Array's management interface I decided to do it from a Debian VM running on that host.

Firstly I removed the discovery information from the ESXI server so it isn't trying to interfere then on the Debian VM I installed open-iscsi with:

apt-get install open-iscsi

Start the open-iscsi daemon with:

/etc/init.d/open-iscsi start

Query the iSCSI target on the storage device:

iscsiadm -m discovery -t st -p 192.168.1.99

Which should return something like this:
192.168.1.99:3260,0 iqn.2010-12.com.manufacturer:nasdevice.name

If you have set up iSCSI authentication on your storage device you will need to run something like the following commands using the iqn in the above response.

iscsiadm   --mode node  --targetname "iqn.2010-12.com.manufacturer:nasdevice.name"  -p 192.168.0.99:3260 --op=update --name node.session.auth.authmethod --value=CHAP
iscsiadm   --mode node  --targetname "iqn.2010-12.com.manufacturer:nasdevice.name"  -p 192.168.0.99:3260 --op=update --name node.session.auth.username --value=username
iscsiadm   --mode node  --targetname "iqn.2010-12.com.manufacturer:nasdevice.name"  -p 192.168.0.99:3260 --op=update --name node.session.auth.password --value=password

Logon to the storage device:

iscsiadm -m node --targetname "iqn.2010-12.com.manufacturer:nasdevice.name" --portal "192.168.0.99:3260" --login

All being well this should now create a SCSI device as if you had attached a hard drive directly to the system. I looked at the bottom of the output from the dmesg command to find out which device (/dev/sdb).

I used the following command to write zeros to the first half a MB of the disk which will overwrite any partition table information (care should be taken that you have the correct device when using this command, it will eat your drive):

 dd if=/dev/zero of=/dev/sdb bs=512 count=1024

Now logout of the storage device with the following command:

iscsiadm -m node --targetname "iqn.2010-12.com.manufacturer:nasdevice.name" --portal "192.168.0.99:3260" --logout

ESXi should now happily accept the iSCSI LUN when you attempt to add it.

Converting a Debian VM from Xenserver to vSphere

You can transfer the data for the machine from one environment to another using clonezilla. Once it is transferred I found that the machine does not boot. On further investigation I realised that there are many differences between a Debian install on Xenserver and on vSphere.

If you get the message "Operating system not found" you will need to install grub to the virtual hard disk. To do this boot a liveCD (such as clonezilla).

As root run grub, at the grub> prompt type:

grub> find /boot/grub/stage1

This will return the location of grubs stage one, make a note of this location for the next command. Type

grub> root (hd0,0) < this is the location returned by the last command

Now install grub to the master boot record (MBR) with:

grub> setup (hd0)

then quit grub with:

grub> quit

Reboot to get the grub menu but if you let it try and continue using the default settings it will very likely hang because it will try to use a block device name that begins with xvd, these are xenserver specific and will not exist on the VMware VM. To get it to continue booting you need to hit 'e' on the grub selection screen, then edit the boot line to replace the device that looks like /dev/xvda1 and made it look like /dev/sda1, also remove the "console=hvc0" otherwise you will not be able to see interact with your OS via the console (hvc0 is another xenserver specific device name).

Once we have booted the system we need to go about preparing the system to boot correctly when left to it's own devices (geddit?), firstly ensure the keyboard keymap is set up correctly with:

# dpkg-reconfigure console-data

Edit /etc/fstab to change all references to xvd devices to sda in /etc/fstab

On many of the machines I transferred using this method I found that they had no swap partitions after the transfer. So I simply set the disk size slightly bigger than the source disk when initially creating the VM in vSphere, then added a partition with fdisk. I usually set the swap partition as /dev/sda2.
You then need to make that partition a swap partition with (I have found often that a reboot is required before the command works):

# mkswap /dev/sda2

Then you can mount it with:

# swapon /dev/sda2

And see if the swap space is available with:

# free

Don't forget to update /etc/fstab so it is pointing to the correct device for the swap partition so it is automounted at boot.

The CDRom is set to /dev/hdc unless you have changed the VM's hardware settings, update this in /etc/fstab as well.

We need to change grubs configuration so that it automatically boots a with appropriate parameters, this information is stored in /boot/grub/menu.list. You can achieve this by either running the following commands:

sed -i 's/xvd/sd/g' /boot/grub/menu.lst
sed -i 's/console=hvc0//g' /boot/grub/menu.lst

Or edit  /boot/grub/menu.lst, find the line that begins # kopt, remove the console=hvc0 from the end and change the "xvd" device to the correct boot device. move down to the botton where the menu choices are configured and change the device and remove the console=hvc0 from each of the one you will likely use (the top one only in my case).

Edit /etc/inittab and comment out the line that begins "co:"

Remove the xenserver specific packages from your apt sources list with:

rm /etc/apt/sources.list.d/citrix.list

Update your packages list:

apt-get update

Remove all the kernels that are installed with:

apt-get remove linux-image*

You will get a warning asking about the removal of the running linux kernel, say "No" to this as we will install another one that we can get headers for in the next step.

Install a more appropriate kernel with:

apt-get install linux-image-2.6-686

Reboot to run the newly installed kernel.

Install VMware tools, details of how in my post here, then reboot to test.

To get the most out of the VM you should switch hardware to paravirutal drivers for SCSI controllers and NICs.

Virtual Center Template for Debian

When using a windows template, VMware's Virtual Center can help you customise the resulting virtual machine with a wizard, unfortunately it doesn't do this for Debian which happens to be my Linux distribution of choice.

To create the template I just installed a nice minimal installation onto a new VM, added the vmware tools, changed the VM to use paravirtual hardware then converted it to a template.

After each "Deploy from template" I simply run through the following:

It would be potential security risk to have all the VMs using the same SSH keys so I regenerate SSH keys for the VM with:

# rm /etc/ssh/ssh_host*


# dpkg-reconfigure openssh-server


Update packages

# apt-get update


# apt-get upgrade


Set the IP address (well it is likely to be a server) with:

# vi /etc/network/interfaces

Change host name as it isn't helpful to have duplicate host names due to the confusion it can cause me:

# vi /etc/hostname

Amend hosts file (to match the host name)

# vi /etc/hosts


Do a quick confidence reboot then go about installing the software onto the VM as usual to make it fit for the task you need it for.

Squid authenticating against Active Directory on Debian Squeeze

Install Debian squeeze on you target (virtual) machine choosing only "Standard system utilities" during package selection.


I would normally logon and install ssh and vim to make life a little easier

# apt-get install ssh vim

Samba
we will need to install samba, winbind and kerberos client to get authentication working with Active Directory:

# apt-get install samba winbind krb5-user

If the Samba Server configuration asks you for a "Workgroup/Domain name" you can use short name that you specified for the domain when you created it but as we will replace this file shortly it doesn't actually matter what you put.

Now run re-configuration for krb5-config: 

# dpkg-reconfigure krb5-config

Default Kerberos version 5 realm: <FQDN for your AD domain in caps>
Add the kerberos server names for your domain: yes
Kerberos servers for your realm: <FQDN of your primary domain controller>
Administrative server for your kerberos realm:        <FQDN of your primary domain controller>


We can test that kerberos is working by running the kinit command, the format of the command is:

kinit <username>@<FQDN for your AD domain in caps> 

So for example, if our FQDN for the domain is test.local and we are using the administrator account we would type:

kinit administrator@TEST.LOCAL

If all is well it will ask for the password for the above account, if it accepts the password it will simply return you to the prompt, if there is something amiss it will report an error.


Move the /etc/samba/smb.conf file somewhere safe:

# mv /etc/samba/smb.conf /etc/samba/smb.old.conf

Create a new file containing the following:

netbios name = <this machine name>
workgroup = <shortname for you domain>
password server = <FQDN for your domain controller>
realm = <FQDN for your domain>
security = ads
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind separator = +
winbind use default domain = yes

Restart the samba services:

/etc/init.d/samba restart ; /etc/init.d/winbind restart

Join the active directory with:

net ads join -U administrator

If you receive a "DNS update failed" error you should manually add this server to the DNS server for the domain.
Restart the samba services:

/etc/init.d/samba restart ;  /etc/init.d/winbind restart

Check the the following commands return with a success:

# wbinfo -t

Success of the above command confirms connection to the domain controller.

# wbinfo -u

Lists users (local and domain).

# wbinfo -g

Lists domain groups.

Squid
Install the squid packages:

# apt-get install squid

Copy the squid.conf somewhere safe:

# cp /etc/squid/squid.conf /etc/squid/squid.conf.old

Edit /etc/squid/squid.conf and uncomment (remove the hash from) the following line:

#http_access allow localnet

Assuming you are using a RFC1918 network range on your network this will allow you to use the proxy. Save the file and restart squid with:

/etc/init.d/squid restart

Log in to a domain joined windows box that is logged on as a domain user in the inetaccess group (or which ever group you chose earlier to add to the auth_param directives). Set the browser to use squid as it's proxy server (squid runs on port 3128) and see if you can get to the internet. If not, you will need to concentrate on getting squid working as a simple proxy before you try to add authentication into the mix.

You will need to choose or create a security group within your Active Directory domain that we will use for deciding which users can authenticate with squid. I have chosen the group named inetaccess (a single word for the name of the group so we don't have to deal with spaces in the group name) and added as members all the users I want to give internet access to this group.

Edit squid.conf with the following changes:

Add the following auth_param section:

auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --require-membership-of=<short name of the domain>+inetaccess
auth_param ntlm children 5

If you want basic (very insecure, but handy for fallback) authentication then you will also need the following auth_param section.

auth_param basic program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic --require-membership-of=<short name of the domain>+inetaccess
auth_param basic children 3
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 5 hours

To stop the leaking of your client IP addresses out of the proxy, set forwarded_for to off

forwarded_for off

Add the following after the existing acl entries:

acl users proxy_auth REQUIRED

Comment out (add a hash to the front of) the line we uncommented before:


http_access allow localnet


Add the following after the http_access, but BEFORE http_access deny all

http_access allow users

Restart squid 

/etc/init.d/squid restart

Using the same domain joined windows box that is logged on as a domain user that you confirmed things were working from earlier see if you still have access.


Trouble shooting
If you are not sure why squid is not letting you through, try changing the debug in the squid.conf to:

debug_options ALL,1 33,8

Try the proxy again and then look though the log file /var/log/squid/cache.log for clues as to what is going on.

Gotchas:

Windows machines running on the Vista or Windows 7 code base (so this includes Windows server 2008 & 2008 R2) by default have a local policy setting that prevents you from authenticating with squid using the older version of NTLM. If you go into the local security policy management console then "local Policies"->"Security Options"->"Network security: LAN Manager authentication level" and set it to "Send LM & NTLM - Use NTLMv2 session security if negotiated" then reboot.
You can set this by group policy if you have a lot of machines to change, also if you find that this setting is not taking effect then maybe group policy is changing it back.

Debian Squeeze samba domain member fileserver

I struggled to find information on how to set up a samba domain member server on Debian Squeeze. This is how I got it working.

NTP
Firstly we install and configure an NTP client. This is needed to keep Kerberos happy, if the time is out by more than 5 mins Kerberos refuses to work.

apt-get install ntp

If you machine can access internet time servers, then this is all you need to do, ntp will happily start connecting  to the Debian time server pool and sync your time.


I have my own time server set up so in /etc/ntp.conf I commented out the server directives for the Debian time server pools and added my own server with the following:

server time.mycompany.com

Restart the ntp daemon with :

/etc/init.d/ntp restart

You can check what ntp gets up to with:

tail -f /var/log/syslog

You will hopefully see something like the following:

Oct  1 10:34:12 myserver ntpd[3757]: ntpd 4.2.4p4@1.1520-o Sun Nov 22 16:14:34 UTC 2009 (1)
Oct  1 10:34:12 myserver ntpd[3758]: precision = 1.000 usec
Oct  1 10:34:12 myserver ntpd[3758]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
Oct  1 10:34:12 myserver ntpd[3758]: Listening on interface #1 wildcard, ::#123 Disabled
Oct  1 10:34:12 myserver ntpd[3758]: Listening on interface #2 lo, ::1#123 Enabled
Oct  1 10:34:12 myserver ntpd[3758]: Listening on interface #3 eth0, fe80::250:56ff:fe84:1#123 Enabled
Oct  1 10:34:12 myserver ntpd[3758]: Listening on interface #4 lo, 127.0.0.1#123 Enabled
Oct  1 10:34:12 myserver ntpd[3758]: Listening on interface #5 eth0, 192.168.0.100#123 Enabled
Oct  1 10:34:12 myserver ntpd[3758]: kernel time sync status 0040
Oct  1 10:34:12 myserver ntpd[3758]: frequency initialized 0.000 PPM from /var/lib/ntp/ntp.drift
Oct  1 10:43:28 myserver ntpd[3758]: synchronized to 192.168.0.2, stratum 3
Oct  1 10:43:28 myserver ntpd[3758]: time reset +298.707500 s
Oct  1 10:43:28 myserver ntpd[3758]: kernel time sync status change 0001


Kerberos
Install the kerberos client

apt-get install krb5-user

Default Kerberos version 5 realm: <FQDN for your domain>
Kerberos servers for your realm: <FQDN for you dc>
Administrative Server for your Kerberos realm:  <FQDN for you dc>


Test that kerberos is working correctly by running the following command (caps are important):

kinit administrator@MYCOMPANY.COM

This will ask you for the password for the above account, which needs to exist on your Active Directory. If you input the password correctly you should be returned to the command prompt, otherwise you will see something like:

kinit(v5): Preauthentication failed while getting initial credentials

In which case you will need to check the contents of your krb5.conf file.

Samba

Install samba and winbind with:

apt-get install samba winbind

Don't worry what we put for the config of samba as we will replace the file anyway


Move the samba config file out of the way with:

mv /etc/samba/smb.conf /etc/samba/smb.conf.orig 

Create /etc/samba/smb.conf with the following contents, change the workgroup and realm to what your AD is set to.

[global]
        netbios name = sambafileserver
        workgroup = MYCOMPANY
        realm = MYCOMPANY.COM
        server string = Samba Domain Member
        smb ports = 445
        security = ADS
        encrypt passwords = yes
        winbind enum users = yes
        winbind enum groups = yes
        winbind use default domain = yes
        winbind nested groups = yes
        winbind separator = +
        idmap uid = 10000-20000
        idmap gid = 10000-20000

        client use spnego = yes
        client ntlmv2 auth = yes

[store]
        comment = file store
        path = /store
        read only = no
        valid users = MYCOMPANY+administrator

There are a couple of things to note about the smb.conf file, workgroup = the short name for your domain (like the domain part of a username when used like so: DOMAIN\username), realm is the FQDN of the domain (the part after the @ when you are using the username format like so: username@DOMAIN.LOCAL)


Create the /store path so that samba can access it to share it out:

mkdir /store 
chmod 777 /store

Edit /etc/nsswitch.conf and ensure that the passwd line looks like this:

passwd:         compat winbind

Restart the samba and winbind services:

/etc/init.d/samba restart ; /etc/init.d/winbind restart

We now need to join the computer to the active directory with:

net ads join -U administrator

As long as the join reports as successful you should be able to ignore any other failures.

Test that winbind can communicate with the domain:

wbinfo -t

If all is well the above command should return:

checking the trust secret for domain NA via RPC calls succeeded

Now jump onto a domain connected windows PC and see if you can create files in the share as the user mentioned in the "valid users" directive of the smb.conf.

Installing VMware tools on a Debian machine

Update: You may not need to do this, check this post.

Another one for the list of things I forget how to do regularly.


Make sure our packages are up to date.

# apt-get update

# apt-get upgrade

Install the packages needed to install the vmware tools:

# apt-get install build-essential psmisc linux-headers-$(uname -r)

In the vmware server console select "Install VMWare tools..." from the VM menu.
Then type the following:

# cd

# mount /media/cdrom

# tar zxvf /media/cdrom/VMware*.tar.gz

# cd vmware-tools-distrib

# ./vmware-install.pl --default

That should be it, you should now have working vmware tools on your Debian distribution.

Optionally you can delete the installation files with:

# cd ..

# rm -rf vmware-tools-distrib

Update: You should consider using more efficient virtual hardware and drivers, check out my post about using paravirtualized drivers