nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

OD Server Mgmt through Firewall

System

Hi, does anyone know how to configure it so that I can manage my remote OD servers through a firewall? OD 5.5.1 SP2

On the receiver I have defined the rmiConnectionPorts to be 13024 to 13033 via the deploy.cfg file. The firewall has these ports open. I also have port 9173 open.

It still doesn't appear to work.

Any help would be appreciated.

Sebouh

Find more posts tagged with

Comments

Adam Stoller

Did you follow the information in the Release Notes for OpenDeploy 5.5.1 SP2? page 20 and possibly 10-11 too.

Did you stop / start the AdminServer (and perhaps Base Server and Receivers) after making these changes?

I'm not sure if you have to make the same changes to the deploy.cfg file on the Receiver side - but it wouldn't hurt to do so before restarting the service there.

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

fish,

Yes, I've done this. I've verified that the RMI ports are 13024 to 13030 using netstat -an. So the receiver is listening on those ports.

Does it matter what RMI ports the Base is using as well?

Sebouh

Adam Stoller

I believe you want to make sure the Java RMI [primary] port is the same on both sender and receiver, but failing that - when you add the receiver to your list of servers in the Admin GUI - I believe you want to specify the Java RMI [primary] port of that specific receiver that you are adding.

So if you have a Base Server with the default Java RMI of 9173 and you have a Receiver with a Java RMI specified as 9999 - when you add the Receiver to the list of servers accessible from the Admin GUI I believe you would specify 9999 for the 'Port'

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

fish,

Thanks, but both Base and Receiver are using the default 9173 for the primary port. The secondary ports for the Receiver are 13024 through 13030.

Sebouh

Migrateduser

Just to double check - Did you apply SP2 to your receiver AND to your Admin Server? The application of SP2 to the Admin Server is a manual process, as outlined on pp. 10-11 of the SP2 Release Notes.

Todd Scallan
Group Product Manager
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

Migrateduser

Todd,

Actually I had not installed the AdminServer updates on either the OD admin runnning on my TeamSite server or the AdminServer installed on the receiving side. I've done that now and have restarted both OD and UI Admin services on both ends (my receiving side has follow-on deployments that fanout to other servers). This still doesn't work. It gives me a message that it can't contact to the server. The ports are definitely open. Is there anything else I should check?

Sebouh

Adam Stoller

You should only have ONE AdminServer
You should have at least one BaseServer and usually at least one Receiver.

The patch for 5.5.1 contained parts which needed to be done manually for the AdminServer - but any non-AdminServer parts needed to be done on both BaseServer and Receiver.

If you have more than one AdminServer configured - that's probably a source of problems...

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

fish,

Ok... I now have only one Admin Server on my TeamSite server. On the target server behind the firewall I have Base Server installed only. Still no luck.

The behavior I'm seeing is strange.... first a litle background. We have NAT translations set up between the two networks. On the TeamSite side I connect to an IP address 192.168.1.14 which gets translated on the target side to 10.100.1.15 (which is the local IP on which the target server is running). If I run TCPVIEW on the TeamSite server, I see that there is a connection made from the TeamSite server to the target on port 9173:

teamsite1:1568 --> 192.168.1.14:9173 ESTABLISHED

a second later a connection is attempted from the TeamSite server to port 13024 on the target, however it is attempted using the 10.100.1.15 address.

teamsite1:1589 --> 10.100.1.15:13024 SYN_SENT

The NAT translations seem to be fine since all my other traffic to this server (including HTTP, Terminal Services, SQL 1433) work fine.

Is it possible that RMI is somehow sending back it's internal address?

Sebouh

Migrateduser

Sebouh,

You might want to take a step back for a second to make sure that something else isn't the cause of the difficulties.

First, all Base Servers, Receivers and the Admin UI Server are updated with the service pack, including manual steps for applying to the Admin UI Server. Correct?

Next, can you log into the OD Admin UI Server as the bootstrap user and connect to a Base Server (or Receiver) with no firewall involved? That is, both are on the same side of the firewall.

Next, is the Base Server (or Receiver) that resides on the other side of the firewall set up with the same bootstrap user as the first Base Server (or Receiver)?

Are you logged in as the bootstrap user when attempting to reach the Base Server (or Receiver) on the other side of the firewall?

If the answer to each of the above questions is Yes, then we've pretty much ruled out the other potential causes of problems.

Todd Scallan
Group Product Manager
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

Migrateduser

Todd,

I can successfully connect to other servers using the OD GUI on the inside (no firewall). I haven't tried it with the bootstrap user, but I suspect the experience would be the same.

On the Base server installed on the target side on the other side of the firewall, the bootstrap user is different because the domains are different on each Base server (this is all on W2K). I don't know of any way of making the bootstrap user the same.

The problem I am seeing appears to not be an authentication issue but it seem that after the primary connection on port 9173, when it attemps to open a connection to port 13024 on the target it tries using the local IP of the target server as opposed to the NATed address on the firewall.

Any thoughts? Should I just open a case at this point?

Sebouh

Migrateduser

E-mail response from Todd...

Hi Sebouh,

The bootstrap user must be identical to the one on the Admin UI server. Basically, you are authenticated when you login to the Admin UI. After that, this userid is passed to the Base Server by the Admin UI Server when you attempt to connect to the host. There is no local user authentication going on at the Base Server, so the user doesn't have to exist on that box. Rather, this info is used by the Base Server for authorization purposes, e.g., which deployments you are allowed to run.

Please try changing the bootstrap user in the OD configuration for the Base Server to be the same as for the other servers. Then login as the bootstrap user and attempt to reach the Base Server.

If you are still having problems, then go ahead and open a tech support case. You should probably include a link to the Devnet post or just copy and paste the details into your case.

Todd Scallan
Group Product Manager
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

Migrateduser

Todd,

I have configured it as suggested with all base and receivers that are not on the admin server using the same bootstrap user as the Admin server and I'm still not having any luck, even if I log in as the bootstrap user into the GUI. I am actually getting a message that says:

The selected host cannot be contacted at this time.

According to the 5.6 documentation (even though I'm running 5.5.1 SP2) if this were not working because of the reason you've indicated I would see a message indicating:

The request to view server configuration was denied.

Would this same message be displayed on OD 5.5.1 SP2?

Also, based on the behavior I described earlier (with the secondary connection occuring on the wrong IP), I noticed in the docs (OD 5.6 pg 50) at the bottom regarding the rmiServerBind setting which defaults to the hostname/IP that it says:

"This value is passed to the Java RMI as a property."

What does this mean? I suspect RMI is passing back the 10.100.1.15 address back to my Admin server which it then is using for the follow-on connection. Is this the expected behavior or is this handled at the network layer?

Sebouh

Migrateduser

I don't think rmiServerBind is supported in OD 5.5.1.

Please open a case with Tech Support to help expedite resolution of your issue. Thanks.

Todd Scallan
Group Product Manager
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

Migrateduser

Todd,

Thanks. Case is opened.

Sebouh