TCP timeouts RST packets

I have run into an interesting issue that I hope there is an easy fix for.

 

I have 2 ISA servers sitting behind 2 BIG-IP 9.2.5 Build 5.1’s (the LB is the gateway for the 2 ISA servers). At a layer 2 level, the LB’s and the servers are connected to a L3 switch and the vlan sits on the trunk to the LB. On a separate LB interface sits another trunked interface with the L3 switch as the gateway that is the vlan for server VIP’s. Do to constraints within the network I need to allow clients on an ad-hoc basis communication with the ISA servers directly without using the VIP.

 

 

I have static routes on the L3 switch pointing to the LB VIP network to get to the ISA servers. Everything seems to work, except I am seeing reset packets sent from the LB to the ISA and to the Client (each saying they came from the other—when I have confirmed that they aren’t). I can only assume that the LB is timing out the TCP connection and sending the RST packets to each end of the syn ack communication.

 

 

I have a default routing VIP on the LB

 

0.0.0.0 0(any) forwarding IP state is enabled, all protocols, protocol profile client fast L4 reset on timeout, idle timeout 300, tcp handshake timeout 3 secs, loose initiation and loose close enabled.

 

 

My question is this, when traffic is routed by the LB without hitting a server VIP does it hit the routing VIP? If so, is it a stateful routing with timeouts applied? Is it possible to change the timeouts to stop the LB from sending the resets?

 

 

The client scenario is this:

 

 

1. Queries for DHCP Option 252 to determine WSPAD location (equivalent of a PAC file for IE)

 

2. Loads WSPAD file

 

3. Connects to FQDN specified in WSPAD file (which is the a alias that specifies the ISA PROD interfaces) and retrieves the proxy cluster config

 

4. Connects to proxies identified in the proxy cluster config.

 

 

The basic reason we cannot target a VIP is 4. The proxy cluster config is published by ISA and as such will always direct the client to the specified interfaces on the proxy server.

 

 

LB1

 

tcpdump: listening on v4008-ext

 

12:02:25.023192 40:0:d7:6a:3e:3 0:5:dc:8:48:0 ip 54: (ISA IP).1745 > (client IP).49506: R 3765865090:3765865090(0) ack 644205770 win 0 (DF)

 

 

 

LB1

 

tcpdump: listening on v4034-ext

 

12:02:23.223172 0:1:d7:6a:3e:4 0:21:5a:27:c2:92 ip 54: (client IP).3099 > (isa IP).1745: R 1254974338:1254974338(0) ack 715301416 win 0 (DF)

 

12:02:25.023182 0:1:d7:6a:3e:4 0:21:5a:27:c2:92 ip 54: (client IP).49506 > (isa IP).1745: R 644205770:644205770(0) ack 3765865090 win 0 (DF)