Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

settings/primaryPort not fully respected #915

Open
darkain opened this issue Feb 5, 2019 · 6 comments
Open

settings/primaryPort not fully respected #915

darkain opened this issue Feb 5, 2019 · 6 comments
Labels
BSD BSD-related issue Status: Backlog Older issues that are awaiting resolution Type: Bug Bug to be resolved

Comments

@darkain
Copy link
Contributor

darkain commented Feb 5, 2019

Describe the bug
Relates to the issues with: #779

If a connection cannot be established on the primary port (usually 9993), then ZeroTier will pick an arbitrary port to try and use instead. This defeats the entire purpose of having a primary port configuration. I have specific firewall rules in place for 9993 for a combination of security and to deal with issue #779. However, at some point ZT added support to "try other ports" that are outside of the configuration, which means the firewall rules in place for #779 no longer work, which means route flapping returned, broken connections, and excessively high CPU usage again. I also tried disabling port mapping to see if that was the issue, but this didn't resolve the issue either. There needs to be a way to force ZT to use one port and one port ONLY.

  • OS: FreeBSD 11.2
  • ZeroTier Version: 1.2.12
  • Hardware: Any (several tested)
@cferrey
Copy link

cferrey commented Mar 19, 2019

Just curious: does anyone know if this was addressed through a recent update? I was getting this flapping behavior pretty regularly in a bridged-LANs-over-WAN setup, but it stopped about 2-3 weeks ago and everything's been stable since then. I didn't change anything, so am wondering if this got patched.

@laduke
Copy link
Contributor

laduke commented Apr 29, 2019

source

Seems like a small change... but how to specify it?

Should just using -p on the commmand line turn off secondary port and upnp port? That's probably not what you want most of the time. Most users are behind NAT.

'secondaryPortEnabled': true|false to go along with portMappingEnabled?

or how about

'maxBindPorts': 1-32 (default 3) heh

@KBrownConsulting
Copy link

I think I'd vote for something along the lines of option 2... Clear individual options for controlling whether UPnP & the secondary port are enabled or disabled.

@darkain
Copy link
Contributor Author

darkain commented May 11, 2019

For firewall security reasons, I need the ability to fully control all incoming/opened ports on my server/router. This is ESPECIALLY true when talking about security audit compliance, such as PCI-DSS. Every open port must be justified to an external audit company, and with ZT arbitrarily opening additional ports if there are ANY issues at all with the defualt 9993 just causes havoc for these security audits (as well as the route flapping issue causing 100% CPU usage and dropped packets)

@joseph-henry
Copy link
Contributor

@darkain Thanks, we've added the ability to turn off any non-primary port assignments via:

'secondaryPortEnabled': true|false

@Teteros
Copy link

Teteros commented Jul 30, 2019

This landed in 1.4.0 stable, but the config setting is actually allowSecondaryPort (true/false, where false disables the extra port bindings.)
secondaryPortEnabled doesn't even exist in the code.

I assume this basically also sets portMappingEnabled to false as well?

@unquietwiki unquietwiki added Status: Backlog Older issues that are awaiting resolution BSD BSD-related issue labels Aug 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BSD BSD-related issue Status: Backlog Older issues that are awaiting resolution Type: Bug Bug to be resolved
Projects
None yet
Development

No branches or pull requests

8 participants