We have a new set-up of an F5 with two VIPS - one performance layer 4 for https (SSL authentication to the pulse secure appliance), ad another standard VIP on UDP/4500 (for IPSec data traffic). Both Profiles have a source affinity persistence profile mapped to them which has option "Match Across Virtual Server" checked. This is to allow Both VIPS to act as one for Data Traffic. The F5 has also two Gateways configured as self IP's and their respective floating IP's - this is so the pulse uses the F5 as its gateway for internal and external traffic. The routing on the F5 points internal traffic to a default route to a
switch in the DMZ which knows the route to the data center - and was being
used to route traffic in the old set-up too.
What we found with the new set-up was that traffic going to the external port worked fine, but traffic to the internal port on the pulse (routed via the F5 internal gateway) was not working at all. This interface should use its own IP address and initiate a request to Authentication servers, but did look like it was - resulting in users not being able to log into their pule clients (as authentication was failing).
In the old set-up the gateways were on two separate switches, and this worked
even after we reverted back - we saw users able to connect and log into
pulse - where as in the new set-up they couldn't go past the prompt.
We believe the issue is only with internal traffic, as external traffic
looks fine. We also believe it could be the F5 potentially stopping the traffic from passing but not sure why.
Could the profile be changing something in the packet header?
Could both VIPs also need to be standard VIPS for this to work ?
Has anyone come across an issue like this before ?
If the pool member servers are not in the same subnet as a self ip on the F5 device then the routing table is checked and maybe the routing table is sending traffic to another interface for the internal gateways.
Also check for asymetric routing for the internal gateway traffic: