Forum Discussion

Erlend_123973's avatar
Erlend_123973
Icon for Nimbostratus rankNimbostratus
Oct 20, 2016

Order of precedence for virtual server when using source address

Hi,

I am creating a "catch all" virtual server (destination:0.0.0.0/0).

VIP_Default source: 0.0.0.0/0, destination 0.0.0.0/0

But for a single subnet, I will have another VS serve this traffic:

VIP_Special source: 198.19.0.128/25, destination: 0.0.0.0/0

But it does not seem like a more specific source address have anything to say when it comes to order of precedence when selecting VS. Incoming traffic from source 198.19.0.128/25 will hit VIP_Default, and not the more specific vs, VIP_Special.

In desperate attempt to just solve this, I attempted to create two more specific destination routes by splitting 0.0.0.0/0 into two equal parts:

VIP_Special_A, source: 198.19.0.128/25, destination: 0.0.0.0/1

and

VIP_Special_B, source: 198.19.0.128/25, destination: 128.0.0.0/1

But I here I get the error message "Invalid host/ip" for 0.0.0.0/1 in the GUI. The CIDR address 128.0.0.0/1 however is ok.

I believe both my attempts should be working fine. Am I doing something wrong, or have I hit a limitation/bug in the F5 software?

My version is 12.1.1 HF1

application delivery
LTM

4 Replies

  • Hannes_Rapp's avatar
    Hannes_Rapp
    Icon for Nimbostratus rankNimbostratus
    Oct 20, 2016

    Recommend to delete all client-side (cs) connections on VIP_Default.

    The closer-match VIP_Special will get the special subnet connections (works as intended in 12.1.1). However, as with any F5 change you must acknowledge that previously established sessions are not aware of your configuration changes.

    Other things that can be wrong: VLANs (on which the Virtual Server is listening), the source IP of the 'special subnet' really does not match (perhaps a SNAT takes place?). If you need further help, please paste the full configuration of both Virtual Servers (

    tmsh list ltm virtual VSname
    )

    • Erlend_123973's avatar
      Erlend_123973
      Icon for Nimbostratus rankNimbostratus
      Oct 20, 2016

      If I change the VS_CP_Inet_Forward / VIP_SPECIAL to only listen for port 443, it will start consuming traffic immediately.

      If it was a problem with the source address, the VS_CP_Inet_Forward should not start accepting traffic because I gave it precedence by setting a more specific port.

      This is the VS that should receive traffic from the 198.19.0.128/25 subnet.

      ltm virtual VS_CP_Inet_Forward {
    destination 0.0.0.0%65000:any
    ip-protocol tcp
    mask any
    profiles {
        tcp-wan-optimized { }
    }
    rules {
        irule_cp_cluster_forward
    }
    source 198.19.0.128%65000/25
    source-address-translation {
        type automap
    }
    translate-address enabled
    translate-port enabled
    vlans {
        iApp_webproxy-70-0-D
    }
    vlans-enabled
    vs-index 21
}
`
      

And this is the more generic VS


      `ltm virtual iApp_webproxy.app/iApp_webproxy-70-D-0-t-4 {
    app-service /Common/iApp_webproxy.app/iApp_webproxy
    description "cp_cluster (1476971594)"
    destination 0.0.0.0%65000:any
    ip-protocol tcp
    mask any
    profiles {
        iApp_webproxy.app/iApp_webproxy-tcp-lan {
            context clientside
        }
        iApp_webproxy.app/iApp_webproxy-tcp-wan {
            context serverside
        }
        iApp_webproxy.app/iApp_webproxy-xssl {
            context serverside
        }
    }
    rules {
        iApp_webproxy.app/iApp_webproxy-ilD
    }
    source 0.0.0.0%65000/0
    translate-address disabled
    translate-port disabled
    vlans {
        iApp_webproxy-70-0-D
    }
    vlans-enabled
    vs-index 16
}
  • Hannes_Rapp_162's avatar
    Hannes_Rapp_162
    Icon for Nacreous rankNacreous
    Oct 20, 2016

    Recommend to delete all client-side (cs) connections on VIP_Default.

    The closer-match VIP_Special will get the special subnet connections (works as intended in 12.1.1). However, as with any F5 change you must acknowledge that previously established sessions are not aware of your configuration changes.

    Other things that can be wrong: VLANs (on which the Virtual Server is listening), the source IP of the 'special subnet' really does not match (perhaps a SNAT takes place?). If you need further help, please paste the full configuration of both Virtual Servers (

    tmsh list ltm virtual VSname
    )

    • Erlend_123973's avatar
      Erlend_123973
      Icon for Nimbostratus rankNimbostratus
      Oct 20, 2016

      If I change the VS_CP_Inet_Forward / VIP_SPECIAL to only listen for port 443, it will start consuming traffic immediately.

      If it was a problem with the source address, the VS_CP_Inet_Forward should not start accepting traffic because I gave it precedence by setting a more specific port.

      This is the VS that should receive traffic from the 198.19.0.128/25 subnet.

      ltm virtual VS_CP_Inet_Forward {
    destination 0.0.0.0%65000:any
    ip-protocol tcp
    mask any
    profiles {
        tcp-wan-optimized { }
    }
    rules {
        irule_cp_cluster_forward
    }
    source 198.19.0.128%65000/25
    source-address-translation {
        type automap
    }
    translate-address enabled
    translate-port enabled
    vlans {
        iApp_webproxy-70-0-D
    }
    vlans-enabled
    vs-index 21
}
`
      

And this is the more generic VS


      `ltm virtual iApp_webproxy.app/iApp_webproxy-70-D-0-t-4 {
    app-service /Common/iApp_webproxy.app/iApp_webproxy
    description "cp_cluster (1476971594)"
    destination 0.0.0.0%65000:any
    ip-protocol tcp
    mask any
    profiles {
        iApp_webproxy.app/iApp_webproxy-tcp-lan {
            context clientside
        }
        iApp_webproxy.app/iApp_webproxy-tcp-wan {
            context serverside
        }
        iApp_webproxy.app/iApp_webproxy-xssl {
            context serverside
        }
    }
    rules {
        iApp_webproxy.app/iApp_webproxy-ilD
    }
    source 0.0.0.0%65000/0
    translate-address disabled
    translate-port disabled
    vlans {
        iApp_webproxy-70-0-D
    }
    vlans-enabled
    vs-index 16
}