Showing posts with label WEBGATE 12C. Show all posts
Showing posts with label WEBGATE 12C. Show all posts

Monday, 15 February 2016

Enabling IP Validation in Load Balancer Environment using ProxyTrustedList & ProxyRemoteIPHeaderVar in OAM 11g

Why we are discussing this topic?

  • It is important to understand the configuration required to be done in OAM for validating the IP addresses when the application server is behind the proxies.

What difference will it make if app server is behind the proxy?

  • The client ip calculation will be different if proxy is present.

How client ip is fetched in OAM/Webgate?

  • remote_addr contains the client ip, in case of proxy this remote_addr will have the last proxy IP Address.

How can i than validate the IP in this scenario where proxies are used?

  • For such scenario we have to configure 2 user defined parameters in Webgate Profile:
    • ProxyRemoteIPHeaderVar = <by default it is set to HTTP_X_FORWADED_FOR>
    • ProxyTrustedIPList = <list of comma seperated IP Addresses>
  • Along with these parameter we need to set the IP Validation flag in webgate profile.

How remote_addr & x_forwaded_for header are related?

  • Remote_addr: Actually it contains the IP address of the client in general. But in scenarios where proxies are involved, this remote_addr conatins the last proxy IP Address.
  • HTTP_X_FORWARDED_FOR: header is a common method for identifying the originating IP address of a client connecting to a web server through an HTTP proxy or load balancer.

Considering the scenario such as:

Client -> Proxy1 -> Proxy2 -> OHS Server(having Webgate)
 
Thus in this scenario, the headers contains following values;
  • REMOTE_ADDR = Proxy2 IP
  • HTTP_X_FORWARDED_FOR = Client IP, Proxy1 IP

So how the ProxyTrustedIPList is to be configured?

  • This parameter should have all the proxies IP Addresses that are present in the deployment or production environment.

How HTTP_X_FORWADED_FOR & ProxyTrustedIPList co-relates?

The IP Addresses present in x_forwaded_for header are backtracked against trustediplist & when the Ip is not found in TrustedList than that is considered to be the client ip.

Consider the scenario:
Client -> Proxy1 -> Proxy2 -> OHS Server(having Webgate)

Headers:
  • HTTP_X_FORWADED_FOR = ClientIp, Proxy1
  • REMOTE_ADDR = Proxy2
Configuration:
  • ProxyTrustedIPList = Proxy1, Proxy2

 
Enjoy :-)

Tuesday, 20 October 2015

OAM - Webgate NAP Tunneling in OTD (R2PS2, R2PS3 & 12C)

As of now we all are aware how to tunnel a request to OAM through webgate, also we have covered this in Webgate NAP Tunneling.

But there is a catch or you can say you need to do one more step to enable NAP Tunneling when using OTD (Oracle Traffic Director) Server.

I am assuming you have followed all the steps that are mentioned in Webgate NAP Tunneling post. At the very last you need to perform one more step i.e. only for OTD;

  1. To enable NAP Tunneling in OTD, one needs to uncomment a line mentioned in
    <instance_name>-obj.conf file which is as follows;

    #Uncomment the below line  and  configure "from" paramater for enable
    tunneling.  The value of from parameter would be the tunneled URLS
    #NameTrans fn="pfx2dir" from="/oam" dir="/webgate/otd/lib"
    name="webgate_response"


    Above line need to be uncommented, to make nap tunneling enable.
    After doing above change one needs to restart the OTD instance.

    Note
    1. This configuration change, to enable NAP Tunneling, is their since
      R2PS2(with a BP Patch),R2PS3 which is the same carried forward to latest release i.e. 12c as well..
    2. In the change suggested above you will find the tunneled urls, that you need to provide here by default it is /oam. But it might be possible you want to tunnel /oamfed as well.. or any other. So all the tunneled urls are to be provided here as well.


Enjoy :-)