Forum Discussion
Kevin_Nail
Nimbostratus
NimbostratusSnat Pool Question
Hi,
We have a unique design in which our LTM has no internal subnet... instead everything flows out through the core router... to accomplish this we had to create a SNAT pool and SNAT all incoming connections to the VIP so that when the LTM load-balanced the request and sent it back out, it would come back to the LTM...
Problem: Siteminder protected applications are experiencing problems with this because when clients click on another part of a page.. the SNAT IP could change and thus breaks the SMSESSION cookie.
Question: Is there a way to make a SNAT pool selection stick so that it always uses the same IP until the connection is closed?
Thanks for the help.
strongarm_46960From your description, can I assume that your Siteminder is being protected by LTM or is it the other way round?, if it’s the former, then just setup SMSSESSION cookie based persistence with perhaps fall back on client source IP on LTM profile, and associate it to the Siteminders VIP, thus ensuring stickiness.
Kevin_NailCorrect. Our Siteminder policy servers are behind the LTM. I'll give your suggestion a try- Kevin_NailBTW, is there such a cookie persistence in LTM. You mentioned setting the SMSESSION cookie based persistence. How is this done? with an iRule or is it just cookie based persistence?
Thanks,
Kevin - strongarm_46960in the Local Traffic, goto Profiles,
click on the Persistence tab, click create ,
give a name such as smscookie,
sellect cookie within the list.
Sellect Prefared cookie method.
give cookie name to show the world.
Expiration ==> click on the session cookie
click finished - Kevin_NailYep, I got the setup correct... but my problem is that the IP presented to the Siteminder policy will change based on the SNAT pool.... I need to be able to present the true client_ip to the policy server on a one-armed LTM setup whil still ensuring that return traffic comes back throught the LTM... Don't know if this can be done or not...
- strongarm_46960I see, what you need in that case is to enable the the "X-Forwarded-For" header in the http profile of your VIP.
You can also do the same thing using iRule below and then associate the iRule with the VIP, this iRule will basically insert a new header called X-Forwarder-For into your users HTTP Request Header:
when HTTP_REQUEST {
HTTP::header insert "X-Forwarded-For" [IP::client_addr]
}
You’ll then be faced with the small problem of how to extract the client IP from this new header called X-Forwarder-for into your backend server logs, there are two ISAPI filter solutions if you are using IIS, one solution originates from MS MSDN and the other from F5’s Joe.
If you are using Apache then its easier to extract than IIS. Do a search for IIS X-Forwarded-for in Devcentral for these extraction solutions.