Using the same IP address for a VIP and a SNAT - yay or nay?

I've SNATted traffic using the VS address as the source on a pretty large scale in the past without issues.

 

 

Regarding your design I suspect the issue may lie with the fact the IP is shared with a wildcard VS. The SNAT may assign a source port that is then used for the destination port by a client attempting to connect to the the VS, the F5 has no way of knowing or reserving ports in this scenario and I'm amazed it works at all. If the VS was restricted to a single port this wouldn't be an issue as the F5 would know what not to use for the SNAT.

Hi Steve,

 

 

Thanks very much for the prompt reply. That definitely is a concern. Is there any way to check possible port conflicts form the CLI?

I'd imagine the only way is to view the connection table: '[tmsh] command sys connection all-properties' but this won't inform you of conflicts. However it may provide some clues in that you can run the command a few times a day and compare the ports used with the SNAT and those used with the VS and see if they ever overlap. Beyond that a tcpdump may be useful but somewhat overwhelming.

Thanks Steve. I'll give that a go.

You're welcome. Do post back if you can it would be nice to have this confirmed one way or the other. Cheers

I guess in the initial post was supposed to mention the listening VIP config for the inbound connections. This VIP shares the same IP as the selective SNAT from above and it experience the "lag".

4.

 
virtual external-VIP {
   snat automap
   pool server-farm-pool
   destination 192.168.1.2:http
   ip protocol tcp
   profiles { http tcp }
   vlans external-VLAN enable
}

The external VIP is available only on the external-VLAN , while the forwarding VIP is on the internal-pool-VLAN only.

The external VIP listens on a port < 1024 for client connections

The SNAT will generate traffic from the same IP address as the external VIP, but on ports always > 1024

So, how would the connection tracking get confused especially the 2 types of traffic originate on different interfaces (internal-VLAN vs external-VLAN) ?

Thanks,

Adrian

P.S. Myself and OttimoMassimo work in the same place, tracking on the same issue...

How are you sure the VS traffic is always < 1024?

 

 

The connection tracking isn't getting confused but there is no way to guarantee uniqueness of port allocation. For example, an outbound connection uses port 2059 as it's source port as currently this port is free in that it is not in use by the SNAT and the VS isn't handling an inbound connection on that destination port. Then, some traffic is received by the VS on port 2059, not something you can control as it's inbound and a wildcard VS. Now we have a problem, port 2059 for that IP address is being used for the SNAT (an 'ephemeral listener' has been created to accept return traffic) so is that traffic processed by the VS, I doubt it.

 

 

Is that clear and logical?

First, thanks for the reply Steve.

 

I'm trying to get to the bottom of that logic on how the LTM will get confused with the connections originated on two different nw segments...

 

The VS defined with "virtual external-VIP" listens on port 80/TCP only. It is presented on an external VLAN interface. Clients connecting to it (Internet originated), have a source port > 1024 (a firewall on the public domain ensures that). This external VS also has "snat automap" which will "hide" the external clients originated IP address to the backend servers.

 

The VS defined with "virtual snat-wcard" listens on all ports but it's only presented on an internal VLAN. The SNAT performed by this VS it's on the same IP with the external VS, but the ports used outbound are always >1024. How do I know this? The servers on the internal VLAN are managed by ourselves as well (i.e we are a closed shop for this traffic - we=the company) and when they need to make an outbound connection (local originated connection to the wild Internet), the IP ports used are between 32768 and 61000 (controlled with /proc/sys/net/ipv4/ip_local_port_range). Also, checked the F5 linux OS and /proc/sys/net/ipv4/ip_local_port_range also shows a range from 32768 to 61000 .

 

So, you are saying here (correct me if wrong), that when a internal-VLAN client makes a request outbound (in this particular config), the F5 after doing the SNAT on the external-VLAN IP, can chose any random port between 1 and 64k ? And this totally bypassing the ip_local_port_range defined in the F5 linux OS? Just curios...

 

 

 

OK, the extra information you've provided mostly indicates that sharing the address is not the cause of your issue, however, let me respond to a few things;

 

 

1) The originating segment doesn't matter; if the SNAT IP consumes port 16000 for an outbound translation that port cannot be used to serve a different inbound connection to the same IP address. Port 16000 for that IP address has already been used, how, why or where is not relevant.

 

2) Apologies but I missed the fact the inbound VS was NOT wildcard and was getting confused with the outbound one.

 

3) Regarding the Linux OS, this is a red herring. Any settings found there are for the HMS and management functions and interface. LTM/TMM does not use these settings; it has multiple protocol stacks that operate independently of the HMS. So yes, it's possible a lower port number could be used for an SNAT and that setting is completely ignored for anything other than management related traffic.

Quick update - the VIP re-IPing made no difference to the performance of the VIP.... back to the drawing board!