VS fails to process ANY traffic

So you exchanged addresses, correct? Is this the current config:

1. VIP: 10.X.X.254
2. Self-IP: 10.X.X.250

When you run a tcpdump (see below) on the virtual server address, are you seeing traffic?

tcpdump -xxvvi 0.0:nnn -s 0 host 10.X.X.254 and port 9989 -w /tmp/devcentral-01.pcap

Dumb question but have to ask: no firewalls between the router and the F5, correct?

In lieu of having access to the upstream router at the time of your reply (needed to get hold of that team this week), would it be possible to swap your suggestion (i.e. - change the F5 self-IP?)

 

I attempted this, and the desired traffic is definitely still landing on the F5 (and the initial landing interface - 1.1 - is now even showing some packets going OUT of it (rather than multicast packets only), but still not seeing any statistics on the VS OR the interface that is ultimately to deliver the traffic to the server (1.5).

 

For the purposes of this conversation, think of the architecture of an F5 virtual server as a firewall policy. There is an IP address and port requirement that inbound traffic must satisfy before traffic is passed. While an F5 self IP address is like any other network interface that subscribes to the OSI model, it is not designed to manage application traffic with policies, profiles, ssl offloading, etc. -- a virtual server is.

 

That said, any application traffic designed to pass traffic through an F5 must have a virtual server with an IP address, port (e.g. 10.1.1.1:3389) and any applicable profiles and policies in place to properly handle this traffic flow.

 

In the case of your configuration, traffic is being sent to the self-ip address. This address will accept the traffic but will not forward/manage/manipulate that traffic because the self-ip address is not designed for that functionality. Much like sending traffic to the IP address assigned to the interface of a firewall (192.168.0.1:443) expecting it to hit a firewall policy (10.0.0.1:443). The firewall interface subscribes to the OSI model and may accept the traffic but nothing will happen afterwards.

 

I'll coordinate with the upstream admin on the router change tomorrow morning.

 

In the meantime -- I'm curious, is there something within default F5 behaviors that makes you suggest the Virtual Server IP change? Are there rules I'm ignoring regarding the Self-IP and VS IP overlapping? And 100% confirm this suggestion stands even though the F5 is seeing traffic destined for the 10.X.X.254:9989 address & port on the inbound interface?

 

Just trying to better understand the logic behind this suggestion.

 

After looking closer at your initial post, I edited the comment. Rather than capturing traffic, go ahead and change the config on the F5 as well as the router:

 

Assuming the router is NOT using the F5 as next hop/default gateway, try this:

 

1. Change the VIP address to 10.x.x.250
2. Configure your router to point to 10.x.x.250 rather than 10.x.x.254.

Once you have basic connectivity sorted out, then we can tackle restricting access to this VIP by VLAN.

 

I have, and nothing. Only time I get any traffic on the intended back end member pool/port is when the udp healthcheck is enabled (which sends packets with the default_send_string text)

 

tcpdump -vvvnnnXi 1.5 (and 1.1 to see the traffic landing on the ingress interface) is the command used

 

The entirety of the virtual server statistics (bits in/out, packets in/out, connections) are all 0. (And I suspect this is not simply an F5 bug -- though I can't be sure -- due to the lack of packets traversing out 1.5 to the pool member)

 

I think I see the problem...the router is pointing to the wrong address on the F5.

 

Assuming the router is NOT using the F5 as next hop/default gateway, try this:

 

1. Change the VIP address to 10.x.x.250
2. Configure your router to point to 10.x.x.250 rather than 10.x.x.254.

Once you have basic connectivity sorted out, then we can tackle restricting access to this VIP by VLAN.

 

ltm virtual V9 {
    destination 10.X.X.0:9989
    ip-protocol udp
    mask 255.255.255.0
    pool V9
    profiles {
        udp {}
    }
    snat automap
    source-port preserve-strict
 }

(Note: I have a 2nd one of these intending to do the same thing on a different port - on that one automap is disabled, with no change in performance)

Could you run tmsh ltm list virtual udp_virtual_servername and post the config please?

 

If you don't have SNAT enabled on your virtual server, that may be the culprit. If SNAT is not enabled, then 192.168.y.20 would have to use 192.168.y.254 as default gateway.

 

Specific IP allocations /configs are as follows (spam filter):

 

• external Range: 10.X.X.0/24, F5 Interface 1.1
• internal Range: 192.168.Y.0/24 F5 Interface 1.5
• External F5 Self-IP: 10.X.X.254 (can ping devices in 10.X.X.0/24 network; this is also IP target data is specifically being sent to)
• Internal F5 Self-IP: 192.168.Y.254 (can ping devices in 192.168.Y.0 network)
• Virtual Server Configuration: Network-10.X.X.0/24:9989, Protocol UDP, All vLANs (would like to narrow this but not sure if I need both external and internal vLANs defined)
• Pool Configuration: 192.168.Y.20:9989, showing up with ICMP health check