Showing posts with label debian. Show all posts
Showing posts with label debian. Show all posts

Tuesday, September 1, 2020

Use perdition as ssl offload proxy for imap / pop and managesieve

 In modern setups you often have an ingress controller, which does the ssl termination of the connections and then routes the traffic to the correct backend(s)

For kubernetes and http(s), often nginx is used for that task.

When you wish to do the same for imap and/or pop, then it also possible to use nginx for this.

https://docs.nginx.com/nginx/admin-guide/mail-proxy/mail-proxy/

But the main drawback is, that you need to implement some authentication and routing based on an http request.Also the managesieve protocol isn't supported.

If you don't wish to do the hassle with this, or you haven't the required infos to do it, then perdition can handle this be used as a full imap/pop/managesieve proxy.

The basic setup is quite simple, but has a few things to be aware of, when using it with ssl and/or ipv6.

When you enable ssl, then you have to specify the certificate files.

Usually something like this:

ssl_ca_file /etc/postfix/ssl/ssl-root.ca
ssl_cert_file /etc/postfix/ssl/myserver.crt
ssl_key_file /etc/postfix/ssl/myserver.key

When you then start perdition, it will probably log some warning about not beeing able to read the DH parameters from the certificate file. 

could not read DH params from cert file

Modern OpenSSL configurations require Diffie-Hellman values to generate secure keys in the exchange.

If your certificate does not have these embedded in it, you can generate them yourself and add them to the certificate.

openssl dhparam -out dhparams.pem 4096

Then just append the content of the dhparams.pem file to your .crt file and perdition has the required DH values.

The second thing you might struggle with, when you start perdition on an IPv6 enable host, then perdition will only bind the IPv4 address and not to the IPv6 address.

Unfortunally the documentation is lacking in this area, as how to bind the IPv6 ports too.

The correct syntax is to use this in the perdition.imap4s etc. files:

bind_address 88.xx.xx.xx,"[2a01:xxx:xxx:xxx::xxx]"

Please note that you must specify both IPvç and IPv6 addresses, and also that the IPv6 "[::]" will not work.

You have to specify the IPv6 address and enclose it in "[...]", including the " characters.

Configuring perdition as managesieve proxy is also not very well documented.

Specifying the sieve capabilities is rather tricky, here a wroking example:

capability \
"\"IMPLEMENTATION\" \"Cyrus timsieved\"  "\
"\"SIEVE\" \"comparator-i;octet "\
"comparator-i;ascii-numeric "\
"fileinto "\
"reject "\
"vacation "\
"imapflags "\
"notify "\
"envelope "\
"relational "\
"regex "\
"subaddress "\
"copy\"  "\
"\"SASL\" \"PLAIN\""


 

The important things to note in this:

Use \" to delimit the capabilities, and use two spaces to delimit the capability lines .

Have a look at the base config file perdition.conf as a staring point

If you have clients using K9 mail (And probably other too), then you might remove all "AUTH=..." settings from the imap capability string.

https://lists.vergenet.net/pipermail/perdition-users/2011-August/002547.html

Please also see my upcomming post  on monitoring perdition with Zabbix


Thursday, September 26, 2019

Startup problems with php-fpm and ldap user backend on Debian

Startup problems with php-fpm and ldap user backend on Debian

Do you use php-fpm together with an ldap backend for user authentication, then you probably have seen this message in your boot logs:

[26-Sep-2019 14:58:34] ERROR: [pool XXXXXX] cannot get uid for user 'XXXXXXXX'

When using the php5.6-fpm / php7.x-fpm versions of the PHP fpm process can cause startup problems, when the users are provided via the nslcd service.

The reason is, that the ldap user backend is starting after the php fpm process(es)

Fortunately this is easy to solve, just edit your /etc/init.d/php7.3-fpm init script and add the user backend service(s) to the Required-Start section

It looks like this:
# Required-Start:    $remote_fs $network

So to add nslcd (and recommended nscd too) results in this line

# Required-Start:    $remote_fs $network nslcd nscd


To enable the new dependencies of your service starts, just disable the service and reenable it.

systemctl disable php7.3-fpm 
systemctl enable php7.3-fpm

After this, you can reboot your server and the fpm processes should startup just fine
 

Wednesday, June 21, 2017

JSVC fails with error 11 after latest linux kernel Upgrades on debian/ubuntu

