ipv6 in the wild

In the last year we did many steps toward ipv6 enabling our networks and servers.
Many things are simple, but there are also many pitfalls.

Here some infos about ipv6 in Ubuntu/Debian

- The Ubuntu distribution 9.04 and newer have good IPv6 support, most applications work with ipv4 and ipv6. Some applications however have problems with ipv6 addresses in some places. Here a upgrade to the most recent 10.10 release solves many issues.

- Debian, yeah, most things work fine in lenny, you can do most things you need, but there are still a few places where you may stumble. The real "full" ipv6 support is coming up in squeeze.

Here a two places where you might struggle:

- Assigning a static IPv6 address in debian lenny just does not work....
Nothing to worry about on workstations/desktops, but on firewalls and servers... it would be nice to always have the same ipv6 address assigned.
The reason for the problem is, that when the eth0 interface (or any other) is activated, the kernel module ipv6 is not yet loaded. So it's not possible to assign the ipv6 settings specified in the /etc/network/interfaces file.
The simplest solution is to just add ipv6 to the file /etc/modules (and rebuild the initramfs), that way ipv6 is directly loaded on boot and everything works as intended.

- RSYNC has only partial ipv6 support.
What does this mean ?
Rsync is able to resolve host names into ipv6 addresses and then connect to them via ipv6.
But if you with to specify the ipv6 address of the host directly on the commandline, then it fails parsing the address.
The simplest way to solve the problem is to install the rsync from the debian backports.

Don't forget, ipv4 addresses are running out in the next year, so prepare slowly to add ipv6 support to your network.
You don't have to do it in a big-bang way, rather just implement it step-by-step.

Collect linux statistics with collectd

Collectd is a great tool to collect various parameters of a running linux installation.

It can monitor disk space, cpu load, temperatures and much more.

One thing to note, is that collectd can cause system load by itself.
To prevent this, enable caching in the rddtools.

For more details read on in this post:

https://jeremy.visser.name/2010/02/23/enable-caching-in-collectd/

IPSec VPN with AVM 7170 / 7270 and linux (Ubuntu) OpenSwan and Dnydns

With the current Firmware the AVM ADSL routers 7170 and 7270 support creating IPSec VPN's.
That makes them interesting for connecting remote offices, small point of sales etc. to the enterprise network, also when the remotes don't have a fixed IP address.

Unfortunately the documentation of the IPSEC stuff from AVM is "very limited".

TO get it working it's important to configure the correct settings in the VPN configuration file for the AVM routers.

The wizard for creating the VPN config files generates something like this:

vpncfg {
connections {
enabled = yes;
conn_type = conntype_lan;
name = "IP_OF_ENTERPRISE";
always_renew = no;
reject_not_encrypted = no;
dont_filter_netbios = yes;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remoteip = 0.0.0.0;
remote_virtualip = 0.0.0.0;
remotehostname = "remote.dyndns.org";
localid {
ipaddr = IP_OF_ENTERPRISE;
}
remoteid {
fqdn = "remote.dyndns.org";
}
mode = phase1_mode_aggressive;
phase1ss = "all/all/all";
keytype = connkeytype_pre_shared;
key = "**********";
cert_do_server_auth = no;
use_nat_t = no;
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipnet {
ipaddr = 192.168.10.0;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 172.18.1.0;
mask = 255.255.255.0;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist = "permit ip any 172.18.1.0 255.255.255.0";
}
ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",
"udp 0.0.0.0:4500 0.0.0.0:4500";
}


To be able to connect to a openswan/linux server, we have to twea some settings:


vpncfg {
connections {
enabled = yes;
conn_type = conntype_lan;
name = "IP_OF_ENTERPRISE";
always_renew = yes; // Make sure the connections autostarts
reject_not_encrypted = no;
dont_filter_netbios = yes;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remoteip = 0.0.0.0;
remote_virtualip = 0.0.0.0;
remotehostname = "remote.dyndns.org";
localid {
ipaddr = IP_OF_ENTERPRISE;
}
remoteid {
fqdn = "remote.dnydns.org";
}
mode = phase1_mode_idp; // Change this from aggressive to normal mode
phase1ss = "all/all/all";
keytype = connkeytype_pre_shared;
key = "**********";
cert_do_server_auth = no;
use_nat_t = no;
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipnet {
ipaddr = 192.168.10.0;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 172.18.1.0;
mask = 255.255.255.0;
}
}
phase2ss = "esp-3des-sha/ah-no/comp-no/pfs"; // this is the compatible setting for openswan
accesslist = "permit ip any 172.18.1.0 255.255.255.0";
}
ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",
"udp 0.0.0.0:4500 0.0.0.0:4500";
}


