Firewall pass list

Answered

Comments

15 comments

  • Avatar
    Norman - Nx Support

    Dear Stephan,

    I hope this message finds you well. We would like to investigate the issue further. Could you kindly provide me with the following information:

    • The cloud ID of the system
    • The version and build number of Nx Witness
    • Could you please share the output of the python script attached to the support article you linked to?

    Thank you very much for your assistance. Please don't hesitate to let me know if you have any further questions or concerns.

    0
    Comment actions Permalink
  • Avatar
    Stephan Versluis

    Hi Norman,

    Thanks for you reaction.

     - Cloud ID: 73a00b0d-954e-4f65-870a-930229cb8722 (This is only from one system, we have several)

     - Version:  5.0.0.35745

     - The python script I can't run on a Windows host, so I'm not able to provide you with that.

    0
    Comment actions Permalink
  • Avatar
    Norman - Nx Support

    Hi Stephan,

    Thank you for the quick reply.
    I'll share the information with our cloud team, to check the issue.

    To run a Python script on Windows, there are various methods. Some are mentioned in this LINK.

    I'll get back to you as soon as possible.

    0
    Comment actions Permalink
  • Avatar
    Stephan Versluis

    Hi Norman,

    Thanks for the how-to-python link :)

    I've added the output below.

    I ran the script from my own client and not from the server as you may understand I can't install the python library's there.

    So firewall rules differ for the server and my client

    <results_removed_for_readability>

    0
    Comment actions Permalink
  • Avatar
    Norman - Nx Support

    Dear Stephan Versluis,

    I hope this message finds you well. I wanted to bring to your attention that after reviewing the results you provided, I was triggered by the results for the mediator cloud instances in the python script that was provided.

    To address this, I have created an updated script (v0.0.4.2) that includes the necessary modifications to the mediator cloud instance list. I kindly request that you run the script once again to ensure the proper functionality of the system.

    Typically, adding mediator.vmsproxy.com to the firewall should be sufficient, but since it appears as closed, I added the specific cloud instances as well, just to be sure, the connection would be possible. An OPEN result for the connection to the mediator.vmsproxy.com address is mandatory to achieve the proper cloud connection.

    There is also a closed connection to the vultr-syd-1.vmsproxy.com and the timeservers, I want to assure you that this should not be a major concern at this time. Based on the likelihood of your connection passing through the AWS Sydney data center, it is very unlikely that this issue will impact your overall experience.

    Thank you for your understanding, and please let me know if you have any further questions or concerns.

    Best regards,

    0
    Comment actions Permalink
  • Avatar
    Stephan Versluis

    Hi Norman,

    Thanks for the updated script, it really helps with troubleshooting now.

    So it looks like adding mediator.vmsproxy.com helped.
    But it makes a connection on TCP 3345 and not on UDP 3345:


    Can I remove the other URLs? Because mediator.vmsproxy.com is the top URL?

    us-east-1.mediator.vmsproxy.com (52.7.195.88)

    us-west-1.mediator.vmsproxy.com (54.153.53.233)
    ap-southeast-2.mediator.vmsproxy.com
    eu-central-1.mediator.vmsproxy.com

    I've added port 37, I think I missed that one.
    I've add vultr-syd-1.vmsproxy.com to, but somehow it's not working. But as you mentioned the likelihood it will be used. Will figure it out on our end why it's not working.
    So now the Python output looks like:

    <results_removed_for_readability>

    Before make these changes to the firewall our NX Witness servers went offline again and 2 new AWS IPs popped up.
    We will first monitor if these changes worked for us.

    Thanks!

    0
    Comment actions Permalink
  • Avatar
    Norman - Nx Support

    Hi Stephan Versluis,

    Some comments:

    So it looks like adding mediator.vmsproxy.com helped.
    But it makes a connection on TCP 3345 and not on UDP 3345:

    Allow me to check this with our cloud team.

    Can I remove the other URLs? Because mediator.vmsproxy.com is the top URL?

    Typically, you could. I just wanted to check it.

    I've add vultr-syd-1.vmsproxy.com to, but somehow it's not working. But as you mentioned the likelihood it will be used. Will figure it out on our end why it's not working.

    The issue is on our side, so don't waste time on it, especially since it is a redundant instance.

    0
    Comment actions Permalink
  • Avatar
    Norman - Nx Support

    Dear Stephan Versluis,

    I hope you're doing well. I wanted to follow up with you regarding the addresses you mentioned;

    • ec2-3-92-111-105.compute-1.amazonaws.com
    • ec2-54-160-122-119.compute-1.amazonaws.com

    After consulting with our cloud team, we have confirmed that these are AWS Elastic Load Balancers (ELBs). Please note that we do not have control over these ELBs, which means that they can be added, removed or modified without our knowledge. Furthermore, these IPs are behind the main cloud domain name (e.g., nxvms.com). These addresses might vary a bit, but are all similar.

    Also, I wanted to let you know that the vultr-syd-1.vmsproxy.com is available again. If you have any other questions or concerns, please don't hesitate to reach out to me.

    Best regards.

    0
    Comment actions Permalink
  • Avatar
    Stephan Versluis

    Hi Norman,

    We've made all changes mentioned above to all our firewalls. I will monitor closely this week.
    The last change was made this weekend, because NX Optics went offline again, and was adding the top domain: nxvms.com to all firewalls. Without a *, just nxvms.com.

    I see vultr-syd-1.vmsproxy.com is working again.

    0
    Comment actions Permalink
  • Avatar
    Stephan Versluis

    Hi Norman,

    I've monitored the connections/Witness servers all week and all looks good now.
    No more disconnects or Witness servers went offline.

    I removed on one site the AWS FQDNs from the firewall and will do on all other sites next week.

    Thanks for your (quick) support!

    Edit:

    One more thing, did you get an answer from your cloud team regarding  TCP 3345/UDP 3345?

    Have a good one.

    0
    Comment actions Permalink
  • Avatar
    Norman - Nx Support

    Hello Stephan Versluis,

    I hope you're doing well. I wanted to thank you for the positive update you shared with me. It's great to hear that everything is running smoothly.

    Regarding TCP 3345/UDP 3345, I must admit that I didn't inquire about it previously. However, I've taken note of your query and will look into it promptly. I will keep you informed as soon as I gather more information. Thank you for bringing it to my attention.

    Fijn weekend alvast.

     
    1
    Comment actions Permalink
  • Avatar
    Norman - Nx Support

    Hi Stephan Versluis,

    I wanted to share some information that I just received from our cloud team regarding network protocols:

    For systems older than version 5.0, UDP port 3345 is used. For systems 5.0 and newer, TCP port 3345 is used.

    Please let me know if you have any questions or concerns regarding this information.

    Best regards.

    0
    Comment actions Permalink
  • Avatar
    Stephan Versluis

    Good morning Norman,

    Just to clarify and maybe you made a typo: TCP port 3345 is used not TCP 3354?

    0
    Comment actions Permalink
  • Avatar
    Norman - Nx Support

    Thanks, Stephan Versluis. I corrected my error.

    1
    Comment actions Permalink
  • Avatar
    Stephan Versluis

    Hi Norman,

    Here I am again.
    We encountered problems again today with 3 of our 7 NX witness servers.
    3 servers went offline and users weren't able to view camera streams anymore.
    After opening up our firewall to any destination the servers came back online again.

    Running the python script only showed 2 (Melbourne I guess) servers offline:
    [92mvultr-mel-1.vmsproxy.com:80 OPEN
    [92mvultr-mel-1.vmsproxy.com:443 OPEN
    [93mvultr-mel-2.vmsproxy.com:80 connection retry in 1 second
    [93mvultr-mel-2.vmsproxy.com:80 connection retry in 1 second
    [91mvultr-mel-2.vmsproxy.com:80 CLOSED
    [93mvultr-mel-2.vmsproxy.com:443 connection retry in 1 second
    [93mvultr-mel-2.vmsproxy.com:443 connection retry in 1 second
    [91mvultr-mel-2.vmsproxy.com:443 CLOSED
    [92mvultr-mel-3.vmsproxy.com:80 OPEN
    [92mvultr-mel-3.vmsproxy.com:443 OPEN
    [92mvultr-mel-4.vmsproxy.com:80 OPEN
    [92mvultr-mel-4.vmsproxy.com:443 OPEN

    All other tests came back with status OPEN.

    After opening our firewall we saw again some AWS and CDN traffic:
    ec2-34-238-227-18.compute-1.amazonaws.com
    unn-89-187-174-241.cdn77.com

    The moment we close our firewall again with the provided firewall pass list the 3 servers go offline again.
    So funny thing, it's only happing with 3 of our 7 servers.

    Thanks for your reply.

    0
    Comment actions Permalink

Please sign in to leave a comment.