outbound traffic for specific url by using specific IP

You would need a virtual server performing transparent http proxying... I dont think it's simple! If you can configure you nodes to use an HTTP proxy, then you could use a VIP+iRule that implement HTTP proxy. and which then would apply your logic to SNATing... I think.

Mohamed.

If you have a wildcard forwarding Virtual Server (that is, listening on 0.0.0.0:0), you may also create a wildcard port 80 VS (that is, listening on 0.0.0.0:80), the add the http profile and the following iRule:

when HTTP_REQUEST {
    if { [string tolower [HTTP::host]] equals "www.yahoo.com" } {
        snat 5.6.7.8
    }
}

Change 5.6.7.8 to the appropriate IP (or use a SNAT pool and the snatpool command. Assign your default SNAT (either AutoMap or the appropriate SNAT pool) from your wildcard forwarding VS to the new port 80 VS. That way, SNAT IP1 will be used for all traffic except that bound for www.yahoo.com. Make sure that both Virtual Servers are bound to only the VLAN from which your pool member traffic originates.

If you want to intercept SSL traffic, that is much trickier, because you would need to stand up an SSL forward proxy and the pool members would need to be provided a trusted internal signing certificate which signs for www.yahoo.com. It absolutely can be done, but is, as Mohamed says, not simple.

If you have a wildcard forwarding Virtual Server (that is, listening on 0.0.0.0:0), you may also create a wildcard port 80 VS (that is, listening on 0.0.0.0:80), the add the http profile and the following iRule:

when HTTP_REQUEST {
    if { [string tolower [HTTP::host]] equals "www.yahoo.com" } {
        snat 5.6.7.8
    }
}

Change 5.6.7.8 to the appropriate IP (or use a SNAT pool and the snatpool command. Assign your default SNAT (either AutoMap or the appropriate SNAT pool) from your wildcard forwarding VS to the new port 80 VS. That way, SNAT IP1 will be used for all traffic except that bound for www.yahoo.com. Make sure that both Virtual Servers are bound to only the VLAN from which your pool member traffic originates.

If you want to intercept SSL traffic, that is much trickier, because you would need to stand up an SSL forward proxy and the pool members would need to be provided a trusted internal signing certificate which signs for www.yahoo.com. It absolutely can be done, but is, as Mohamed says, not simple.

Oh, and consider using a Local Traffic Policy instead, if you are running 11.4 or higher:

• SOL15085: Overview of the Local Traffic Policies feature

You would still create the second (port 80 only) VS, but all of the logic above can be accomplished using a Local Traffic Policy attached to that second VS.

@Mohamed, assuming it is applied to a wildcard VS (destination is 0.0.0.0/0) it would leave the destination address unchanged (assuming that the address translation -- meaning destination translation -- field is unset). For delivery, the BIG-IP would follow its route table.

I think you are mixing up IP Forwarding VS behavior, with that of Standard VS. You can't have both.

Thanks, Mohamed.

Sorry that was not clear. To clarify: - You cannot use that iRule on an IP forwarding VS, because you cannot apply an http profile to it. - On a standard VS, where you can apply that iRule, you need a pool to serve http traffic from, or the iRule needs to implement transparent proxy behavior... Oh, this is a request for google.com, let's resolve that name in DNS, then lets get this request answered from that server.

Makes sense?

Thanks, Mohamed.

Naturally that is true for the forwarding Virtual Server (i.e., one may not apply an http profile to it), but it turns out that -- while it may seem somewhat counter-intuitive -- that assertion is not correct for Standard Virtual Servers. If there is no pool and (destination) Address Translation is disabled, it will forward using BIG-IP's normal routing (I just verified on 11.5.3 to make sure I was remembering correctly (: ). If you wanted to exert more control over the route direction, you may create a pool that contains gateways (routers) and still disable (destination) Address Translation. That will have the same effect (but use the gateways' routing rather than BIG-IP).

But a fair point, in any case. I was not explicit about using a Standard VS, and that is definitely confusing now that I'm reading back through my posts.

Thanks for clarifying... I tried to create such a VS, but for some reason it does not seem to be actually handling the traffic...Anyway, I would be interested to hear of this worked out for you John.

Thanks for clarifying... I tried to create such a VS, but for some reason it does not seem to be actually handling the traffic...Anyway, I would be interested to hear of this worked out for you John.