Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 602515 - Setting nsslapd-listenhost to IPv4 address allows IPv6 connection
Setting nsslapd-listenhost to IPv4 address allows IPv6 connection
Status: CLOSED NOTABUG
Product: 389
Classification: Retired
Component: Directory Server (Show other bugs)
1.2.6
All All
medium Severity medium
: ---
: ---
Assigned To: Rich Megginson
Chandrasekar Kannan
:
Depends On:
Blocks: 639035
  Show dependency treegraph
 
Reported: 2010-06-09 22:49 EDT by Endi Sukma Dewata
Modified: 2015-01-04 18:42 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-01-18 18:59:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Endi Sukma Dewata 2010-06-09 22:49:12 EDT
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 18:27:31 EST
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 18:50:28 EST
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 18:59:06 EST
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.