cancel
Showing results for 
Search instead for 
Did you mean: 

Asymmetric routing after software-update not working anymore

We have performed a software update from 13.1.1.5 to 13.1.3.2 on a BIG-IP 4000S.

After this we noticed that access to a server is not working anymore (it was working with the old version).

Following some details about the configuration:

  • The server, FW and the BIG-IP have IPs in the same VLAN.
  • The FW is normally the main Layer3-hop in this VLAN.
  • As the application on the server can not work with SNAT, this server has its default gateway pointing to the BIG-IP.
  • The BIG-IP itself has its default gateway pointing to the FW.
  • We have a forwarding VS configured with a fastL4 profile and both "Loose Initiation" and "Loose Close" options enabled.
  • This configuration on the BIG-IP is part of a Route-Domain and separated via a partition (this partition is assigned to the Route-Domain).

Now we have for example the following use-case:

  • We want to start a RDP-session to this server from a hopping station.
  • The "request"-traffic is going via the FW and from there directly to the server.
  • But due to the default gateway pointing to the BIG-IP, the "response"-traffic is going via the BIG-IP.
  • When starting a tcpdump we see two entries:
IN s1/tmm2 : 3389 → 55964 [SYN, ACK, ECN] Seq=0 Ack=1 Win=64000 Len=0 MSS=1460 WS=1 SACK_PERM=1 OUT s1/tmm2 : 31463 → 55964 [SYN, ACK, ECN] Seq=0 Ack=1 Win=64000 Len=0 MSS=1460 WS=1 SACK_PERM=1
  • When checking the MAC-addresses of the outgoing paket, this is the one from the FW.

Please correct me if I'm wrong, but this looks for me that the paket reaches the BIG-IP and will be routed/forwarded correctly.

How can we further analyze this? Any idea if this really belongs to the software-update?

The FW-team mentioned that they have not performed any changes in that time, but it's not 100% proven 😉

Do you need any further information/details?

Thank you for your help!

 

Ciao Stefan 🙂

1 ACCEPTED SOLUTION

Hello Stefan.

 

The behavior of the F5 in 13.1.3.2 have changed.

REF - https://support.f5.com/csp/article/K50533164

REF - https://cdn.f5.com/product/bugtracker/ID726176.html

 

"Source-port: preserve" now forces a port change, so the behavior have changed since your previous version:

REF - https://support.f5.com/csp/article/K11003

 

My recomendation is to change your VS source-port option to "preserve-strict".

 

KR,

Dario.

Regards,
Dario.

View solution in original post

3 REPLIES 3

Simon_Blakely
F5 Employee
F5 Employee

That indicates the source port was translated from 3389 to 31463

IN s1/tmm2 : 3389 → 55964 [SYN, ACK, ECN] Seq=0 Ack=1 Win=64000 Len=0 MSS=1460 WS=1 SACK_PERM=1 OUT s1/tmm2 : 31463 → 55964 [SYN, ACK, ECN] Seq=0 Ack=1 Win=64000 Len=0 MSS=1460 WS=1 SACK_PERM=1 ^^^^^

Check that the virtual has not has port translation enabled.

Hello Stefan.

 

The behavior of the F5 in 13.1.3.2 have changed.

REF - https://support.f5.com/csp/article/K50533164

REF - https://cdn.f5.com/product/bugtracker/ID726176.html

 

"Source-port: preserve" now forces a port change, so the behavior have changed since your previous version:

REF - https://support.f5.com/csp/article/K11003

 

My recomendation is to change your VS source-port option to "preserve-strict".

 

KR,

Dario.

Regards,
Dario.

Hi Dario,

thank you for the detailed links.

We changed the Source Port option to "preserve-strict" and RDP is working again.

We will monitor this and also check and test different use-cases, but it looks like this solved the issue.

Thank you!!!

 

Ciao Stefan 🙂