Proxy Protocol Initiator

In configurations where non-default Route Domains are used, IP::remote_addr and IP::local_addr get the %rd identifier appended to the IP address, which is invalid in the ha proxy protocol. In order to remedy this, you can use the getfield iRule function to strip off the %rd. Using this function should be ok whether or not Route Domains are in use. Here's how that looks:

set proxyheader "PROXY TCP[IP::version] [getfield [IP::remote_addr] "%" 1] [getfield [IP::local_addr] "%" 1] [TCP::remote_port] [TCP::local_port]\r\n"

This worked for me with smtp going to postfix. (See postfix configuration above)

We implemented the solution on a LTM 13.1 VLB and the Virtual Server stopped working with a "PR_END_OF_FILE_ERROR" shown in the browser. The LB is configured not to unload SSL.

The backend server logs does not have any entries so it looks like traffic does not reach the backend servers.

Inspection of logs in VLB /var/log does not show anything related. Are there other logs or tools we can use to see what is causing the Virtual Server to stop responding?

thanks

So far it works on BIG-IP 14.1.2.2 Build 0.30.4 

Has this been confirmed to work in BIGIP versions > 11.6?

If you're curious what this looks like in a packet capture where you do SSL re-encrypt on the virtual server, terminate SSL at the F5 then re-encrypt HTTPS to the pool members, the data is within a server side packet after the three way handshake with PSH and ACK flags set.

The data is hex encoded but if you right click the PSH,ACK packet and follow stream wireshark will decode it or you can use another resource.

Here's what the proxyheader looks like: PROXY TCP4 192.168.x.x 10.x.x.x 50299 443

This might be slightly more efficient than the original versions:

when SERVER_CONNECTED {
      TCP::respond "PROXY TCP[IP::version] [IP::client_addr] [clientside {IP::local_addr}] [TCP::client_port] [clientside {TCP::local_port}]\r\n"
}

They had me

reboot

Darren, that is surprising. Am I correct to assume you have the iRule attached to a Standard mode virtual server?

If so, I'd suggest opening a case with F5 support. While the cannot support the iRule code, the fact that you're getting this execution error on an event that is supported for TCP::respond should be something they can investigate.

We are trying to implement proxy protocol (for use with RabbitMQ AMQP) and have this irule:

when CLIENT_ACCEPTED{
    set proxyheader "PROXY TCP[IP::version] [IP::remote_addr] [IP::local_addr] [TCP::remote_port] [TCP::local_port]\r\n"
}
when SERVER_CONNECTED {
TCP::respond $proxyheader
}

But keep receiving a logged error:

TCL error: /Common/rabbitMQ_proxy_protocol  - Operation not supported (line 1) invoked from within "TCP::respond $proxyheader"

This page below says that TCP::respond is a valid command for SERVER_CONNECTED. Any ideas?

https://devcentral.f5.com/wiki/iRules.SERVER_CONNECTED.ashx

arun, the data you're providing in your first comment about not getting client IP addresses isn't clear. it'd be helpful to indicate what you are seeing via packet capture or something. Regarding FTP/SSL; I'm not sure I'd expect things to work in that scenario due to the special characteristics of FTP (two connections).