Forum Discussion
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 🙂
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.
- Simon_BlakelyEmployee
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.
- Stefan_KlotzCumulonimbus
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 :)
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com