ERA server behind an AWS ELB

[liabtsab 0]

Has anyone gotten this setup to function properly? Here's a summary of my current configuration:

On Windows host running ERA server:

- removed the server connector from the server.xml tomcat config file
- uncommented the HTTP connector from the server.xml tomcat config file
- in the HTTP connector section, added the attributes scheme="https",proxyName="route 53 CNAME record", proxyPort="443"

On AWS:

- Created two security groups, one for the ERA instance and one for the ELB
- ELB security group allows all traffic from ports 443 and 2222 (no outbound restrictions)
- ERA instance security groups allows traffic from port 443 and 2222 from the ELB security group
- Listener rule on the ELB set to forward incoming 443 traffic to the ELB to ports 8080 on the ERA instance
- Another listener rule on the ELB set to forward incoming 2222 traffic to the ELB to port 2222 on the ERA instance
- Added the ERA instance to the ELB and adjusted the healthcheck to ensure healthy state
- Created a route 53 Alias that points to the ELB dns hostname and which is also equal to the proxyName set in the HTTP connector section inside of Tomcat

So as-is, everything "works". Traffic is flowing, agents are able to check in over the internet. The only remaining issue i'm noticing is every now and then the web console errors out with a "failed to retrieve data. Session invalid" message. When this happens, it'll auto log me out of the console and i have to wait several minutes before I can log back in. I found a small page in the KB articles saying if a session from an IP is invalid for 15 attempts this occurs. Not really sure how to fix this and as far as i can tell, the IPs given to an ELB are dynamic and always changing. I don't know if this IP change is whats causing the issue, but when we run it with the ELB and have SSL terminate at the tomcat level, everything is fine. 

We don't want to do this because it detracts from our standard setup and it doesn't open up our ERA server over the internet so our remote users can check-in their machines. It's also a nghtmare to try and track down users in different timezones every so often to have them hop on the VPN for the checkin to occur since most of them don't really need access to internal resources to do their job...If anyone has gotten this to work, please share.

[MartinK 378]

On 10/28/2017 at 4:52 PM, liabtsab said:

So as-is, everything "works". Traffic is flowing, agents are able to check in over the internet. The only remaining issue i'm noticing is every now and then the web console errors out with a "failed to retrieve data. Session invalid" message. When this happens, it'll auto log me out of the console and i have to wait several minutes before I can log back in. I found a small page in the KB articles saying if a session from an IP is invalid for 15 attempts this occurs. Not really sure how to fix this and as far as i can tell, the IPs given to an ELB are dynamic and always changing. I don't know if this IP change is whats causing the issue, but when we run it with the ELB and have SSL terminate at the tomcat level, everything is fine.

Problem is that by default, ERA session is tied to one connection IP address (this is for security). When using load balancer, it is possible that multiple addresses are used and thus dropped sessions.

It is possible to change source of IP address detection via via ERA console configuration file, located inside tomcat webapps directory:

era/WEB-INF/classes/sk/eset/era/g2webconsole/server/modules/config/EraWebServerConfig.properties

using configuration parameter remote_address_source, which is documented directly in configuration file. In your case, use of HTTP header X-Forwarded-For should be sufficient. Be aware, that changing this parameter is not recommended, as it may reduce sessions hijack protection in case it is not configured properly.

[liabtsab 0]

@MartinK That's what I figured. I was trying to find where that option would be didnt know it was in that properties file. I ended up using x-forwarded-last since the available options were connection, x-forwarded-last, and x-forwarded-first. The last one being the least secure option. It seems to have fixed the issue. Not sure what the difference is between the two x-forwarded options so ill probably have to research a bit.

[MartinK 378]

54 minutes ago, liabtsab said:

@MartinK That's what I figured. I was trying to find where that option would be didnt know it was in that properties file. I ended up using x-forwarded-last since the available options were connection, x-forwarded-last, and x-forwarded-first. The last one being the least secure option. It seems to have fixed the issue. Not sure what the difference is between the two x-forwarded options so ill probably have to research a bit.

According to AWS documentation (not sure it is service you are using), client IP address is added at the end of list of IP addresses in header X-Forwarded-For. Seems you selected proper configuration type, but I would recommend to double-check, as otherwise you may missconfigure it in a way that this kind of security protection won't be working properly. IT is crucial that IP address selected from header is IP address of user, not IP address of some element inside your infrastructure.

[liabtsab 0]

yeah were using AWS and i took a second look at that document. Looks like the x-forwarded-for-last option does what you mentioned so i think we're good. Can confirm i no longer get the session disconnects. Thanks for the help!