If you are using AgentConnection then you will need rules in your firewalls to allow PEM > managed hosts via port 3180(your port) two ways , if you want to tighten this then you can setup the agent to go in and out via two different ports.
If you are using a three tier patrol architecture (central) with cservers and rtservers then you will need an rtserver outside the firewall which the agents on that later can bind to , you then bind that to the cserver etc ....
you mentioned "ConnectPatrol interface " I believe you mean console server connection ? if you are talking about binding your agents to a cserver and then getting that into PEM "ConnectPatrol" was the original name for AgentConnection if I remember correctly ?
You mention xpetconf ... that means you are using agent connection filter paths , for this you could just ask you firwall admins to open 3180> TCP/UDP two way , see how that goes , if they want more security there are no more options available out there than in patrol 8) , if thats the case come back and ask the question again ....
thanks so much for your reply. You have answered my question, despite my confusing use of terminology. I'll try to clarify our environment. We use Patrol Central architecture to monitor about 700 patrol 3.5.32.08 or 3.6.00.7 agents on Windows, and 3.6.50 on about 300 AIX servers. We have a 11 RTServer "cloud" utilyzing "hub & spoke" topology. 6 spokes talking to 2 hubs using "costing" to load balance traffic. 1 RT for C-server connection into the cloud and 2 RT's reserved for Agent residing in two different DMZ's. Due to issues we have incurred with too many objects in the cloud at one time, namely "Cloud Freeze", we have not embraced the Pem Console Server Connection into the cloud, and have stuck with explicit Agent connections from PEM to individual agents across filter paths. So....with that clarification in mind, using the Agent Connection to each Patrol agent, is the answer still the same? Does PEM really require a bi-directional hole through the firewall to gather Patrol events? we were under the assumption since PEM initiates the conversation with each agent to poll for Patrol events, that the hole could be a "one-way" from internal "out" to the DMZ servers...keeping the port open for return communication from the PEM api running on Patrol. Thanks in advance for any help you can provide!
You are spot on with the outbound (upstream) initiation from PEM to managed hosts , however I dont think you will get away with one way traffic , PEM initiates and manages (timeouts, reconnects etc ...) its connections to its managed hosts (upstream) but those connections are then registed event manager connections at the agent, when an event/alert is triggered it is sent to the registered event manager connections , i.e. the event send is inititated by the agent not picked up by a poll from PEM.....
as an example ... I have had agents with dodgy OS routing tables which effectively meant they did not know the correct route back to the PEM that requested the connection , this i suppose effectively mimicks the one way scenario....
I found the following from the 4.3.xx Install and Config guide ....
"Can Agent Connection Connect to PATROL Agents
on the Other Side of a Firewall?
Yes, Agent Connection can connect to PATROL Agents on the other side
of a firewall if you do the following steps:
For each PATROL Agent defined to Agent Connection, specify the
number of the port (for example, 3181) on the PATROL EM server that
Agent Connection will use to connect to the PATROL Agent.
For Agent Connection:
• Set the connection protocol to UDP.
• Set the local port to a specific value (for example, 1999) so that
Agent Connection will use the port for all communications to the
Use the PATROL Integration Configuration Utility to change the protocol
and local port connection attributes or edit the filter_path.pet file and
change the values defined for the PET_CONNECTION_MODE
parameter and the PET_LOCAL_PORT parameter.
BMC Software, Inc., Confidential and Proprietary Information
8-58 PATROL Enterprise Manager Installation and Configuration Guide
For the firewall, specify
# Allow Source Destination
# |Deny IP/port/proto IP/port/proto
Deny //* //* # Default: deny all
Allow firewall// //* # From firewall
Allow agenthosts/3181/UDP cpserver/1999/UDP"
Also watch out for NAT'ing (network address translation) if you are using it as this can cause huge issues with Patrol ACL's etc ....
Not sure why the above says to use UDP , I personally would and do use TCP everytime over UDP.
the method of connectivity between CSC and AgentConnection is very different and requires a different approach for each in relation to firewalls as one is an upstream (pem initiated) and the other is downstream (agent initiated) I suppose you need to make your choice on which one your gonna go with as it would be more secure than using both,the golden rule of firewall admin is to only allow through what is required (so I hear).
If your network guys dont like you could always go up a level or two of patrol security to appease them.
It sounds like you have a pretty good 3 tier (central) setup there and are using relatively up to date versions , you might be better off adressing the "cloud freeze" issue you have had and going all the way with that method of connectivity rather than opening up a lot of holes for the two tier method.
Good luck !
We have some windows servers in DMZ location. This servers are not in domain as well as behind the firewall. Patrol agent in these servers are getting disconnected frequently with RT SERVERS and again getting connected.
Even in BMC Reporter the same issues are there, data is not getting generated properly for these servers.
Product Name/ Version / Patch : BMC Performance manger, Patrol agent version 3.7.40
Operating System : Windows 2k
Please help us on this.
Thanks & Regards,