Forum Discussion

ToonVA's avatar
ToonVA
Icon for Cirrus rankCirrus
Jan 31, 2022
Solved

Forward traffic based on TCP Port - LTM Policy

Hi All, i try to troubleshoot a configuration i can't get working and could use some input here. 
So we have 5 Virtuals all on the same public IP but different ports (20, 21, 22, 990 and 0). The Virtuals are used for filetransfer application and the problem is sitting on the port 0 config. On this one we have a LTM Policy defined that the port needs to be in the range of 1024-1048 or otherwise we send a reset. The idea behind is that FTP transfer is started on the port 21 virtual, then uses a passive port in this range off 1024-1048 and so entering the virtual on port 0. From my view this seems all to be configured correctly but it doesn't work and when taking a TCP Dump we can see in our trace that the traffic is reset by F5 due to the policy.

So at this point it seems that our definiation of the portrange doesn't work and so by default the traffic is reset. I can't seems to figure out what goes wrong and we don't want to use iRules (we know they can do the same) for company reasons. 

I did already some googling myself but there don't seem to be many similar configurations. To rule out if the matching port criteria were the issue we added all of them in the policy list with the same result. Also in one of the articles further down below they mention to modify the local side of external interface to make it working but we all tried this (even all 4 options) but the result remains the same. At this point i am thinking more in the direction of a bug but i can still be wrong in the logic here...

Current software release we run is BIG-IP 15.1.3 Build 0.150.11 Engineering Hotfix



ltm virtual /Common/VS_XXXXXXXXXXX_STG_1024-1048 {
    creation-time 2021-01-19:11:48:01
    description "XXXXXXXXXXX"
    destination /Common/XX.XX.XX.XX:0
    ip-protocol tcp
    last-modified-time 2021-12-21:17:13:55
    mask 255.255.255.255
    policies {
        /Common/Policy_XXXXXXXXXXX_STG_Public { }
    }
    profiles {
        /Common/tcp { }
    }
    serverssl-use-sni disabled
    source 0.0.0.0/0
    source-address-translation {
        type automap
    }
    translate-address enabled
    translate-port disabled
}

ltm policy /Common/Policy_XXXXXXXXXXX_STG_Public {
    controls { forwarding persistence }
    description "Forward traffic policy based on content for Public XXXXXXXXXXX"
    requires { tcp }
    rules {
        default {
            actions {
                0 {
                    shutdown
                    client-accepted
                    connection
                }
            }
            ordinal 1
        }
        portrange {
            actions {
                0 {
                    forward
                    client-accepted
                    select
                    pool /Common/POOL_XXXXXXXXXXX_STG_1024-1048
                }
                1 {
                    persist
                    client-accepted
                    source-address
                    netmask 255.255.255.255
                    timeout 57600
                }
            }
            conditions {
                0 {
                    tcp
                    client-accepted
                    port
                    greater-or-equal
                    values { 1024 }
                }
                1 {
                    tcp
                    client-accepted
                    port
                    less-or-equal
                    values { 1048 }
                }
            }
        }
    }
    strategy /Common/first-match
}


Links we already used:

https://community.f5.com/t5/technical-articles/three-ways-to-specify-multiple-ports-on-a-virtual-server/ta-p/285101 
https://f5partnerdashboard.force.com/DevCentral/s/question/0D51T00008694asSAA/use-ltm-policies-to-create-a-vip-listening-on-specific-ports 
community.f5.com/t5/technical-forum/ltm-policy-to-select-pool-based-on-tcp-port-is-not-working/td-p/225065 

  • Okay, i can't explain why but suddenly it works with the earlier mentioned configuration. Maybe the session was hanging in between tests resulting in a bad test but for anyone expierincing a similar issue the policy combined with local side of external interface works.

     

4 Replies

  • Okay, i can't explain why but suddenly it works with the earlier mentioned configuration. Maybe the session was hanging in between tests resulting in a bad test but for anyone expierincing a similar issue the policy combined with local side of external interface works.

     

  • in your rules, what end of the tcp connection is it applying that port to, the remote or local? If remote, that would make sense, as your remote port is outside of the 1024-1048 range. I think there's an option in the rule to apply local/remote (don't have an instance up right now, battery is getting low and I'm remote)

    Edit: I see your policy now...I'll dig in when I get home. Any reason you don't have an ftp profile applied to that virtual?

    • ToonVA's avatar
      ToonVA
      Icon for Cirrus rankCirrus

      Hey JRahm,

      Any reason you don't have an ftp profile applied to that virtual?
      Honestly it was an existing configuration which we had to adapt a bit so never really looked for "optimization" but i will take it into account once i get this working.

      It's indeed the client who picks a port in the range 1024-1048 so the logic of "local side of external interface" seems to be correct (it's not displayed in cli when i select this in the policy options only true GUI).

      https://support.f5.com/csp/article/K56149721?utm_source=f5support&utm_medium=RSS