Deployed wrong policy with Replication Proxy settings, now clients cant replicate

[marlonanjos 0]

I mistakenly published a wrong policy with Replication Proxy settings set. Now my agents cant reach our ERA Server to download the new policy without the proxy settings.

There is any way to force agents to connect directly to the replication server? Or to reset settings and download new policies like a new install? 

ERROR: InitializeConnection: Initiating replication connection to 'host: "zzz.zzz.zzz" port: 2222' failed with: Request: Era.Common.Services.Replication.CheckReplicationConsistencyRequest on connection: host: "zzz.zzz.zzz" port: 2222 with proxy set as: Proxy: Connection: yyy.yyy.yyy:3128, Credentials: Name: , Password: ******, Enabled:1, EnabledFallback:0, failed with error code: 14, error message: Connect Failed, and error details:

Thank you in advance,

Marlon

[Marcos 3,631]

To my best knowledge the agent should fall back to direct connection if connection through the proxy fails. @MartinKwill confirm or correct me.

[marlonanjos 0]

@Marcos I had disabled fallback direct connection on the same policy 🙄

[MartinK 337]

 

42 minutes ago, Marcos said:

To my best knowledge the agent should fall back to direct connection if connection through the proxy fails. @MartinKwill confirm or correct me.

19 minutes ago, marlonanjos said:

@Marcos I had disabled fallback direct connection on the same policy 🙄data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==

@Marcos: Unfortunately in this case there is probably no fallback for HTTP proxy, as it was explicitly disabled, and also "replication" proxy was set, not generic/global proxy, where we silently count with possibility that it might not support replication connections.

In this case, probably only solution would be to repair installations, i.e. using AGENT installers. IS there no possibility to at least temporarily deploy HTTP proxy on "wrong" hostname/IP? Or redirect agents to other location via DNS changes? It would be probably easier ...

[marlonanjos 0]

7 minutes ago, MartinK said:

 

@Marcos: Unfortunately in this case there is probably no fallback for HTTP proxy, as it was explicitly disabled, and also "replication" proxy was set, not generic/global proxy, where we silently count with possibility that it might not support replication connections.

In this case, probably only solution would be to repair installations, i.e. using AGENT installers. IS there no possibility to at least temporarily deploy HTTP proxy on "wrong" hostname/IP? Or redirect agents to other location via DNS changes? It would be probably easier ...

@MartinK I tried a simple http/https proxy running on the same host/port and I can see traffic but with 403 code response. I need to do anything more to allow this connection?

"CONNECT eraserver:2222 HTTP/1.0" 403 226 "-" "grpc-httpcli/0.0"

Also tried to redirect from port 3128(proxy)->2222(era) but failed too.

 

[MartinK 337]

22 hours ago, marlonanjos said:

@MartinK I tried a simple http/https proxy running on the same host/port and I can see traffic but with 403 code response. I need to do anything more to allow this connection?

"CONNECT eraserver:2222 HTTP/1.0" 403 226 "-" "grpc-httpcli/0.0"

Also tried to redirect from port 3128(proxy)->2222(era) but failed too.

 

In case you used Apache HTTP proxy which is part of our installers, you should follow following steps: https://help.eset.com/esmc_install/72/en-US/apache_configuration.html where in short you have to:

• enable port 2222 in case it is not enabled already (depends on version you used)
• enable connections to your hostname (hostname where AGENT are trying to connect) - by default, only connections to ESET domains are enabled due to security, therefore using proxy for replication connections requires manual steps.

 

[marlonanjos 0]

Solved as per @MartinK solution.

I added the directive 

AllowCONNECT 443 80 2222

and also a proxymatch to my ERA Server hostname using the expression generated by https://support.eset.com/en/kb7214-write-a-proxymatch-expression-for-configuration-of-apache-http-proxy-with-esmc-7

to the file /etc/httpd/conf.d/proxy.conf, and restarted the service with

systemctl restart httpd

After that my agents can connect to my ERA Server through the apache proxy (usually used for updates) and replicate the new policies that removed the wrong settings of using proxy to ERA Server.

I will remove these changes as soon as all agents replicated.

Thank you @MartinK and @Marcos for your help.