Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 7 replies
  • Subscribers 0 subscribers
  • Views 29275 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RMS issue - clients update just fine but do not report to SEC

asester

All,

It appears that after a recent update on 4/21/15 for the Sophos Update Manager on our message relay server, external clients are no longer reporting in SEC.  They are able to update as usual, but nothing reports to SEC.

After doing some digging, looking at the MRInit.conf files, policies, tearing my hair out, etc.....I think I see the issue - just not sure how to resolve it.

In the SEC application, I can see the primary server and the message relay both have the latest Update Manager version > 1.5.6.13.

However, looking at the Programs installed on the message relay server through control panel, it is not showing the proper version installed.  It shows 1.5.2.1060, whereas the primary server shows the proper 1.5.6.13 version.

I tried to run a repair on the Sophos Update Manager application on the message relay server via control panel, but that didn't change the version.  When I force an update through SEC, it downloads the binaries and appears like it's still at the latest version...

Also, using 5.2.2 on server 2008 R2.

Any help is appreciated.

:57312


This thread was automatically locked due to age.
Parents
  • 0

    Thanks for the article link Christian.  I compared the registry entries and they match.  I went ahead and ran configcid.exe again, and it ran successfully, but still not relaying messages.

    I should state this caveat - if the remote client hits our VPN, it appears it is then able to relay and shows up in SEC.

    More background on my setup:

    Primary SEC (internal DMZ 10.x.x.x)

    Message Relay Server (internal DMZ 192.x.x.x, NAT'd out for remote updating)

    It has been working fine for about 2 years.  I manage the firewall as well, so I can tell you the proper ports are for sure open.

    So, after seeing that the external clients that come in through our VPN end up communicating with the Message Relay Server, that led me to look at the netstat and local firewall logs.  In the local machines firewall logs, I can see the communication happening to the proper NAT'd IP address, but what's interesting is when I run a netstat, it shows the 8194 port connection attempt to the internal 192.x.x.x IP, not the NAT'd IP.  Obviously it cannot hit that IP from where it's at, so why is it displaying that?  Is there some sort of NAT translation happening and that's a normal occurance?  I would think it would be trying to establish the 8194 communication through the external NAT...

    I confirmed the MRINIT.conf file is set to the proper parent and MRparent addresses.

    Looking at the message router log on the client, I noticed this:

    While not on the VPN:

    -RMS router name:  Router$(PC name):279132

    -IOR port number: 8192

    -SSLIOP port number: 8194

    -Parent addresses: x.x.x.x (NAT'd IP), FQDN, Server name (this is all correct)

    -Current parent address:  Not available

    -RMS router type:  endpoint

    While on the VPN:

    -RMS router name:  Router$(PC name):279132

    -IOR port number: 8192

    -SSLIOP port number: 8194

    -Parent addresses: x.x.x.x (NAT'd IP), FQDN, Server name (this is all correct)

    -Current parent address:  x.x.x.x (NAT'd IP)

    -RMS router type:  endpoint

    While on the VPN it fills out hte current parent address field in the report, but while off the vpn it is unknown.  Not sure if this is relevant, but I figured I'd throw it out there.

    Thanks again for the assistance.

    Adam

    :57330
Reply
  • 0

    Thanks for the article link Christian.  I compared the registry entries and they match.  I went ahead and ran configcid.exe again, and it ran successfully, but still not relaying messages.

    I should state this caveat - if the remote client hits our VPN, it appears it is then able to relay and shows up in SEC.

    More background on my setup:

    Primary SEC (internal DMZ 10.x.x.x)

    Message Relay Server (internal DMZ 192.x.x.x, NAT'd out for remote updating)

    It has been working fine for about 2 years.  I manage the firewall as well, so I can tell you the proper ports are for sure open.

    So, after seeing that the external clients that come in through our VPN end up communicating with the Message Relay Server, that led me to look at the netstat and local firewall logs.  In the local machines firewall logs, I can see the communication happening to the proper NAT'd IP address, but what's interesting is when I run a netstat, it shows the 8194 port connection attempt to the internal 192.x.x.x IP, not the NAT'd IP.  Obviously it cannot hit that IP from where it's at, so why is it displaying that?  Is there some sort of NAT translation happening and that's a normal occurance?  I would think it would be trying to establish the 8194 communication through the external NAT...

    I confirmed the MRINIT.conf file is set to the proper parent and MRparent addresses.

    Looking at the message router log on the client, I noticed this:

    While not on the VPN:

    -RMS router name:  Router$(PC name):279132

    -IOR port number: 8192

    -SSLIOP port number: 8194

    -Parent addresses: x.x.x.x (NAT'd IP), FQDN, Server name (this is all correct)

    -Current parent address:  Not available

    -RMS router type:  endpoint

    While on the VPN:

    -RMS router name:  Router$(PC name):279132

    -IOR port number: 8192

    -SSLIOP port number: 8194

    -Parent addresses: x.x.x.x (NAT'd IP), FQDN, Server name (this is all correct)

    -Current parent address:  x.x.x.x (NAT'd IP)

    -RMS router type:  endpoint

    While on the VPN it fills out hte current parent address field in the report, but while off the vpn it is unknown.  Not sure if this is relevant, but I figured I'd throw it out there.

    Thanks again for the assistance.

    Adam

    :57330
Children
No Data
Unfiltered HTML