Forum Discussion

Piotr_Lewandows's avatar
Icon for Altostratus rankAltostratus
Jun 06, 2016

Local Traffic Policy and forward to virtual not working



Maybe not "not working at all" but for some reasons for some configs not :-(


I tried setup like that:


  • VS1 - Standard, wildcard with pool containing default gateway IP (not really relevant here), SNAT enabled, Address and port translation disabled
  • VS2 - ForwardingIP, wildcard

VS1 has LTP attached: forward to VS2


Client pointed at BIGIP selfIP as default gateway. Because VS1 has Source Address set to client IP VS1 is processing client request. From log it's obvious that traffic from VS1 is passed to VS2 then delivered to target server.


Setup like that is not working - forward to VS2 is completely ignored, traffic is passed directly to target server (same one as for first config)


  • VSProxy - Standard, Explicit forward proxy profile attached, no pool, SNAT enabled, Address and Port translation disabled
  • VS2 - same as above

VSProxy has same LTP attached


No traffic ever reaches VS2, client request is passed directly to target server. I know of course how VS with explicit proxy HTTP profile is working but can't understand why it's ignoring LTP and not forwarding traffic to VS2 - even if connection will not work then forward should not be ignored - but it is :-(


Sure there is Address/Port translation enabled but still...


When Address/Port translation is disabled on VSProxy connection fails completely but traffic is not hitting VS2 as well.


So either it's by design or it's kind of bug?




6 Replies

  • 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.


  • 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 [] [ []]


    • = 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.
  • Hi,


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


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




  • 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: to is client IP 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: to 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: to 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:; For target FQDN:; Target server:
    HTTP_PROXY_REQUEST; explicit_intercept_http_no_apm_vs; Clientside; Conn: to URI:; No PROXY URI: /
    HTTP_REQUEST; explicit_intercept_http_no_apm_vs; Clientside; Conn: to URI: /; No PROXY URI: /
    HTTP_REQUEST; explicit_intercept_http_no_apm_vs; Clientside; LB server SELECTED: " 80", LB server addr: ""
    HTTP_REQUEST; explicit_intercept_http_no_apm_vs; Clientside; After virtual (via virtual command) set (/Common/allow_all_interent_vs) for target server ( nexthop = unknown; unknown; ff:ff:ff:ff:ff:ff
    LB_SELECTED; explicit_intercept_http_no_apm_vs; Clientside; LB server SELECTED: " 0", LB server addr: ""
    LB_FAILED; explicit_intercept_http_no_apm_vs; Clientside; LB FAILED for VS (/Common/allow_all_interent_vs): " 0", LB server addr: ""


  • 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:

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

    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: -> (target server in proxy request

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

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

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

    and of course connection is failing 😞

    Hope it make any sense now...


  • 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 :-)