This morning, after doing some apt-get update/upgrades on various debian systems, we noticed that many of our java services did no longer work.
Since we use it to handle all our tomcat instances on many many servers, the impact is heavy.No single tomcat did run this morning...

Looking into the tomcat logs, we did see this message:
Service killed by signal 11

After some more investigations, it looks like the problem is related to the new kernel version installed in the upgrade process.

Google didn't find much about this, but the more important ones are here:
So the solution for now, is either switch to not using jsvc to start your services, or use a older or a "unstable" kernel.

The kernel causing the problems is
3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u1 (2017-06-18) x86_64
 
With the older one it does work
3.16.0-4-amd64 #1 SMP Debian 3.16.43-2 (2017-04-30) x86_64
 
To switch back to the older kernel just do this, and reboot your system:
apt install linux-image-3.16.0-4-amd64=3.16.43-2  
 
Reverting back to a older kernel is discouraged, since this does not solve the security problem.

Fortunately there is a very simple work arround for it.
When you start jsvc, just specify it to use a larger stack.
For tomcat you can put this in your startup file, so the daemon.sh takes the new options for jsvc.
 
export JSVC_OPTS=-Xss1280k

Thanks to https://community.ubnt.com/t5/UniFi-Wireless/IMPORTANT-Debian-Ubuntu-users-MUST-READ-Updated-06-21/td-p/1968252

Monday, June 19, 2017

Installing/running Debian stretsch inside kvm debian jessie

Installing or upgrading to a Debian stretch (Debian 9) edition should be a "no problem" case for most platforms.

Unfortunally running stretch in a KVM/QEMU environment based on Debian jessie isn't "just" working.

We did try to upgrade a existing Debian Jessie VM to stretch with the usual steps.
The upgrade itself works very fine and flawless as known from Debian systems.
But after rebooting the system, we did start getting errors in the guest, most of the time it did not even boot correctly.

In the host logfile we did see these messages in syslog:

kvm: zapping shadow pages for mmio generation wraparound
vcpu0 unhandled rdmsr: 0x34

In the log of the guest, we did see these stack traces:

