FW (active)> show session id 2394622 Session 2394622 c2s flow: source: 10.101.6.34 [INTERNAL2] dst: 172.20.0.89 proto: 17 sport: 52125 dport: 5555 state: ACTIVE type: FLOW src user: unknown dst user: ee\ss offload: Yes s2c flow: source: 172.20.0.89 [SERVER2] dst: 10.101.6.34 proto: 17 sport: 5555 dport: 52125 state: ACTIVE type: FLOW src user: ee\ss dst user: unknown offload: Yes Slot : 1 DP : 0 index(local): : 2394622 start time : Thu Oct 31 16:30:53 2019 timeout : 30 sec time to live : 28 sec total byte count(c2s) : 1096464 total byte count(s2c) : 0 layer7 packet count(c2s) : 16345 layer7 packet count(s2c) : 0 vsys : vsys2 application : unknown-udp rule : AVT service timeout override(index) : False session to be logged at end : True session in session ager : True session updated by HA peer : False layer7 processing : completed URL filtering enabled : True URL category : any session via syn-cookies : False session terminated on host : False session traverses tunnel : False captive portal session : False ingress interface : ae2.6 egress interface : ae2.20 session QoS rule : N/A (class 4) tracker stage l7proc : ctd decoder bypass end-reason : unknown FW (active)> show clock Mon Nov 4 10:12:36 PST 2019
And for whatever reason for this device 10.101.6.34 is seen as available to the server 172.20.0.89 for the application they are using, while all other are failing.
Solved! Go to Solution.
If a communication/traffic is continued to be in a session (considered 2 flows of C --> S and S --> C) on the same DST port (in your case 5555), then the session is still open until either side stops communicating.
For example, a video or audio conference call, there are (generally) 2 connections made: Control traffic (TCP) and data traffic (UDP)
The Control traffic establishes the call, mutes/un-mutes, etc. (TCP)
The Data traffic is the actual audio/video packets that are transmitted. (UDP)
The call could go on for minutes or hours, as people use the technology, so as long as the same UDP ports are being used to transmit audio/video on this call, then the session is active.
So I tend to believe that either the client or the server is continuing to communicate to each other.
The FW is simply keeping the session open, as designed.
Why other clients cannot access the server is not something we can troubleshoot here. Need to tshoot with wireshark to confirm traffic from a new client is being received by the server...
Hope that all makes sense.
What other questions can we answer for you?
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!