Firewall pass list
AnsweredHi,
We've used the firewall pass list to allow NX Witness traffic out.
We've added all IPs and FQDNs as listed and requested there:
https://support.networkoptix.com/hc/en-us/articles/360010795813-Firewall-Pass-List
Yesterday, for the second, time all our NX Witness servers lost connection and went offline.
After some investigation we found out an extra connection was made to:
ec2-3-92-111-105.compute-1.amazonaws.com
And yesterday another extra connection was made to:
ec2-54-160-122-119.compute-1.amazonaws.com
So, why is this happening and needed?
These FQDNs are not listed in the firewall pass list.
It gives me an uncomfortable feeling, this can happen any time soon again if a (NXOptics) resource in AWS changes and gets another IP or FQDN.
Or what can we do about it to prevent next time from happening.
Thanks for your reaction.
-
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.
-
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.
-
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>
-
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,
-
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!
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Thanks, Stephan Versluis. I corrected my error.
-
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 OPENAll 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.comThe 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.
Please sign in to leave a comment.
Comments
15 comments