Bug 130753 - named fails to operate if ipsec service is active
named fails to operate if ipsec service is active
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
2
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Jason Vas Dias
Ben Levenson
http://archives.mandrakelinux.com/coo...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-08-24 07:12 EDT by Aleksander Adamowski
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-06-02 11:50:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Aleksander Adamowski 2004-08-24 07:12:56 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Gecko/20040813

Description of problem:
This bug's component should in fact be
freeswan-userland-2.04_2.4.20_20.9-0 (since this package is the source
of the problem, apparently), but it's not registered in Bugzilla yet.

The problem:

If the ipsec service is active (e.g. started on boot), then the named
daemon fails to operate correctly.

It spills the following log messages (some irrelevant data obfuscated):

Aug 24 HH:MM:SS infra named[PID]: client XXX.XXX.XXX.XXX#53: error
sending response: unexpected error

After some hours of operation named terminates with the following message:

Aug 24 HH:MM:SS infra named[PID]: socket.c:1564:
INSIST(!sock->pending_send) failed
Aug 24 HH:MM:SS infra named[PID]: exiting (due to assertion failure)


The connection between this problem and IPSec service wasn't obvious,
but I've found this single Mandrake mailing list post by Googling for
the assertion message:
http://archives.mandrakelinux.com/cooker/2004-02/msg06999.php

After disabling the ipsec service, the errors have stopped.

Version-Release number of selected component (if applicable):
bind-9.2.3-13

How reproducible:
Sometimes

Steps to Reproduce:
1. Enable the ipsec service
2. Enable the named service
3. Wait, and monitor /var/log/messages for named errors
    

Actual Results:  Stream of the following error messages:

Aug 24 HH:MM:SS infra named[PID]: client XXX.XXX.XXX.XXX#53: error
sending response: unexpected error

And after some time, the following error message after which named
terminates:
Aug 24 HH:MM:SS infra named[PID]: socket.c:1564:
INSIST(!sock->pending_send) failed
Aug 24 HH:MM:SS infra named[PID]: exiting (due to assertion failure)


Additional info:

It may be relevant: I'm running Fedora 2 kernel 2.6.8-1.521 with
selinux  in permissive mode, with the default policy loaded.


Severity is high, since ipsec is enabled by default if FreeSwan is
installed, and it results in non-operational name server with a cause
which is hard to track down.
Comment 1 Jason Vas Dias 2004-08-24 10:48:45 EDT
 openswan-2.1.4-5 is now part of the latest Fedora Core (rawhide)
 release (as of this Monday). You can download the source from 
ftp://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/SRPMS/openswan-2.1.4-5.src.rpm
 and compile it for FC2; I've also compiled it for FC2 on the i386,
 and you can download this from:
ftp://people.redhat.com/~jvdias/openswan-FC2/

 Also BIND has been updated for FC2, to bind-9.2.4rc6-FC2_7 .

 I cannot duplicate your problem with bind-9.2.4rc6 and 
 openswan-2.1.4-5 on FC2 ; but I do have a rather limited setup here -
 we're behind a firewall, so I run a fake 'root' nameserver , and
 only have one client connecting with dhcp and using my test   
 nameserver. I set up host-host encryption with openswan for this one
 client and the server, and could not duplicate this problem.

 So please try out the new versions of bind and openswan ; if they
 do not fix your problem, please attach details of your configuration
 to this bug: ipsec configuration files, named configuration files and
 zone files. A tcpdump gathered when the problem is duplicated would
 also be very useful. If you do not want to append potentially  
 sensitive information to this bug report, you can email it to me 
 directly: jvdias@redhat.com.


 
Comment 2 Trevor Cordes 2005-02-23 23:21:45 EST
An additional note: I used to run freeswan with fc1 along with named on several
machines and I never had the problem you list here.  Since freeswan is so
tempermental, I suspect there was something wonky with your freeswan config.
PS: the new 2.6 kernel VPN stuff works great as an alternative to open/freeswan.
Comment 3 Jason Vas Dias 2005-06-02 11:50:58 EDT
Clearing out old bugs here. It appears this one was a non-issue -
if not, please re-open .

Note You need to log in before you can comment on or make changes to this bug.