Jun 19 15:40:18 sv54 kernel: [    0.000000] Linux version 4.9.0-3-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2 (2017-06-12)
Jun 19 15:40:18 sv54 kernel: [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-3-amd64 root=UUID=fb8d9106-4421-4e85-af6f-8c0561bb2b25 ro quiet
Jun 19 15:40:18 sv54 kernel: [    0.000000] ------------[ cut here ]------------
Jun 19 15:40:18 sv54 kernel: [    0.000000] WARNING: CPU: 0 PID: 0 at /build/linux-FT3UnK/linux-4.9.30/arch/x86/kernel/fpu/xstate.c:593 fpu__init_system_xstate+0x53b/0x981
Jun 19 15:40:18 sv54 kernel: [    0.000000] XSAVE consistency problem, dumping leaves
Jun 19 15:40:18 sv54 kernel: [    0.000000] Modules linked in:
Jun 19 15:40:18 sv54 kernel: [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.0-3-amd64 #1 Debian 4.9.30-2
Jun 19 15:40:18 sv54 kernel: [    0.000000]  0000000000000000 ffffffff87f28634 ffffffff88803e08 0000000000000000
Jun 19 15:40:18 sv54 kernel: [    0.000000]  ffffffff87c76eae 000000000000000a ffffffff88803e60 0000000000000340
Jun 19 15:40:18 sv54 kernel: [    0.000000]  ffffffff88803e90 ffffffff88803e9c 0000000000000100 ffffffff87c76f2f
Jun 19 15:40:18 sv54 kernel: [    0.000000] Call Trace:
Jun 19 15:40:18 sv54 kernel: [    0.000000]  [<ffffffff87f28634>] ? dump_stack+0x5c/0x78
Jun 19 15:40:18 sv54 kernel: [    0.000000]  [<ffffffff87c76eae>] ? __warn+0xbe/0xe0
Jun 19 15:40:18 sv54 kernel: [    0.000000]  [<ffffffff87c76f2f>] ? warn_slowpath_fmt+0x5f/0x80
Jun 19 15:40:18 sv54 kernel: [    0.000000]  [<ffffffff87c72754>] ? xfeature_size+0x5a/0x78
Jun 19 15:40:18 sv54 kernel: [    0.000000]  [<ffffffff88947243>] ? fpu__init_system_xstate+0x53b/0x981
Jun 19 15:40:18 sv54 kernel: [    0.000000]  [<ffffffff87f586e6>] ? msr_clear_bit+0x36/0xa0
Jun 19 15:40:18 sv54 kernel: [    0.000000]  [<ffffffff889468dc>] ? fpu__init_system+0x208/0x30b
Jun 19 15:40:18 sv54 kernel: [    0.000000]  [<ffffffff88942fea>] ? setup_arch+0xb8/0xcc6
Jun 19 15:40:18 sv54 kernel: [    0.000000]  [<ffffffff87d7a24e>] ? printk+0x57/0x73
Jun 19 15:40:18 sv54 kernel: [    0.000000]  [<ffffffff88938120>] ? early_idt_handler_array+0x120/0x120
Jun 19 15:40:18 sv54 kernel: [    0.000000]  [<ffffffff88938bbf>] ? start_kernel+0xab/0x463
Jun 19 15:40:18 sv54 kernel: [    0.000000]  [<ffffffff88938120>] ? early_idt_handler_array+0x120/0x120
Jun 19 15:40:18 sv54 kernel: [    0.000000]  [<ffffffff88938408>] ? x86_64_start_kernel+0x14c/0x170
Jun 19 15:40:18 sv54 kernel: [    0.000000] ---[ end trace 44d08096f31f4f03 ]---


and

Jun 19 15:40:18 sv54 kernel: [    0.387100] WARNING: CPU: 2 PID: 1 at /build/linux-FT3UnK/linux-4.9.30/arch/x86/include/asm/fpu/internal.h:368 fpu__clear+0x179/0x1b0
Jun 19 15:40:18 sv54 kernel: [    0.387101] Modules linked in:
Jun 19 15:40:18 sv54 kernel: [    0.387103] CPU: 2 PID: 1 Comm: swapper/0 Tainted: G        W       4.9.0-3-amd64 #1 Debian 4.9.30-2
Jun 19 15:40:18 sv54 kernel: [    0.387103] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
Jun 19 15:40:18 sv54 kernel: [    0.387104]  0000000000000000 ffffffff87f28634 0000000000000000 0000000000000000
Jun 19 15:40:18 sv54 kernel: [    0.387105]  ffffffff87c76eae ffff9ec076158040 ffff9ec076158b40 ffff9ec072329400
Jun 19 15:40:18 sv54 kernel: [    0.387106]  ffffffff88869da0 ffff9ec072354400 ffff9ec076158758 ffffffff87c30fc9
Jun 19 15:40:18 sv54 kernel: [    0.387107] Call Trace:
Jun 19 15:40:18 sv54 kernel: [    0.387110]  [<ffffffff87f28634>] ? dump_stack+0x5c/0x78
Jun 19 15:40:18 sv54 kernel: [    0.387112]  [<ffffffff87c76eae>] ? __warn+0xbe/0xe0
Jun 19 15:40:18 sv54 kernel: [    0.387113]  [<ffffffff87c30fc9>] ? fpu__clear+0x179/0x1b0
Jun 19 15:40:18 sv54 kernel: [    0.387114]  [<ffffffff87e0914c>] ? flush_old_exec+0x5bc/0x6b0
Jun 19 15:40:18 sv54 kernel: [    0.387116]  [<ffffffff87e5df52>] ? load_elf_binary+0x3c2/0x1600
Jun 19 15:40:18 sv54 kernel: [    0.387117]  [<ffffffff87e087f0>] ? search_binary_handler+0xa0/0x1c0
Jun 19 15:40:18 sv54 kernel: [    0.387118]  [<ffffffff87e5d734>] ? load_script+0x204/0x230
Jun 19 15:40:18 sv54 kernel: [    0.387118]  [<ffffffff87dfe0da>] ? __check_object_size+0xfa/0x1d8
Jun 19 15:40:18 sv54 kernel: [    0.387119]  [<ffffffff87e093c8>] ? copy_strings.isra.25+0x188/0x450
Jun 19 15:40:18 sv54 kernel: [    0.387120]  [<ffffffff87e087f0>] ? search_binary_handler+0xa0/0x1c0
Jun 19 15:40:18 sv54 kernel: [    0.387121]  [<ffffffff87e09f0a>] ? do_execveat_common.isra.37+0x5aa/0x790
Jun 19 15:40:18 sv54 kernel: [    0.387123]  [<ffffffff881f8d20>] ? rest_init+0x80/0x80
Jun 19 15:40:18 sv54 kernel: [    0.387124]  [<ffffffff87e0a118>] ? do_execve+0x28/0x30
Jun 19 15:40:18 sv54 kernel: [    0.387125]  [<ffffffff881f8d70>] ? kernel_init+0x50/0x100
Jun 19 15:40:18 sv54 kernel: [    0.387126]  [<ffffffff882064f5>] ? ret_from_fork+0x25/0x30
Jun 19 15:40:18 sv54 kernel: [    0.387127] ---[ end trace 44d08096f31f4f07 ]---
Jun 19 15:40:18 sv54 kernel: [    0.387363] ------------[ cut here ]------------
Jun 19 15:40:18 sv54 kernel: [    0.387365] WARNING: CPU: 2 PID: 1 at /build/linux-FT3UnK/linux-4.9.30/arch/x86/include/asm/fpu/internal.h:353 fpu__copy+0x140/0x190
Jun 19 15:40:18 sv54 kernel: [    0.387366] Modules linked in:
Jun 19 15:40:18 sv54 kernel: [    0.387367] CPU: 2 PID: 1 Comm: init Tainted: G        W       4.9.0-3-amd64 #1 Debian 4.9.30-2
Jun 19 15:40:18 sv54 kernel: [    0.387367] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
Jun 19 15:40:18 sv54 kernel: [    0.387368]  0000000000000000 ffffffff87f28634 0000000000000000 0000000000000000
Jun 19 15:40:18 sv54 kernel: [    0.387369]  ffffffff87c76eae ffff9ec0723e7ec0 ffff9ec076158b40 ffff9ec0723e7e80
Jun 19 15:40:18 sv54 kernel: [    0.387370]  0000000000000000 0000000000000000 00007f7cfecd79d0 ffffffff87c30a90
Jun 19 15:40:18 sv54 kernel: [    0.387371] Call Trace:
Jun 19 15:40:18 sv54 kernel: [    0.387373]  [<ffffffff87f28634>] ? dump_stack+0x5c/0x78
Jun 19 15:40:18 sv54 kernel: [    0.387374]  [<ffffffff87c76eae>] ? __warn+0xbe/0xe0
Jun 19 15:40:18 sv54 kernel: [    0.387375]  [<ffffffff87c30a90>] ? fpu__copy+0x140/0x190
Jun 19 15:40:18 sv54 kernel: [    0.387376]  [<ffffffff87c74490>] ? copy_process.part.33+0x1a0/0x1c00
Jun 19 15:40:18 sv54 kernel: [    0.387377]  [<ffffffff87dfe0da>] ? __check_object_size+0xfa/0x1d8
Jun 19 15:40:18 sv54 kernel: [    0.387379]  [<ffffffff87f56988>] ? strncpy_from_user+0x48/0x160
Jun 19 15:40:18 sv54 kernel: [    0.387379]  [<ffffffff87e0744d>] ? cp_new_stat+0x14d/0x180
Jun 19 15:40:18 sv54 kernel: [    0.387381]  [<ffffffff87c760d3>] ? _do_fork+0xe3/0x3f0
Jun 19 15:40:18 sv54 kernel: [    0.387381]  [<ffffffff87e074b9>] ? SYSC_newstat+0x39/0x60
Jun 19 15:40:18 sv54 kernel: [    0.387383]  [<ffffffff87c03b1c>] ? do_syscall_64+0x7c/0xf0
Jun 19 15:40:18 sv54 kernel: [    0.387384]  [<ffffffff8820632f>] ? entry_SYSCALL64_slow_path+0x25/0x25
Jun 19 15:40:18 sv54 kernel: [    0.387384] ---[ end trace 44d08096f31f4f08 ]---
Jun 19 15:40:18 sv54 kernel: [    0.387420] ------------[ cut here ]------------
Jun 19 15:40:18 sv54 kernel: [    0.387422] WARNING: CPU: 2 PID: 1 at /build/linux-FT3UnK/linux-4.9.30/arch/x86/include/asm/fpu/internal.h:353 __switch_to+0x66a/0x6c0
Jun 19 15:40:18 sv54 kernel: [    0.387422] ------------[ cut here ]------------
Jun 19 15:40:18 sv54 kernel: [    0.387423] Modules linked in:
Jun 19 15:40:18 sv54 kernel: [    0.387425] WARNING: CPU: 3 PID: 0 at /build/linux-FT3UnK/linux-4.9.30/arch/x86/include/asm/fpu/internal.h:368 __switch_to+0x415/0x6c0
Jun 19 15:40:18 sv54 kernel: [    0.387426] CPU: 2 PID: 1 Comm: init Tainted: G        W       4.9.0-3-amd64 #1 Debian 4.9.30-2
Jun 19 15:40:18 sv54 kernel: [    0.387427] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
Jun 19 15:40:18 sv54 kernel: [    0.387427] Modules linked in:
Jun 19 15:40:18 sv54 kernel: [    0.387428]  0000000000000000 ffffffff87f28634 0000000000000000 0000000000000000
Jun 19 15:40:18 sv54 kernel: [    0.387430]  ffffffff87c76eae ffff9ec0762401c0 ffff9ec076158040 ffff9ec076240cc0
Jun 19 15:40:18 sv54 kernel: [    0.387431]  ffff9ec0762401c0 0000000000000002 ffff9ec076158a80 ffffffff87c24aaa
Jun 19 15:40:18 sv54 kernel: [    0.387432] Call Trace:
Jun 19 15:40:18 sv54 kernel: [    0.387432] ---[ end trace 44d08096f31f4f09 ]---


After some research we did find out, that there is a bug in the QEMU/KVM packages as provided by jessie stable repositories.

To solve the problem, you have to install more recent QEMU/KVM packages, and the best way to get them for stretch is to add the jessie backports to your sources.list

deb http://ftp.debian.org/debian jessie-backports main

After the usual apt-get update just install the qemu-kvm and related packages in the 2.8xxx version, instead of the 2.1xxxx releases.

After a reboot of your physical server, you can now enjoy debian stretch in your guests

Wednesday, May 24, 2017

Using letsencrypt certificates with Collabnet Subversion Edge

With the letsencrypt CA you can create ssl certificates to protect your http servers with a valid certificate.

These certificates are valid 90 days and the can be auto renewed, so your services won't interrupt.

For normal apache / nginx installations there are plenty of documentations on how to install and use such certificates.

Unfortunately with subversion edge, it does not just work out of the box, but it uses a apache http server for http/https communication.

So what's the problem?

Let's look at a standard subversion edge installation under debian:
  • The certificates are stored in /opt/csvn/data/conf in the files server.crt and server.key
  • The configuration for the ssl certificates are in the csvn_main_httpd.conf file, which is generated at each restart
  • In the csvn_main_httpd.conf file we only have the two server.crt and server.key files referenced, but not the required intermediate certificate chain

The first thing to do is generate a ssl certificate for your server.
The http server root points to /var/www/html, so you can use that folder to generate your certificates

certbot certonly --webroot -w /var/www/html -d svn.example.com
This generates the certificates in /etc/letsencrypt/live/svn.example.com

To use them, you can now delete the two server.crt and server.key files in /opt/csvn/data/conf and create symbolic links to these files

server.crt -> /etc/letsencrypt/live/svn.example.com/cert.pem

server.key -> /etc/letsencrypt/live/svn.example.com/privkey.pem

But what about the SSLCertificateChainFile /etc/letsencrypt/live/svn.example.com/fullchain.pem file?
You can't add it to csvn_main_httpd.conf since this file is regenegated on each restart.
But fortunally you can add it into the https special config, where the chiper config is stored.
So just add it into the ssl_httpd.conf file

Now we have everything together and could start the https svn server.
Unfortunately this will fail with a error message like:

ERROR errors.GrailsExceptionResolver  -
 FileNotFoundException occurred when processing request: 
[POST] /csvn/
/opt/csvn/data/conf/server.crt (Permission denied). Stacktrace follows:
java.io.FileNotFoundException: /opt/csvn/data/conf/server.crt (Permission denied)
        at java.io.FileOutputStream.open(FileOutputStream.java:270)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
        at java.io.FileWriter.<init>(FileWriter.java:107)


Ok, so you are running subversion as non-root as recommended. (If not, then rethink what you are doing and reinstall subversion as a standard user)

To allow the subversion user to access the ssl certificates of letsencrypt, the simplest way is to add the subversion user to the ssl-cert group, and give the group rx access to the certificates in /etc/letsencrypt/live and /etc/letsencrypt/archive

Once this is done, you should be able to start the svn server with active letsenrcypt ssl certificates.
What remains to be done is the periodic renewal of the certificates, which is widely described in the Internet.
What you have to do, is to restart the https service when a new certificate is generated. Usually you can do this in the renew script.

Thursday, March 31, 2016

Install Symantec Endpoint Protection on Debian Jessie

Syamntec endpoint protection is not only shipping for Windows systems, but also for OS-X and Linux systems.
Installing it on a debian jessie server does require some manual steps to have all features enabled.

The first step is to create a package in your SEP installation, simplest with a web downloadlink which you can later use to fetch the package via wget.

  1. Install Java 8
  2. Download JCE from http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html
  3. Install the cryptografic files into "/usr/lib/jvm/java-8-oracle/jre/lib/security"
  4. Ony 64-bit systems enable i386 packages and install glibc in 32bit edition
    dpkg --add-architecture i386
    apt-get update
    apt-get install libc6:i386
  5. On 64-bit systems install the linux-headers to allow compilation of the realtime scan kernel modules
    apt-get install linux-headers-amd64
  6. Download your SEP package from your server wget http://<your-sep-server>/EmailInstallPackages/xxxxxxxxxxxx/sep/SymantecEndpointProtection.zip
  7. Unzip zip package
  8. bash ./install.sh -i  

Installing Java 8 on Debian Jessie

Installation Oracle Java 8 on Debian Jessie

Debian 8 alias Jessie ships with OpenJDK 7 which is fine in many cases. But sometimes you need a more recent version.
In that case you can use the ubuntu ppa archives as install source.

Just type these commands in the console of your Debian system and it should install just fine, also providing automatic security upgrades as they become available.

echo "deb http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main" > /etc/apt/sources.list.d/webupd8team-java.list
echo "deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main" >> /etc/apt/sources.list.d/webupd8team-java.list
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys EEA14886
apt-get update
apt-get install oracle-java8-installer
java -version

Thursday, January 28, 2016

Upgrading from Debian 6 Openswan to Debian 8 Strongswan

When upgrading from Debian 6 to Debian 8, then IPSEC softwarestack is changed from Openswan to Strongswan.
The switch itself is not a big thing, but when you still have other Openswan IPSEC partners, you will have to change your Strongswan config a little bit.
Otherwise the two IPSEC implementations won't be able to build the VPN tunnel.

On the Openswan end of the VPN you will see such messages in your auth.log file:

Jan 28 11:58:55 fw pluto[1279]: "vpn01" #746: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW to replace #670 {using isakmp#4 msgid:6c3f1671 proposal=defaults pfsgroup=OAKLEY_GROUP_MODP2048}
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #669: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #669: starting keying attempt 5 of an unlimited number
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #747: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW to replace #669 {using isakmp#4 msgid:23eb99a9 proposal=defaults pfsgroup=OAKLEY_GROUP_MODP2048}
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: ignoring informational payload, type NO_PROPOSAL_CHOSEN msgid=00000000
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: received and ignored informational message
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: ignoring informational payload, type NO_PROPOSAL_CHOSEN msgid=00000000
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: received and ignored informational message
Jan 28 11:58:55 fw pluto[1279]: "vpn01" #4: ignoring informational payload, type NO_PROPOSAL_CHOSEN msgid=00000000


On the Strongswan side, you see this in the daemon.log:

Jan 28 12:16:52 vpn01 ipsec[13909]: 09[IKE] no matching proposal found, sending NO_PROPOSAL_CHOSEN
Jan 28 12:16:52
vpn01 ipsec[13909]: 09[ENC] generating INFORMATIONAL_V1 request 2468276578 [ HASH N(NO_PROP) ]

This is dues to some IKE mismatch (The OpenSWAN IKEv2 implementation has does not respect all standards)
You can solve this issue by specifying IKEv1 for the connection in your ipsec.conf on the Strongswan side:

keyexchange=ikev1

This should solve the problem.
Sometimes (Depending the Openswan setttings) you also have to add this to your connection  definition on the Strongswan side:

esp=aes128-sha1-modp2048!


Thursday, February 16, 2012

Changing keyboard layout when netbooting linux mint (And other debian variants)

When you boot the Linux Mint live cd to have a live recovery system (described here), then you have the default english/us keyboard active.
That's inconvinient when your keyboard has a different layout.

You can change it to the one you use by adding this to the APPEND statement in your boot configuration:

 locale=de_CH console-setup/layoutcode=ch

With these two setting, you receive most messages in german and the keyboard is set to swiss german.
The layout is correct in the X-Window system and in the terminals inside X.
On the console (Switch with CTRL+ALT+F1..F6) you will still have the us keyboard, if anyone has a tip...

Wednesday, November 10, 2010

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.