PA confirms the only work around right now is to increase the Vidyo application timeout to something large like 2-3h, something that works best to your users. PAN agrees this is a design limitation on their end, because they should tie the two application and identify them as one (ICE) Vidyo Client only send keep alive via STUN (to keep the port open) but in the PA case that is not enough as the Vidyo application session will timeout. Unfortunately, it does NOT fix the whole issue because of the 2nd Application identified by the FW, Vidyo. Increasing the STUN timeout to 600sec should solve that issue. The STUN keep alive are every 15sec meaning in the 300 we will only be sending 20. Vidyo ICE is identified by the PA as two applications Vidyo and STUN.ĭefault application timeout is 300sec, In these 300sec the FW is expecting to get 32 packets. In larger Palo Alto FW with multiple CPUs PA is using session offload where the session is monitored per application. The Admin can define rules to minimize the range by creating a new service.Īlso application default can be used as on the PA Vidyo will have TCP/dynamic and UDP/dynamicĪlso the admin can of course make the rules stricter by providing specific destination IP addresses of the Vidyo elements (like VidyoRouter, VidyoPortal) in a Internal & DMZ deployments. Note that for the second rule, the service is ‘any’ to include all the UDP ports 50000-65535 (recommended). Where the vidyo-service in the service column is defined as a service object below: Vidyo with Encryption enabled: For encryption the admin need to create an SSL service and include Vidyo ports 443, 17990-17992 this with addition to the Vidyo and Stun services for the UDP traffic.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |