Bug 602515 - Setting nsslapd-listenhost to IPv4 address allows IPv6 connection
Summary: Setting nsslapd-listenhost to IPv4 address allows IPv6 connection
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: 389
Classification: Retired
Component: Directory Server
Version: 1.2.6
Hardware: All
OS: All
medium
medium
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks: 639035
TreeView+ depends on / blocked
 
Reported: 2010-06-10 02:49 UTC by Endi Sukma Dewata
Modified: 2015-01-04 23:42 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-01-18 23:59:06 UTC
Embargoed:


Attachments (Terms of Use)
scripts.tar.gz (2.79 KB, application/x-gzip)
2010-06-10 02:49 UTC, Endi Sukma Dewata
no flags Details

Description Endi Sukma Dewata 2010-06-10 02:49:12 UTC
Created attachment 422755 [details]
scripts.tar.gz

The nsslapd-listenhost should be used to limit the server to listen to certain address only.

Assuming the hostname is mapped to both IPv4 and IPv6 addresses, this is the expected behavior:
A. If it's set to the hostname, it should listen to the hostname and both IPv4 and IPv6 addresses.
B. If it's set to the IPv4 address, it should listen to the hostname and the IPv4 address only.
C. If it's set to the IPv6 address, it should listen to the hostname and the IPv6 address only.

The problem is the scenario B above doesn't work properly. Currently if the nsslapd-listenhost is set to the IPv4 address it will accept connections from everything: the hostname, the IPv4 address, and the IPv6 address.

This problem can be reproduced consistently on RHEL and Solaris.

To reproduce the problem, unpack the attached scripts.tar.gz and execute run.sh. It will execute the following operations:
1. Create slapd instance
2. Configure IP mappings in /etc/hosts (RHEL) or /etc/inet/ipnodes (Solaris)
3. Run test with nsslapd-listenhost set to the hostname.
4. Run test with nsslapd-listenhost set to the IPv4 address.
5. Run test with nsslapd-listenhost set to the IPv6 address.
  
Steps #3-5 are trying to verify scenarios A-C above, respectively. They will execute the same test with different nsslapd-listenhost settings. As mentioned above step #4 will fail because a client can connect successfully using the IPv6 address.

Comment 3 Nathan Kinder 2011-01-18 23:27:31 UTC
With DNS configured to map a single hostname to both an A and AAAA record, I do not see the issue when setting nsslapd-listenhost to the IPv4 address.  Netstat shows the following:

# netstat -an | grep 389
tcp        0      0 10.16.98.160:389            0.0.0.0:*                  LISTEN

I will try using the hosts file to see if that makes a difference.

Comment 4 Nathan Kinder 2011-01-18 23:50:28 UTC
Using the test scripts from this but, there is an FAIL status reported when it configures the listenhost for the IPv4 address and it attempts to connect using the IPv6 address.

Looking into it, it seems that the problem is related to the mozldap client.  If I have the server configured to listen on the IPv4 address only, the mozldap client works when specifying the IPv6 address, but the OpenLDAP client fails:

[root@dsrhel5-vma scripts]# ldapsearch -x -h [fec0:0:a10:6000:210:16ff:fe98:160] -p 389 -b "" -s base "(objectClass=*)"
ldap_bind: Can't contact LDAP server (-1)

[root@dsrhel5-vma scripts]# /usr/lib/mozldap/ldapsearch -h [fec0:0:a10:6000:210:16ff:fe98:160] -p 389 -b "" -s base "(objectClass=*)"
version: 1
dn:
objectClass: top
namingContexts: dc=example,dc=com
...

If I configure ns-slapd to listen on all interfaces (or just the IPv6 interface), both the mozldap and OpenLDAP clients work fine.  I think this is a mozldap client bug.

Comment 5 Nathan Kinder 2011-01-18 23:59:06 UTC
I also noticed when connecting using mozldap ldapsearch that the access log shows that the connection is actually going over the IPv4 interface:

[18/Jan/2011:16:10:46 -0800] conn=3 op=1 fd=64 closed - U1
[18/Jan/2011:16:12:16 -0800] conn=1 fd=64 slot=64 connection from 10.16.98.160 to 10.16.98.160

I'm marking this as NOTABUG since it is not a bug in 389.


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