Background
The NEXT applications in your browser must connect to the NEXT backend to load data. It's therefore required that your organization's firewalls allow:
Your browser to load the NEXT applications and
The NEXT application in your browser to connect to the NEXT backend.
You will need the IT department of your organization to configure the corporate firewalls.
Required configurations for your firewall
The following traffic must be enabled in your firewall in order to use NEXT:
Users | Domains | Port | Protocols |
All | *.nextapp.co | 443 | https, wss |
All | cognito-idp.<REGION>.amazonaws.com | 443 | https |
All | *.s3-accelerate.amazonaws.com | 443 | https |
NEXT is hosted on cloud infrastructure with load balancing. We therefore cannot provide a list of IPs to whitelist.
Please contact NEXT Support if you IT team can't enable access to AWS domains.
Detect if your firewall is configured correctly
There are various reasons why you might not be able to connect to NEXT. Use these steps to isolate if the problem is caused by your corporate firewall:
Try to connect with the latest version of Chrome from your device => If this works: your browser isn't supported. See here the list of supported browsers
Try to connect from another device in your corporate network (e.g. tablet) => If this works: check for virus scanner or other protections on your device
Try to connect from a non-corporate network (e.g. your network at home). => If this works: this is likely a problem with your corporate firewall
FAQ
Q: Can I allow a list of public IP addresses instead of domains?
NEXT runs on AWS' infrastructure. For maximal fault tolerance, we can't limit the IP addresses to a NEXT-specific ranges but leverage the full IP range of AWS. Please consult the AWS documentation on how to download the current IP ranges.
We advise against allowing IP addresses instead of domains because:
Limited benefit: The IP ranges of AWS are rather wide and everyone can deploy software in these ranges (e.g. sign up for AWS and bring up an EC2 instance). Hence, the benefit vs. no limit at all is only marginal.
Lots of complexity: The IP ranges of AWS change frequently. This requires you to develop an automated tool that regularly downloads the IP ranges JSON from AWS and updates your firewall configuration. Failure to do so might lead to NEXT not being accessible.
Q: What's the impact of not allowing WebSockets/WebRTC traffic?
NEXT requires WebSockets/WebRTC for real-time collaboration. Not allowing these protocols will degrade the user experience as following:
When not allowing WebRTC: Users won't see text entered by other users in the editor character-by-character but in chunks with a lag of a couple of seconds. Also, the editor won't show the avatar/cursor of other users who are working at the same time in the editor.
When not allowing WebSockets: Users won't receive any real-time updates. This means that changes made by one user (e.g. move cards in the board, enter text in editor, rename a project, etc.) won't be visible to other users - and other users might in turn overwrite these changes. It's therefore highly advised to have WebSockets enabled or ensure organizationally that not more than one user is working in a project at a time.
Q: Can WebRTC be used over TCP - instead of UDP?
WebRTC should generally be ran over UDP because UDP's more lenient nature means that small connection issues are simply ignored. In contrast, TCP's strict reliability guarantees amplifies these small issues, leading to poor performance when something goes wrong in the connection. For that reason, NEXT uses by default always WebRTC over UDP.
The one situation when you might have to use WebRTC over TCP is if your enterprise firewall can't be configured to allow for UDP traffic.
Please follow these steps if you require WebRTC over TCP:
Contact Customer Success including the timeline from your IT department
Further reading: