Skip to main content

Having a challenge configuring X-forwarding for multiple IP interface elastic load balancing. The service generates multiple load balancer IP addresses/interfaces and registers a DNS A record with all. I'm attempting to configure the RemoteIPValve x-forwarding on the JSS' and I've configured the "Enable Remote IP Valve" setting under Apache Tomcat Settings and edited the "server.xml" file on each JSS to include the RemoteIPValve element for internal and trusted proxies fields. However, the internal and trusted proxy addresses in the "server.xml" seem to only honor one IP address for a load balancer.

Example in server.xml:
<Valve
className="org.apache.catalina.valves.RemoteIpValve"
internalProxies="172.1.2.3"
trustedProxies="172.1.2.3"
remoteIpHeader="x-forwarded-for"
remoteIpProxiesHeader="x-forwarded-by"
protocolHeader="x-forwarded-proto"/>

DNS A record:
JSS.hawks.com has address 172.1.2.3
JSS.hawks.com has address 172.4.5.6

Testing with this configuration works when a connected client comes from the load balancer IP address I've entered in server.xml (172.1.2.3) but if it connects from the other load balancer IP (172.4.5.6) it will not pull the original client IP from the header and update JSS accordingly.

Has anyone come across a format to represent multiple proxy entries (IP address sources) in this element or any other solution?

Running 9.62 on RHEL7 and using elastic load balancing services for a pool of JSS'.

Regards,
DJ

should be able to use a regex expression or comma delimited value. might depend on the version of tomcat you are running.

https://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/valves/RemoteIpValve.html

Thanks, David. That did the trick with some modification for version 7 of Tomcat using a pipe delimeter. https://tomcat.apache.org/tomcat-7.0-doc/api/index.html?org/apache/catalina/valves/RemoteIpValve.html

<Valve className="org.apache.catalina.valves.RemoteIpValve" internalProxies="172.1.2.3|172.4.5.6" remoteIpHeader="x-forwarded-for" proxiesHeader="x-forwarded-by" protocolHeader="x-forwarded-proto" />

Although, as I'm finding with the nature of elastic LB the dynamic nature of IP's will break the whole process above with the static IP's. I see in version 8 of Tomcat they allow for "172.16/12" subnet mask for the internalProxies entry. Have to test if a Tomcat upgrade will work with JAMF 9.62. Or I deploy my own BigIP and go with traditional LB.

Cheers!

Hey @dsepton , sorry to bump an old thread but we're encountering a similar situation where enrollment via QuickAdd.pkg fails due to our Amazon Elastic Load Balancer. NSLookup of our ELB DNS Name resolves 2 different IPs (it will change periodically as Amazon have many IPs for their Elastic Load Balancers).

During installation of QuickAdd, I figured out from wireshark logs that it's trying to communicate to 1 IP initially, then change to the 2nd IP midway and cause the installation to fail.

I suspect I will need to use the RemoteIPValve as well for our Tomcat 7. However, like your post, the "internalProxies=" switch requires IP addresses and/or a series of subnet masks, and I cannot use DNS Name of our ELB.

Did you have any luck configuring JSS to be behind an ELB?

Regards,
Norman

Hi Norman,

I have configured a pool of JSS' behind AWS ELB. I used the RemoteIPValve configuration in server.xml with the network range defined by a regular expression. You will want to substitute the network range below in "internalProxies" to your own AWS subnet range behind the ELB.

Here is a sample RemoteIPValve tag that I have before my closing host tag:

<Valve className="org.apache.catalina.valves.RemoteIpValve" internalProxies="172.(?:1[6-9]|2[0-9]|3[0-9]).d{1,3}.d{1,3}" remoteIpHeader="x-forwarded-for" remoteIpProxiesHeader="x-forwarded-by" protocolHeader="x-forwarded-proto" />

The above expression gives the possibility of 172.16-39.0-999.0-999 source IP's from the load balancer (of course, IP's won't come back >254 on the last two octets)

There is a regex tool to test and validate expressions at https://regex101.com

Terms & ConditionsCookie settingsAccessibility statement