Can a UDP session be this long?

[raji_toor]

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.

[S.Cantwell · Accepted 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?

[raji_toor]

@S.Cantwell Thanks for the explanation