For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

vf-mt_243104's avatar
vf-mt_243104
Icon for Altocumulus rankAltocumulus
Nov 07, 2017

Forwarding Traffic to URL rather than Pool

Hi,   In our current implementation of LTM, we create multiple virtual servers with each having it's own Policy. In the Policy, rules define domain based or URI path based requests, and forward to...
application delivery
BIG-IP
LTM
vf-mt_243104's avatar
vf-mt_243104
Icon for Altocumulus rankAltocumulus
Nov 08, 2017
Hi Henrik S,

What I tried implementing was by attaching as simple log in iRule to understand what's happening as follows: when HTTP_REQUEST { log local0. "server is currently at IP [RESOLV::lookup @8.8.8.8 "abc.com"]" }

 

I noticed I wasn't able to reach the Google DNS so I had to resolve to the local Domain DNS and reach the service through the firewall from there onwards.

 

I also found the following link useful https://clouddocs.f5.com/api/irules/resolv__lookup.html

 

and also to request traffic to the newly resolved IP: https://devcentral.f5.com/s/feed/0D51T00006i7RxBSAU

 

The SNAT looks interesting, however I didn't fully understand. Any Links that further explain this please?

 

If not you could probably leverage SNAT and create a pool with FQDN pool member. You can configure the LTM to auto populate and you can choose the interval that the LTM re-queries DNS. By default auto populate is on and re-checks once an hour. If an IP is not returned that was originally it will be removed and subsequently, if a new IP is returned it will be added.

 

Hi boneyard

as explained above, it seems like I had an issue reaching a public DNS.

 

After additional tests following the links mentioned above, I am now able to redirect to an IP after resolving the DNS name and also returning a 503 should the resolution or IP on the other end fail.

 

Thanks, Stefan