Forum Discussion
Racquel_Mays
Employee
EmployeeUse LTM Policies to Create a VIP listening on Specific Ports
All, we are moving from A10 to F5 LTM. With A10 we have 1 VIP, and up to 4 "service-groups" or pools serving 4 specific ports. My goal is to provide a similar functionality in the LTM using Local Traffic Policy-not iRules [solely]. I understand, with LTM it's common or 'best' to have multiple VIPs; one for each service. However, our fear it that this will become a challenge to manage.
In testing the policies, I find that it works partially, so long as the VIP's IP matches one of the ports on the data-group configured in the policy. The question is, "How should the VIP be configured, along with a policy, which states it should listen on multiple ports?"
#facepalm...notice the hidden option on the tcp port:
mine was remote by default, changing to local fixed the issue. Working policy that should help:
ltm policy allports_testpolicy { controls { forwarding } last-modified 2021-02-10:16:42:35 requires { tcp } rules { tcp-80 { actions { 0 { forward client-accepted select pool nerdlife_pool } } conditions { 0 { tcp client-accepted port local values { 80 } } } } tcp-8080 { actions { 0 { forward client-accepted select pool nerdlife_pool } } conditions { 0 { tcp client-accepted port local values { 8080 } } } ordinal 1 } tcp-all-else { actions { 0 { shutdown client-accepted connection } } conditions { 0 { tcp client-accepted port local not values { 80 8080 } } } ordinal 2 } } status published strategy first-match }
- Daniel_Wolf
MVP
There are several ways to satisfy your requirements. I will skip all the "iRule ways", since they are not interesting for you.
As stated, you VS should listen on port 0. The LTM Traffic Policy should have default rule, like a firewall, at the end. To reject all traffic that wont match rules above.
- JRahm
Admin
If you need the virtual server to listen on more than one port, the port should be configured as 0. If you are asking something else, please provide more details and I'll do my best to point you in the right direction.
Racquel_MaysThank you so much for you help. Im going to configure based on your suggestions and update.
- Racquel_Mays
Hello, I configured the policy. I have the pool members serve a simple web page, so I know end-to-end communication works. However, when I apply the policy I no longer get the page. However, using curl, I see that I get connected to the VIP along with GET. Instead of giving 200 OK, I get:
curl: (56) Recv failure: Connection reset by peer
* Rebuilt URL to: http://{IP Redacted}/ * Trying {IP Redacted}... * TCP_NODELAY set * Connected to {IP Redacted} ({IP Redacted}) port 80 (#0) > GET / HTTP/1.1 > Host: {IP Redacted}. > User-Agent: curl/7.54.0 > Accept: */* > * Recv failure: Connection reset by peer * stopped the pause stream! * Closing connection 0 curl: (56) Recv failure: Connection reset by peer - Racquel_Mays
Here is what I configured, for reference.
- Daniel_Wolf
Ok, one step backwards. Many questions.
Did you configure health monitors? Do they show green?
Did you try curl from the F5 to the backend? Does that work?
Did you apply a server-side SSL profile to the VS?
Did you configure SNAT on the VS?
Can you run a tcpdump with -i 0.0:nnnp to see the reset cause?
- Racquel_Mays
Hello,
- Did you configure health monitors?
- Health monitors on the pool ; pools are Green
- Curl from the F5 to the backend
- works, to individual pool members
- Did you apply a server-side SSL profile to the VS
- No
- Did you configure SNAT on the VS
- Yes
- Resets are coming from the Virtual Server IP, itself.
- Did you configure health monitors?
- JRahm
Do you have a clientssl profile attached to your virtual server? if so, you either need to enable Non-SSL Connections in the clientssl profile, or you need to set up your tcp port 80 rule in the policy to disable clientssl on client accepted.
- Racquel_Mays
No, I dont have a clientssl profile on that vip. Its http, so I didn't think i would need it. Do I need it?
- JRahm
if you have no ssl, then no. But if you are trying to serve a combination, yes.
I've been testing some different policy options and am also having issues getting it to work, whereas my very simple irule is working fine;
when CLIENT_ACCEPTED { switch [TCP::local_port] { 80 - 8080 { pool nerdlife_pool } default { reject } } }I cannot seem to achieve the same in my policy, I get resets regardless. I'll have to do some research.
- JRahm
#facepalm...notice the hidden option on the tcp port:
mine was remote by default, changing to local fixed the issue. Working policy that should help:
ltm policy allports_testpolicy { controls { forwarding } last-modified 2021-02-10:16:42:35 requires { tcp } rules { tcp-80 { actions { 0 { forward client-accepted select pool nerdlife_pool } } conditions { 0 { tcp client-accepted port local values { 80 } } } } tcp-8080 { actions { 0 { forward client-accepted select pool nerdlife_pool } } conditions { 0 { tcp client-accepted port local values { 8080 } } } ordinal 1 } tcp-all-else { actions { 0 { shutdown client-accepted connection } } conditions { 0 { tcp client-accepted port local not values { 80 8080 } } } ordinal 2 } } status published strategy first-match }- Racquel_Mays
This looks great! Testing now. Will update.
- Racquel_Mays
It's working! I'm doing the fine tuning that Daniel spoke now. Great work. Also. Are you the one of the "F5 YouTube Stars"? You look like one of them :).
- Racquel_Mays
In looking at this setup. SSL and non-SSL traffic will use the same VIP. I found a vulnerability, K21942600. What are the security concerns?
- JRahm
implementing the workaround should cover you on traffic that should be encrypted. for the intended non-ssl traffic, that shouldn't factor into the scenario.
And yes, I do a fair amount of youtube stuff for DevCentral, though I will walk away from any "star" talk 😀
- Racquel_Mays
Thanks, again.
