That happened a few days later when I tried to use Apple’s Back to My Mac — it just didn’t work. After some network tracing I found out that the Apple machine sent DNS SOA requests but never got a reply back. It turned out that all SOA request got blocked somewhere. Sending requests to my own name server (host -t soa blackdown.de ns.blackdown.de) and tracing DNS there showed that no packet ever arrived.

I put the Speedport back into router-mode at this point and, who would have guessed it, SOA requests worked fine again.

After fruitless discussions with Deutsche Telekom support (it was impossible to find anyone who even remotely understood what I was talking about) and sending a bug report to AVM (the 701V actually is a FRITZ!Box) which never got an answer, I finally solved the problem by putting a Freetz firmware on the Speedport. This firmware had an option to disable the PPPoE-Filter. After disabling the filter the device worked flawlessly in modem-mode.

Now, a few days ago, I switched to VDSL and got a new router: a Speedport W920V.
First thing I did was to put it into modem-mode. And there it was again, the DNS SOA problem!

Knowing what the problem was, I found a simpler fix this time:

1. Download the configuration from the device
2. Manually change dnsfilter_for_active_directory = yes; to dnsfilter_for_active_directory = no; in the pppoefw section
3. Manually change ipnetbiosfilter = yes; to ipnetbiosfilter = no; in the pppoefw section
4. Insert a NoChecks=yes line after the Country=… line in the header to make the device accept the modified file although its checksum is wrong now
5. Upload the modified configuration to the device

(If you have a local NTP server, you also might want to add it to the server_list in the ntpclient section while editing the configuration of the Speedport.)

My exim configuration uses three different cyrus_sasl authenticators and each exim invocation resulted in three of these OTP warnings because exim calls sasl_listmech() for each configured authenticator. It doesn’t specify a limiting mech_list, that means SASL will test which of all installed mechs actually can be used for authentication. Debian’s SASL package includes libotp.so, so it also tries to use OTP which is not configured on my system.

There are two ways to get rid off the warnings:

• Remove /usr/lib/sasl2/libotp.*. You’ll have to do this after each upgrade of the libsasl2-modules package.
• Rebuild exim with this patch. The patch specifies a limiting mech_list option for SASL. This limits sasl_listmech() to the mechs used in the exim configuration. Other mechs won’t be tried anymore.

May 3rd, 2005: A slightly modified version of the patch has been integrated into Exim CVS and will be included in the next Debian release of exim4 (see Debian bug #299743)

• /etc/exim4/exim.pl:
  Don’t forget to change ppp0 to the interface you want to handle!

  #! /usr/bin/perl
  
  # Requires libio-interface-perl
  
  use strict;
  use IO::Socket;
  use IO::Interface;
  
  sub get_remote_helo_data()
  {
      my $s = IO::Socket::INET->new(Proto => 'udp');
      my $addr = inet_aton($s->if_addr('ppp0'));
      my $hostname = gethostbyaddr($addr, AF_INET);
  
      $hostname = '' if (!$hostname);
  
      return $hostname;
  }
  

• /etc/exim4/conf.d/main/50_exim4-localconfig_perl:

  #main/50_exim4-localconfig_perl
  perl_at_start = true
  perl_startup = do '/etc/exim4/exim.pl'
  

• Add the following code to the appropriate transport, e.g. remote_smtp_smarthost:

  helo_data = \
    ${if >{${strlen:${perl{get_remote_helo_data}}}}{0} \
                   {${perl{get_remote_helo_data}}} \
                   {$primary_hostname}}
  

The Limit action can be used to limit accepted connections per IP and timeframe. The hardcoded limit currently is 6 connections per 60 seconds. If an IP tries to connect more often, the attempts will be DROPed.

The Whitelist action provides some simple port-knocking whitelist. If you know the WHITELIST_PORT and can lift the limits imposed by the Limit action for your IP and 60 seconds by connecting to that port.

Here’s how you can integrate those two actions:

• Create two empty files:
  • shorewall/action.Limit
  • shorewall/action.Whitelist
• Copy Limit and Whitelist to the shorewall directory
• Add Limit and Whitelist to shorewall/actions
• Set WHITELIST_PORT in shorewall/params
• Use Limit in shorewall/rules, for instance:

  Limit:ULOG:SSH    net  fw  tcp  ssh
  Limit:ULOG:IMAP   net  fw  tcp  imap,imaps
  

  Note: You must use the <action>:<log>:<tag> format for the rules. Limit uses the <tag> for the ipt_recent table name.

• Optionally add a Whitelist rule:

  Whitelist:ULOG    net  fw
  

If you’re running OpenSSH 3.9 or later, you additionally might want to set MaxAuthTries to 1 (see sshd_config(5)).

May 9th, 2005: I have found a bug in the ipt_recent module, see this article for more information and a fix.