Forum Discussion
NimbostratusF5 Proxy protocol irule support
One of our service is hosted in Cloudflare which is redirecting the request to our F5 LTM where the actual service is hosted.
By default when the request coming from cloudflare it is not sending the real client IP in the header and we need to see the real client IP in the F5.
As per cloudflare support they are using proxy protocol v1 and v2 to send the IP headers of real client IPs. We found the below irule in Devcenteral for proxy protocol receiver and we added that that in the LTM. However this irule is not working for us as expected. When we apply this irule we are not seeing any logs for Proxy v1 or proxy 2. This VS is configured with Client and Server SSL with an APM policy.
https://devcentral.f5.com/s/articles/proxy-protocol-receiver
Could someone confirm this irule will work with client and server SSL terminated on F5, and how to see the actual header details sent by Cloudflare.
Also any modification required in the irule to capture the proxy protocol headers.
7 Replies
- boneyard
MVP
wouldnt using this be easier?
https://support.cloudflare.com/hc/en-us/articles/206776727-What-is-True-Client-IP-
Injazat-SOCUnfortunately we dont have the true client IP option for our application. The option we have now is to use proxy protocol v1 or v2.
When we apply the proxy protocol receiver irule the published service is not working, however when we allow no proxy in the irule it works. It seems LTM is not receiving the proxy protocol as applied in the irule hence it is resting the connection. Even when the service works with no-proxy option we are not getting real client IP details. If we can get answers for the below it may help us to narrow down the issue.
- Why the LTM is not able to intercept proxy protocol, is there any issues with irule?
- How to confirm that LTM is receiving the proxy protocol header (Cloudflare confirmed that they are sending proxy protocol v1)
- How to get the real client IP using proxy protocol
- boneyard
so you have enabled proxy v1 or v2 in cloud flare as described here?
https://developers.cloudflare.com/spectrum/getting-started/proxy-protocol/
have you check the traffic at the F5 with a packet capture to determine it is actually send?
and why exactly cant you enable the true client IP header?
have you checked the ltm log when you have the iRule applied? is anything logged?
- Injazat-SOC
We enabled proxy protocol v1 in cloudflare and the irule which we applied supports both V1 and V2.
When we check the LTM logs it always throws the below logs
"Connection rejected from [IP::client_addr]:[TCP::client_port] due to lack of PROXY protocol header"
And when we allow no-proxy we receive the below logs
log "Connection from [IP::client_addr]:[TCP::client_port] allowed despite lack of PROXY protocol header"
It never hit the proxy protocol v1 or V2
Now how can i confirm whether we are receiving the proxy protocol v1 in LTM, As per the packet capture with that irule applied after initial 3-WAY handshake client hello was sent and VS IP reset it.
Please suggest how to verify proxy protocol header details in packet capture.
It seems the subscription we are using is not allowed to use true-client IP feature.
- boneyard
with the irule on no-proxy i assume you dont get a reset after the client hello?
if you do, do you have a HTTP profile on your virtual server? not quite sure that profile with work if you insert non standard HTTP things.
there is no chance to have cloudflare talk unencrypted to your BIG-IP as a test. then you could easier packet capture
you can try to print the TCP payload which should contain the word proxy, i.e. [TCP::payload 0 5] in your allowed despite lack of ... section.
- Injazat-SOC
Yes, with no proxy the service works.
We do have http profile applied in that VS with
X-forward enabled,
redirecr-rewrite: matching and
HTTP strict transport security : enabled
- boneyard
is there a chance to have cloudflare talk unencrypted to your BIG-IP as a test. then you could easier packet capture.
you can try to print the TCP payload which should contain the word proxy, i.e. [TCP::payload 0 5] in your allowed despite lack of ... section.
