Can a UDP session be this long?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Can a UDP session be this long?

L4 Transporter

 

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.

1 accepted solution

Accepted Solutions

Cyber Elite
Cyber Elite

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?

Help the community: Like helpful comments and mark solutions

View solution in original post

2 REPLIES 2

Cyber Elite
Cyber Elite

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?

Help the community: Like helpful comments and mark solutions

@SCantwell_IM Thanks for the explanation

  • 1 accepted solution
  • 6232 Views
  • 2 replies
  • 1 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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 LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!