In the avm documentation you see the possible combinations of phase1ss and phase2ss. It is important to know, that ONLY the listed combinations work. So you can't use other non-listed combinations. (Took me a whole day to figure out)

On the openswan side you have to define a connection like this:


# VPN connection for remote.dyndns.org
conn remotedyndnsorg
right=remote.dyndns.org
rightid=@remote.dyndns.org
rightsubnet=172.18.1.0/24
left=IP_OF_ENTERPRISE
leftsubnet=192.168.10.0/24
auth=esp
pfs=yes
authby=secret
dpddelay = 20
dpdtimeout = 60
dpdaction=hold
auto=start
keyingtries = %forever
keylife=45m
rekey=yes
ikelifetime=20m
compress=no


and of course in the ipsec.secrets you have to add the PSK

Currently we have a problem, that when the fritz boxes receive a new public IP,
the openswan does not always update the IP address for the connection.
This can be partially solved by upgrading to a more recent openswan version (2.3.16 or newer), which does a dns resolve when the vpn tunnel breaks.
But sometimes it still hangs in a state where it receives IPsec packets and drops them because they do not match the old resolved ip.

Hyper-V and current CPU's

You have a brand new installation, with a new server, ms windows 2008r2 server and hyper-v.

You see frequent blue screens (or unexpected reboots) with event log entries
like:

0x00000101 (0x0000000000000019, 0x0000000000000000, 0xfffff88001e5d180, 0x0000000000000002)


MS is aware of the problem and has a hotfix they provide on demand.

More details can be found here:

http://support.microsoft.com/?scid=kb%3Ben-us%3B975530&x=11&y=13


Looks like the Hyper-V stuff is still somewhat beta quality.

Disable IE enhanced security in Windows 2008 R2 Terminalserver

One of the IE features in server environments is the enhanced user security setting.
For servers this setting might be ok, but for normal users in a terminalserver it's just not usable.

On the "Server Manager" screen you can specify for users and administrators if the enhanced security should be active or not.
First this is to turn this off for normal users.
If by chance this really has a effect on your users, be happy and enjoy it.

But if you are still reading, then probably disabling this setting for the users did not change anything.

To make it simple:

Login as user and run these 3 commands from the commandline:

Rundll32 iesetup.dll, IEHardenLMSettings

Rundll32 iesetup.dll, IEHardenUser

Rundll32 iesetup.dll, IEHardenAdmin


This bug is only one year old, so please let MS some more time until they provide a fix for it.
(http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2general/thread/c5572fc7-6e92-46f8-824d-baca246e3106)

Be (a little bit) god under Windows 7

Under Windows 7, just create a folder with the name

GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}.


Now navigate to this folder with the windows explorer.
Software developers (even at MS) have some sense of humor :)

Connecting VDSL modem with Cat6 cable

if it's a Zyxel VDSL P-870M, then don't do it

Instead use the supplied ethernet cable (Cat5 UTP)
We did install such a modem and connected it to the firewall system (HP rack server) and did install the PPPoE stuff.
The PPP authentication did work, but then the modem stopped responding on the ethernet port.
We did even switch network port on the server, changed the cable against another cat6 cable, connected a serial terminal to the management port etc.

In a last try we did then plug in the supplied yellow cable.... and it worked.

The supplied yellow cable is a cat5 unshielded cable, with only 4 wires connected.
So probably the modem and server did agree to a gigabit connection when all 8 wires where connected, but then the modem miserably failed as soon as data did flow at gigabit speed.
On a 4-wire cable connection, the server and modem did agree to a 100MBit connection and that's probably the speed the modem is able to handle.