Thanks I've read the replication section many times at the site and logically it doesn't make sense when you look at the configuration.  My Master has this configuration: 
# Add indexes to the frontend db.
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryCSN eq
-
add: olcDbIndex
olcDbIndex: entryUUID eq

#Load the syncprov and accesslog modules.
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov
-
add: olcModuleLoad
olcModuleLoad: accesslog

# Accesslog database definitions
dn: olcDatabase={2}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {2}hdb
olcDbDirectory: /var/lib/ldap/accesslog
olcSuffix: cn=accesslog
olcRootDN: cn=admin,dc=example,dc=com
olcDbIndex: default eq
olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart

# Accesslog db syncprov.
dn: olcOverlay=syncprov,olcDatabase={2}hdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpNoPresent: TRUE
olcSpReloadHint: TRUE

# syncrepl Provider for primary db
dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpNoPresent: TRUE

# accesslog overlay definitions for primary db
dn: olcOverlay=accesslog,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogSuccess: TRUE
# scan the accesslog DB every day, and purge entries older than 7 days
olcAccessLogPurge: 07+00:00 01+00:00
 There's nothing in the configuration to inform the slapd daemon to "push" the info to a consumer in the dmz.

Here's my slave ldap configuration:
#Load the syncprov module.
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov

# syncrepl specific indices
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryUUID eq
-
add: olcSyncRepl
olcSyncRepl: rid=0 provider=ldap://ldaptest1.example.com bindmethod=simple binddn="cn=admin,dc=example,dc=com" credentials=passwd searchbase="dc=example,dc=com" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshOnly retry="60 +" syncdata=accesslog
-
add: olcUpdateRef
olcUpdateRef: ldap://ldaptest1.example.com
Here the consumer has a provider address and looks like this will initially connect to the provider server which won't work in the dmz. 

But I will try it. :)

Regards.

On Thu, Nov 18, 2010 at 9:48 AM, Aaron Richton <richton@nbcs.rutgers.edu> wrote:
On Thu, 18 Nov 2010, Anton Chu wrote:

I have a provider server in the intranet and I want to add a consumer server in a DMZ for replication.  The problem is that a connection can only be initiated from the intranet
to the DMZ.  I've read both refreshandpersist and refesh-only replications both require an initial connection from the consumer server which will be in the DMZ.  Should I put
the provider server in the DMZ instead? 

While only you can decide on your optimal network configuration, I note that configuration of push based (i.e. provider initiated connection) replication is detailed in the OpenLDAP 2.4 Administrator's Guide. So OpenLDAP software will handle whatever you decide is your optimal network configuration.