Forum Discussion

Paulo_Vinicius_'s avatar
Paulo_Vinicius_
Icon for Altocumulus rankAltocumulus
Feb 13, 2023

Implementing new IP forwarding virtual servers using IP Address Lists (shared objects).

Hi Dear F5 DevCentral community!

 

We have a client that already uses IP forwarding virtual servers using as a source an IP Address /32, especifying exactly the source that these IP forwarding virtual servers will match. The destination address is always 0.0.0.0 and specified the port 25 (SMTP).

 

And for the traffic that not matches these Virtual IP forwarding virtual servers source, we have another Virtual IP forwarding virtual server wildcard with 0.0.0.0 for source and destination, only specific the port as 25 (SMTP).

 

Everything has been working fine up to this point for some time now.

 

But now, this client want to create new IP forwarding virtual servers using IP Address Lists (shared objects) as source address, keeping the destination as 0.0.0.0 (any) and specifying the port 25. They already configured it like that, but the traffic is being forward by the wildcard  IP forwarding virtual server, do'nt matching the new  IP forwarding virtual server created using IP Address Lists (shared objects) as source address, which Address List contains 2 IP addresses from 2 distincts subnets.

Has anyone already faced this problem?

I looked through the F5 documentation and didn't find anything specific.

 

Thank you!

 

Best Regards.

application delivery
  • Paulius's avatar
    Paulius
    Icon for MVP rankMVP
    Feb 13, 2023

    Paulo_Vinicius_ I had a similar experience with the F5 BIG-IP and had an open case with them because of this behavior. Sadly we only had one troubleshooting session before I had moved on to another company so I am not aware if they ended up solving the issue or if this is a known bug. If no one has an answer for you here I recommend creating a QKVIEW, opening a case with F5, and uploading that QKVIEW to the ticket to see if they have a solution for you or if iHealth shows you any possible solutions when opening it in that ticket.

    • Paulo_Vinicius_'s avatar
      Paulo_Vinicius_
      Icon for Altocumulus rankAltocumulus
      Feb 13, 2023

      Thank you very much for your attention, I'll keeping close eyes here, but already planning opening the case!

  • JoshBecigneul's avatar
    JoshBecigneul
    Icon for MVP rankMVP
    Feb 13, 2023

    Hi Paulo_Vinicius_ ,

    There are some limitations when mixing resources that use the regular address definition and the newer address list feature. One I have found is you can't mix a standard single address and a list where they overlap, which I thought causes an error upon saving. Double check that all your VIPs use the appropriate netmask values if you're truly wanting to listen to "any" IP.

    Maybe you can paste a screenshot or a text snippet of the configuration?

    Here are some other resources which may help:

    • Paulo_Vinicius_'s avatar
      Paulo_Vinicius_
      Icon for Altocumulus rankAltocumulus
      Feb 14, 2023

      Hi,

       

      Unfortunately I can't share the configuration of the client.

       

      But we scheduled a maintenance window to configure the new Virtual Servers on the client environmet, like I've described above the tests from our laboratory, where we could reproduce the issue and perform the correction and I'll reply here if it solved or not the issue.

       

      Thank you!

      • Paulo_Vinicius_'s avatar
        Paulo_Vinicius_
        Icon for Altocumulus rankAltocumulus
        Feb 17, 2023

        In the MW with the client, the issue was resolved only when we configured the sourde address as a single IP address /32 and the destination Any (0.0.0.0/0). As they already had others IP forwarding virtual servers working properly.

         

        But, differing from our lab, the client use partitions, and the Rouite Domain ID of the partition is 10. The Common is 0.

         

        The IP forwarding virtual servers are placed in the partition with the ID 10.


        Whe in the partition with the route domaind ID 10, the BIG IP adds automtically the route domaind ID 10 into the IP address configured into the address lists created:

        For example in one address list with two IPs, they were like this:

        172.20.20.1%10/32

        172.20.20.100%10/32

         

        When we configure the IP forwarding virtual server using this list as source address, and configure the 0.0.0.0/0 in the destination, when we update the configuration of the VS the BIP IP adds automatically the route domain from partition Common and it changes to 0.0.0.0%0/0. We tried to add the route domain 10, configuring the destination as 0.0.0.0%10/0 so, the route domains will match between source address into the address list and the destionation mask (any), but the BIP IP system changes it again to 0.0.0.0%0/0.

         

        So, we conclude that it could be a misbehaviour from BIG IP and openned a support case. 

  • Paulo_Vinicius_'s avatar
    Paulo_Vinicius_
    Icon for Altocumulus rankAltocumulus
    Feb 13, 2023

    We've been testing it in a Lab Environment, and made such progress.

     

    We keep in the lab the Virtual IP forwarding virtual server wildcard with 0.0.0.0 for source and destination, only specific the port as 80 (HTTP). Different port from the client just for lab pourpouses. And it worked well.

     

    Then, we started the tests, first besides the Virtual IP forwarding virtual server wildcard, we've configured two more IP forwarding virtual server, each from one specific client source, specifying the IP 10.1.0.10/32 and 10.1.0.20/32 for example, using the mask /32 for each 2 new Virtual Servers, and keeping the destination as 0.0.0.0 or 0.0.0.0/0 (both worked). When we did that, the traffic from these sources matched the criteria for each one of these new IP forwarding virtual server and it worked, as we could see in the statistics from the vrtual servers and tcpdump capture.

     

     

    So, it was time to perform the tests using the IP Address Lists (shared objects), and differing from the client configuration, we configured specifying the IPs with a /32 mask into the IP Address List we created. Deleting the two IP forwarding virtual server confiugured each with one source, we keeped the wildcard and configured a new one, with the Address List as source, and the destionation as 0.0.0.0 or 0.0.0.0/0 (both worked too), and port 80, keekping the wildcard IP forwarding virtual server and this new IP forwarding virtual server with de same destination 0.0.0.0 and port 80, differing only that the IP forwarding virtual server wilcard matching any source to any destionation at port 80, and the new IP forwarding virtual server matching any the both /32 prefixes configured in the Address List as source to any destination at port 80. Ir worked fine in our lab!

    Now we're waiting the customer to make some adjustments in the production BIG IPs.