ZTOne Changing Source port - local.conf location?

Community Support
1

I’m trying to figure out how to change the local source port used by ZTOne but am at a bit of a loss. I can’t seem to find the “local.conf” file mentioned in the manual for zerotier but I did find the following directories and files.

Mac OS
/Library/Application Support/ZeroTier/One
Win10
C:\ProgramData\ZeroTier\One

Both directories have a “zerotier-one.port” file which has the default ‘9993’ listed, but changing it doesnt seem to have an effect.

The reason I’m doing this is to accommodate multiple ZT clients behind a firewall with source port preservation turned on - this is causing a session clash when both clients try to reach out to the same IP with source port 9993 - causing them to constantly override each other.

2

I believe local.conf does NOT exist by default, its only used for custom additions.

You could try this in a local.conf? Change the port obv.

{
    "settings": {
        "primaryPort": [ "9993" ]
    }
}

https://github.com/zerotier/ZeroTierOne/blob/master/service/README.md

As a side note i have 20 clients behind a single address and have no issues, i only forward incoming 9993 to my router (which has zerotier) and no DNAT for 9993 outgoing.

3

Thanks Stevo!
I was trying that just as your message came in but dont think I had the syntax correct. I appreciate the example you provided.

Haven’t been able to confirm the change yet though, cant reboot and I’m not sure how to restart the ZT service on mac. Firewall still sees sessions beeing started from 9993.

Regarding your sidenote - I haven’t noticed any ZT issues, just a lot of logs in my firewall about session clashes coming from the same source port going to the same destination - probably the ZT relay.

4

Unfortunately it seems that this doesnt take effect, even after reboot on windows and Mac OS - sessions still being established from source port UDP 9993

5

Ah, seems a syntax error.

Try this, i was able to observe the change with netstat.

{
    "settings": {
        "primaryPort": "9994"
    }
}
6

Thanks Stevo,
But I think this has revealed a ZeroTier-One bug. It seems that the desktop client on both Mac and Windows 10 can’t deal with a change of the primary port.

On Mac, when starting the client I get a message “Could not connect to the server” with a Retry and Quit button.

On windows, the client starts but shows “NodeID: Unknown” and none of the configured networks are listed - it’s just a blank window when checking “Show Networks…”

7

Hi there. Yeah that is kind of an issue.
I haven’t tried this, but can you try editing the zerotier-one.port file, instead of using local.conf for this?

Or, try setting the secondaryPort or tertiaryPort instead of the primary port, and use that for your router.

8

Thanks for responding @zt-travis.
I took a look at the zerotier-one.port file, and it seems to be controlled by software as since rebooting with my local.conf file, the contents has updated to the new port value.

Are the secondary and tertiary port more ephemeral than the primary? My main reason for changing it is that when sessions are established from the same source port to the same destination and destination port such as the ZT servers - the firewall just overrides the previous clients existing session. This doesn’t seem to cause a noticeable issue with function at small scale (2-3 clients behind FW), but it does fill the FW logs with “Session clash” messages. I’m guessing that if the destination in question is trying to send a message back to client A, it likely will get delivered to client B or dropped due to some mismatch of session information.

9

Out of curiosity, which firewall os/firmware are using?

secondary and tertiary are chosen at random when the service starts. You could set one of those and manually map it in your router. And leave 9993 alone so the UI can use it.

Manually mapping ports in your router makes us sad though. Maybe you can turn off the random port mapping.

10

:slight_smile: I’m not manually mapping ports in the router. Sorry, its a little hard to clarify over text here but I’ll do my best.

I’m using a Fortigate 60F but this would apply to any Fortigate firewall running FortiOS v6.x and up, and probably most prior versions. The firewall does not support UPnP and by default will randomize the source port when NAT/PATing to the WAN interface. This makes it nearly impossible for ZT nodes or just about any p2p software to connect directly when both nodes are behind enterprise grade firewalls. So on my end, I enable “source port preservation” which at least keeps the source port when PATing to the WAN.

The problem arises when you have two or more inside hosts sending traffic to the same destination IP+Port like the ZT planet/leaf servers. Both hosts send from the same source port, now the firewall has a conflict, how does it differentiate the sessions when they are going to have the same NATed IP and PATed source port, going to the same Destination IP+Port? It can’t, so it logs a session clash and allows the most recent packet to override the session in it’s NAT table.

My workaround to this session clash, is just changing the default primary source port on ZT from 9993 to 9994 and up from there on clients that are behind the same Firewall, or just picking something in the ephemeral range.

Edit: Just re-iterating that I dont actually notice any negative impact from the session clashes on the firewall apart from the excessive logs. ZT seems to work just fine with the session clashes happening but I don’t really have the knowledge/expertise/visibility to tell if something is wrong unless the network connections completely fail. For the most part, this is just my OCD trying to clean up what I can see.

11

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.