Replicas behind NAT

[arekdreyer]

Does anyone have a replica behind NAT?

One 10.4.7 server is an Open Directory Master 10.4.7 with a public address 66.92.134.160 on en0.
Another 10.4.7 server has a private addreses of 192.168.10.20 on en0, which is behind
a NAT device, translating the 192.168.10.20 into a public address.
Each server only has one active interface.

I see some choices:
*Find a way to make server2 have its primary interface use a public address not private
*Set up a (static site-to-site ?) VPN so that the ODM can contact server2 at 192.168.10.20
*Roll it all by hand

When trying to make the second server a replica, things fail on Step 9
and then everything is undone.
This is from Library/Logs/slapconfig.log:

22006-07-25 23:49:33 -0700 – 9 Enabling password server replication
2006-07-25 23:49:33 -0700 – command: /usr/sbin/NeST -setupreplica 66.92.134.160 diradmin ****
2006-07-25 23:49:34 -0700 – NeST command failed with status 78
2006-07-25 23:49:34 -0700 – Removing replica due to an error adding a Password Server replica.
2006-07-25 23:49:34 -0700 – command: ssh [email protected] /usr/sbin/slapconfig -removereplica 192.168.10.20
2006-07-25 23:50:48 -0700 – command: /usr/sbin/sso_util remove -k -d -s -c -n -v 1
2006-07-25 23:50:59 -0700 – sso_util command output:
shutting down kadmind
kadmind shut down
shutting down kdc
No such process
No such process
kdc shut down
removing kdc database files

I was surprised that the syntax for NeST -setupreplica doesn’t include any information
about the candidate replica:
NeST -setupreplica <ip address of master> <admin name> <admin password>

[jxself]

[QUOTE]… which is behind a NAT device[/QUOTE]
If the master needs to contact the replica, and the replica is behing a NAT device, port fowarding needs to be set up. Check with the documentation on the NAT device about how to set up such a thing.

[arekdreyer]

Sorry, I should have said PAT rather than NAT. All ports are forwarded to the internal address of the Mac OS X server. Yes, that makes a big difference.

[dblack]

We experienced the exact same thing at our site and finally punted with a second cable back to the inside because of the same issue. The downside to using a second cable is that you end up with screwy behavior in terms of listeners and you will have to put a script into your startup items to set the route to the secondary card. Even in these situations, I’ve noticed that replication gets goofy.

When we tried this, we wanted a server in the DMZ to be a OD replica to provide authentication services to a blog server, webmail and others. We configured the PIX to do a route between the DMZ and the Inside so that our inside ldap server would “appear” to be inside the DMZ.

Quite a few authentication protocols seemed to work fine such as plaintext but the OSX ones for Blosjom, Jabber, AFP, etc. would fail. I don’t know what the mechanism is doing this…is it a lookup or verification of the sender IP address packet, is it doing a checksum of the whole packet? Which authentication service is this?

I’d still be interested to see if we could change this behavior.

[Author]

Posts