F5 BIG-IP connector

F5 BIG-IP is the reference load-balancer connector. Most legacy SOAP traffic in enterprise and government environments terminates on an F5 virtual server before reaching the SOAP backend, so the platform observes that traffic at the F5 edge and discovers the inventory from it.

A note on vendor names. This page names F5 BIG-IP because the product integrates with it. That is interoperability information, not a comparison.

---

What the connector does

| Side | Mechanism | |---|---| | Discovery | Services are discovered from the F5 traffic feed (front-end virtual server, front-end URI, resolved backend), enriched by the platform's discovery service. | | Ingest | F5 streams syslog to a Specaria relay that forwards normalized transaction records to the platform. | | Consumer attribution | A sample X-Client-IP iRule injects the real client IP at the F5 so the original consumer — not the F5 SNAT hop — is attributed. |

---

Traffic ingest via the relay

F5 forwards its syslog to a small relay running inside your VPC (a dedicated relay VM, or the equivalent local ingest container). The relay receives the syslog stream, normalizes each transaction, and forwards the records to the platform's ingest endpoint. Running the relay inside your network means the F5 never needs internet egress and the syslog feed stays on internal networking.

What is captured. For most F5 traffic the feed carries the request body, response body, request headers, and response headers — not just the request line. The raw ingest log receives all four artefacts per row when ingest is healthy, and they flow through into learned examples and the live-traffic drill-down.

The relay-VM container is image-pinned and refreshed as part of a worker deploy. If F5 traffic logs stop arriving after an upgrade, the relay image is the first thing to check — see the operations runbook. This is an operator-side concern, not an F5 configuration issue.

---

Sample X-Client-IP iRule

By default the F5 source-NATs traffic to its own address before forwarding to the pool member, so without a header-injection rule the backend (and the platform) sees the F5's SNAT IP for every request and per-consumer attribution collapses. Install this iRule on the SOAP virtual server to inject the real client IP:

# X-Client-IP-injection.tcl
# Apply to the virtual server's iRule list. Inserts X-Client-IP with the
# original client IP, removing any pre-existing copy first to prevent
# client-side spoofing.
when HTTP_REQUEST {
    HTTP::header remove "X-Client-IP"
    HTTP::header insert "X-Client-IP" [IP::client_addr]

    # Also append to X-Forwarded-For so downstream proxies see the full chain.
    if {[HTTP::header exists "X-Forwarded-For"]} {
        HTTP::header replace "X-Forwarded-For" \
            "[HTTP::header value "X-Forwarded-For"], [IP::client_addr]"
    } else {
        HTTP::header insert "X-Forwarded-For" [IP::client_addr]
    }
}

• IP::client_addr returns the original TCP-level source IP before SNAT translation — the value you want attributed to the consumer.
• The explicit remove before insert prevents a client from pre-populating X-Client-IP to spoof its source.
• HTTP_REQUEST fires once per request, before forwarding to the pool member.

---

Client-IP attribution and fallback

The platform resolves the consumer from the forwarded-header chain it inspects in order — X-Client-IP, X-Forwarded-For, then Forwarded (RFC 7239) — and takes the first candidate that is not the F5's own immediate-hop IP. JSON-array forms and the RFC 7239 for= syntax are parsed correctly.

Fallback. When no forwarded header is present, or every candidate equals the F5 SNAT IP, attribution collapses to the F5 hop. The transaction is still ingested and discovered — only per-consumer fidelity degrades. The tell-tale sign that the iRule is missing or misconfigured is that the "top consumers" breakdown shows the F5's SNAT address for everything. Installing the iRule above restores accurate attribution.

See Consumer attribution for the cross-vendor explanation.

---

Scope

The connector targets mainstream BIG-IP releases (12.x and newer) over HTTP/HTTPS. Very old firmware is handled as a targeted engagement rather than in the standard product — see Scope — the mainstream 80%.

---

Related

• Load balancers — the equivalent header-injection rule for Citrix, HAProxy, nginx, Kemp, A10, and Radware.
• Learned examples — how the captured F5 payloads become curated mapping evidence.

---

All Specaria SOAP to REST docs