<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Can a UDP session be this long? in General Topics</title>
    <link>https://live.paloaltonetworks.com/t5/general-topics/can-a-udp-session-be-this-long/m-p/296105#M77938</link>
    <description>&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;LI-CODE lang="markup"&gt;FW (active)&amp;gt; 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)&amp;gt; show clock 

Mon Nov  4 10:12:36 PST 2019&lt;/LI-CODE&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;</description>
    <pubDate>Mon, 04 Nov 2019 18:24:21 GMT</pubDate>
    <dc:creator>raji_toor</dc:creator>
    <dc:date>2019-11-04T18:24:21Z</dc:date>
    <item>
      <title>Can a UDP session be this long?</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/can-a-udp-session-be-this-long/m-p/296105#M77938</link>
      <description>&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;LI-CODE lang="markup"&gt;FW (active)&amp;gt; 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)&amp;gt; show clock 

Mon Nov  4 10:12:36 PST 2019&lt;/LI-CODE&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;</description>
      <pubDate>Mon, 04 Nov 2019 18:24:21 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/can-a-udp-session-be-this-long/m-p/296105#M77938</guid>
      <dc:creator>raji_toor</dc:creator>
      <dc:date>2019-11-04T18:24:21Z</dc:date>
    </item>
    <item>
      <title>Re: Can a UDP session be this long?</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/can-a-udp-session-be-this-long/m-p/296143#M77939</link>
      <description>&lt;P&gt;If a communication/traffic is continued to be in a session (considered 2 flows of C --&amp;gt; S and S --&amp;gt; C) on the same DST port (in your case 5555), then the session is still open until either side stops communicating.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;For example, a video or audio conference call, there are (generally) 2 connections made: Control traffic (TCP) and data traffic (UDP)&lt;/P&gt;&lt;P&gt;The Control traffic establishes the call, mutes/un-mutes, etc.&amp;nbsp; (TCP)&amp;nbsp;&lt;/P&gt;&lt;P&gt;The Data traffic is the actual audio/video packets that are transmitted. (UDP)&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;So I tend to believe that either the client or the server is continuing to communicate to each other.&lt;/P&gt;&lt;P&gt;The FW is simply keeping the session open, as designed.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Why other clients cannot access the server is not something we can troubleshoot here.&amp;nbsp; Need to tshoot with wireshark to confirm traffic from a new client is being received by the server...&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Hope that all makes sense.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;What other questions can we answer for you?&lt;/P&gt;</description>
      <pubDate>Mon, 04 Nov 2019 18:54:23 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/can-a-udp-session-be-this-long/m-p/296143#M77939</guid>
      <dc:creator>S.Cantwell</dc:creator>
      <dc:date>2019-11-04T18:54:23Z</dc:date>
    </item>
    <item>
      <title>Re: Can a UDP session be this long?</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/can-a-udp-session-be-this-long/m-p/296166#M77951</link>
      <description>&lt;P&gt;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/113304"&gt;@S.Cantwell&lt;/a&gt;&amp;nbsp;Thanks for the explanation&lt;/P&gt;</description>
      <pubDate>Mon, 04 Nov 2019 20:25:31 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/can-a-udp-session-be-this-long/m-p/296166#M77951</guid>
      <dc:creator>raji_toor</dc:creator>
      <dc:date>2019-11-04T20:25:31Z</dc:date>
    </item>
  </channel>
</rss>

