AltostratusHello All,
Can we configure an iRule for non http services? I have a VIP configured on port 491 with 3 Pool which I am trying to manage using irule but traffic is not hitting irule.
when HTTP_REQUEST {
if { [HTTP::uri] starts_with "/URI1" }{
pool QA_URI1_491
} elseif { [HTTP::uri] starts_with "/URI2" }{
pool QA_URI2_491
} elseif { [HTTP::uri] starts_with "/URI3" }{
pool QA_URI3_491
}
}
Thanks,
EmployeeOne thing to note about the pcap, this MAY still actually be HTTP traffic. However, because this is running on a non-standard port for HTTP, Wireshark will not automatically decode it as such. In Wireshark you can right click on one of the packets in question and select "Decode As.." and select HTTP. If that doesn't work, then I would try decoding as SSL/TLS.
Let us know the results of that.
EmployeeActually, a quick review of the Proficy Webspace Server documentation (https://www.ge.com/digital/documentation/webspace/oxy_ex-1/topics/t_ifix_web_space_modifying_the_host_port.html ) suggests that this is indeed web traffic (since this same server/application is accessible via a browser client) and almost defintely SSL traffic.
If that is indeed the case, you can likely still use an iRule with the HTTP events/commands but you will need install the Webspace server SSL certificate and key on the BIGIP so you can decrypt there.
AltostratusHello Joseph_Martin, Thanks for the response !
I am unable to decode any of the packet either in http or SSL/TLS. It is not giving me option to decode.
Thanks,
EmployeeSo when you right-click on a packet you don't have the "Decode As..." option like this?
Cumulonimbusyes, irules is not limited to http
https://clouddocs.f5.com/api/irules/
however, from your irules it seems it is http based service though not on port 80.
http does not always use port 80
the virtual server needs to have http profile to have http realted irules works
instead of irules scripting, you can also use gui based traffic policy
https://techdocs.f5.com/en-us/bigip-15-1-0/big-ip-local-traffic-management-getting-started-with-policies/introducing-local-traffic-policies.html#GUID-A29C4871-6F8C-4230-8A8D-1F746120488E
MVPndubey2 I would definitely make sure you have the pieces configured that zamroni777 mentioned. In addition, you might try the following iRule instead because your URI path could not match the case exactly and the following will ignore case.
when HTTP_REQUEST priority 500 {
set URI [string tolower [HTTP::uri]]
if { ${URI} starts_with "/uri1" }{
pool QA_URI1_491
} elseif { ${URI} starts_with "/uri2" }{
pool QA_URI2_491
} elseif { ${URI} starts_with "/uri3" }{
pool QA_URI3_491
}
}
AltostratusHello Paulius zamroni777 thanks for the response. Regarding http profile, I have already applied it. One thing I would like to tell you that this application is not being access via web browser, it is being accessed via a desktop application so not sure if that would be considered http traffic or not.
I will try iRule shared by Paulius as well to check if this resolve the issue.
I checked sys connection as well and it is showing any6.any any6.any after traffic hitting the VIP but no traffic showing on iRule.
Altostratuscould anyone please reply? I am stuck ina deployment.
Thanks,
MVPndubey2 You are 100% positive that the virtual server is being hit? It shouldn't matter if it's browser based or application based, the only thing that really matters is the protocol being used for the application to function. Your best bet is to first confirm that your traffic is indeed hitting the virtual server in question. You should be able to run the following tcpdump which will save to a file located in directory "/shared/tmp/" and is named "mycap.pcap" which can be exported and opened in wireshark.
tcpdump -nni 0.0:nnp host <VS_IP> -w /shared/tmp/mycap.pcap
If for some reason after this you see traffic hitting the virtual server in question referencing the F5 information saved in each packet you will then want to confirm that it is indeed HTTP traffic. If this isn't HTTP traffic then your iRule will not work. If this is going over HTTPS you will want to ensure that you are performing SSL termination on the F5 in order for it to look at the HTTP header.
AltostratusYes, I am 100% sure traffic is hitting the VIP. I saw it in sys connection tcp dump as well. Below is the scenario.
There is an app on user desktop which is using content C:\Program Files (x86)\Proficy\Proficy WebSpace Client\Client\Proficy.exe -h VIP -f 0 -a URI2" to access the application on LB.
As there are three different pool serving different service, I didn`t call any of the pool in VIP resources instead I am applying iRule while when I remove the iRule and call a dedicated pool under VIP resource, that perticular application start working.
Hope, it gives you more clarity about the requirement and troublwhooting I have done till now.
Thanks,
MVPndubey2 I recommend performing that tcpdump and inspecting the requests to ensure that your requests are arriving as an HTTP protocol request with the associated HTTP header fields. If those fields do not exist then the iRule will not work. Notice in the following image the GET defined with the associated path and HTTP version.
AltostratusIn my case, I am only getting tcp protocol.
Tried below iRule as well.
when CLIENT_ACCEPTED {
if { [TCP::local_port] eq 491 } {
if { [TCP::payload] contains "URI1" } {
pool QA_URI1_491
} elseif { [TCP::payload] contains "URI2" } {
pool QA_URI2_491
}
}
}
MVPndubey2 In order to do what you want I believe you would have to convert each string to binary and then search for that binary value to make a decision. Sadly I haven't had the opportunity to perform this type of iRule so I don't really have much more direction other than converting the respective strings to binary and making the match that way.
AdminHi ndubey2 , reviewed the thread and i'm not clear on a couple things:
If you have a pcap of a sample transaction from client directly to server you can DM me, I'd be happy to take a look. Make sure to sanitize any credentials or IP. If mqtt, we can probably make this work pretty easily, though it'll be a learning process for both of us because i haven't done much with it yet. If not, what Paulius said is likely and you'll need to do a binary decode of the messages in the TCP data.
AltostratusHello JRahm, Thanks for the response !
Below is the sanswer of your query.
Please find the pcap data. Hope, this will help you to understand the communication. Ip ending with 54 is client and Ip ending with 133 is server.
Thanks,