Local Traffic Policy and forward to virtual not working

Hi,

Seems that there is some issue in version 12.0.0HF3. I switched back to 12.1.0 and magically virtual "name of virtual" targetIP, targetPort started to work.

Now traffic from source VS to Forwarding (IP) VS is using targetIP:Port set via virtual command instead of IP:port of source VS :-)

Piotr

Hi,

Here is overview:

• VS1 - Standard type working as a switching device - depending on some conditions traffic should be directed to different virtual servers, for example one working as explicit forward proxy with authentication and URL Filtering or to Forwarding (IP) type working as L4 firewall (AFM polices applied). Probably this VS1 could be as well explicit forward proxy type with proxy disabling using iRule commands depending on some devised logic.
• Issue with proxy request from client is that we know source IP:port but not target IP:port. Target IP port can only be evaluated after L7 processing via parsing HTTP request. I am doing it via iRule so I can use target IP:port for further processing.
• Now there is issue I am trying to solve - how to pass traffic to another virtual using retrieved target IP:port. If I will use virtual "name of target VS" traffic is passed but target IP:port is equal to IP:port of source VS.

Based on your post (as well as info from release notes of 12.0.0HF3 and 12.1.0) I tried to use this new syntax of virtual command - add retrieved target IP:port to the call: virtual "name of target VS" targetIP targetPort.

Problem is that whatever I tried to do target VS is always receiving traffic with target IP:port of sending VS instead of target IP, target port set in virtual command.

So either I am doing something wrong or there is some issue with this new syntax.

I am a bit puzzled by one sentence from new syntax description:

How I can specify name of the source server in iRule attached to this server? At least I understand above liket that. Shouldn't it be:

the name of the virtual server to redirect the connection to.?

Anyway I would really appreciate any example iRule that can pass traffic from one VS to another using specified IP and port. Example flow:

client -> proxyVS (proxy here is IP:port set in client browser, on BIGIP it can be any type of VS, not necessarily with explicit forward HTTP profile assigned), for example:

10.24.17.120:41234 -> 10.24.17.15:4141 (target server in proxy request 178.33.250.62:80)

proxyVS -> FirewallVS (for example Forwarding (IP) type with Destination set to 0.0.0.0/0)

10.24.17.120:41234 -> 178.33.250.62:80

FirewallVS -> target server (if AFM policy allows it based on src IP:port and dst IP:port)

192.168.75.242:41234 (SNATpool used) -> 178.33.250.62:80

The main issue in above flow is that traffic in step proxyVS -> FirewallVS is always passed like that:

10.24.17.120:41234 -> 10.24.17.15:4141

and of course connection is failing 😞

Hope it make any sense now...

Piotr

Hi,

Switched to 12.0.0HF3. Unfortunately it seems not to be working.

I am using virtual "name of virtual server" "IP of target server" "Port of target server" This is set in HTTP_REQUEST event.

Targeted virtual is ForwardIP type

Source virtual is Standard with explicit proxy HTTP profile attached. SNAT is set to external VLAN IP, Address/Port translation enabled.

Result is:

• If I am using snat none before virtual command traffic is reaching ForwardingIP VS with actual client IP. Target server IP is however still one of Standard explicit proxy IP: CLIENT_ACCEPTED; allow_all_interent_vs; Clientside; Conn: 10.24.17.120 to 10.24.17.15: 10.24.17.120 is client IP 10.24.17.15 is standard VS (source of VIP to VIP communication)
• If snat none is no used in iRule then traffic is indeed arriving at ForwardIP VS with snated client IP. CLIENT_ACCEPTED; allow_all_interent_vs; Clientside; Conn: 192.168.75.243 to 10.24.17.15 but still with the same target IP

So in both cases IP:port specified via virtual command is ignored.

What could be the reason? Should I place virtual command in other event? Should I use LB::reselect or LB::detach, or both - if so LB::detach first then LB::reselect?

On Standard VS (source VIP) I have such entries in log:

CLIENT_ACCEPTED; explicit_intercept_http_no_apm_vs; Clientside; Conn: 10.24.17.120:49294 to 10.24.17.15:5151. Src VS (from shared): No source VS
HTTP_PROXY_REQUEST; explicit_intercept_http_no_apm_vs; Clientside; AFTER calling resolv_fqdn_2 proc; Method: GET; URI: http://portquiz.net/; For target FQDN: portquiz.net; Target server: 178.33.250.62:80
HTTP_PROXY_REQUEST; explicit_intercept_http_no_apm_vs; Clientside; Conn: 10.24.17.120:49294 to 10.24.17.15:5151. URI: http://portquiz.net/; No PROXY URI: /
HTTP_REQUEST; explicit_intercept_http_no_apm_vs; Clientside; Conn: 10.24.17.120:49294 to 10.24.17.15:5151. URI: /; No PROXY URI: /
HTTP_REQUEST; explicit_intercept_http_no_apm_vs; Clientside; LB server SELECTED: "178.33.250.62 80", LB server addr: "178.33.250.62:80"
HTTP_REQUEST; explicit_intercept_http_no_apm_vs; Clientside; After virtual (via virtual command) set (/Common/allow_all_interent_vs) for target server (178.33.250.62:80): nexthop = unknown; unknown; ff:ff:ff:ff:ff:ff
LB_SELECTED; explicit_intercept_http_no_apm_vs; Clientside; LB server SELECTED: "0.0.0.0 0", LB server addr: "0.0.0.0"
LB_FAILED; explicit_intercept_http_no_apm_vs; Clientside; LB FAILED for VS (/Common/allow_all_interent_vs): "0.0.0.0 0", LB server addr: "0.0.0.0"

Piotr

Hi,

At least it seems to be step in right direction :-)

Any news when it will be implemented in 12.1.x?

Piotr

a change has been introduce to 12.0 HF3 and documented in the RN. This was done to address such issue.

could you try it somehow ?

560405-7 : Optional target IP address and port in the 'virtual' iRule API is not supported.

Component: Local Traffic Manager

Symptoms: In certain scenarios there is a need to redirect an HTTP request through a given virtual server to a another virtual server (or remote endpoint). Such an operation is also known as 'vip-to-vip' forwarding. The available iRule API (specifically, the 'virtual' command) does not currently support this functionality.

Conditions: Using an iRule to forward a request through a given virtual server to another virtual server or remote endpoint.

Impact: Cannot implement HTTP Forward Proxy plus Transparent redirection to Web-Cache Pool.

Workaround: None.

Behavior Change: The 'virtual' iRule API has been changed to support a secondary target IP address and port to redirect the connection to, from a given virtual server. The new signature of the 'virtual' iRule API is:

virtual [] [ []]

where:

• = the name of the virtual server to redirect the connection from.

• = the target IP address of the remote endpoint to route the connection to, through the specified virtual server;
  can also have a route-domain (%).

• = the port of the remote endpoint to route the connection to, through the specified virtual server.

Hello This is a known bug as of 12.0 : BUG 453354: “http explicit proxy doesn’t work when target is VIP on same box" . The explicit http proxy is doing dns resolution and goes direct to default gateway.