Hi there,
I would like to have ports 8006 and 8007 available to bind. Is it possible to do a range here, or only a single port?
ziti edge create config jptech.pve.cfg.host host.v1 '{
"address": "127.0.0.1",
"protocol": "tcp",
"port": 8006,
"listenOptions": { "identity": "$tunneler_id.name" }
}'
For this, what you do is use "forwardPort": true with allowedPortRanges and then on the intercept side you intercept ports 8006-8007.
So something like:
{
"allowedPortRanges": [ { "high": 8007, "low": 8006} ].
"forwardPort": true,
... all the other stuff
}
Is there any reason not to just always use this method of defining a port range? i.e. will it hurt if I never did a single port but always expressed a range in this way?
"address":"127.0.0.1",
"protocol":"tcp",
"allowedPortRanges": [ {"low":'"${LOWPORT}"',"high":'"${HIGHPORT}"'} ],
"forwardPort": true,
"listenOptions": { "identity": "$tunneler_id.name" }
}'
If you mean “always use forwardPort”, you’ll find out that sometimes, you want port 443 on the intercept side to land at port 8443 on the far side, and in that case, you cannot forward the port. So there are times when you don’t just decide to forward the port or protocol (since the same is true for protocol too). You can “forwardProtocol” and “allowedProtocol” too.
That’s what ZAC is doing when you toggle the forward options:
I think my question was more on the host config only. So if I understand your example, the incoming port from the intercept would be 8443 and the forwardPort on the host would not be 8443, so no traffic is passed. But if the host is not using 'forwardPort', then it is just accepting traffic to the stated port regardless of where it comes from. Is that close to being right?
Maybe another way to express that. Using the 'ForwardPort' method is more like a firewall rule... very explicit. On the other hand not using the 'forwardPort' is like a nat entry (let's ignore that there is a firewall rule in there too), anything on the outside to anything on the inside, but restricted to a single port.
“forwardPort” says “whatever port was intercepted, when it comes here use that port when you offload the service”.
Let’s use an example.
On the client, the user opened a browser and is trying to go to “https://my.intercept” (intercepting TCP:my.intercept:443). With “forwardPort” enabled, whatever port was intercepted would get relayed to the actual.host so it would be port :443. The actual.host though is listening on :8443 so traffic gets to the far router, but “nothing works” because the router tries to attach to :443. Here, you will clearly see an error in the router logs indicating the dial failure to actual.host:443 . That clearly won’t work, so in that situation “forwardPort” will not work for you. You would have to specifically “nat” from the intercepted :443 to the remote :8443 by not using “forwardPort”.
“forwardPort” is super useful when you are intercepting ranges, or multiple ports and you want to just relay them to the remote.
Other than this one small “issue”, you can always use forwardPort if you want! There’s no downside.
I’ll just add that allowedPortRanges (and allowedAddresses, allowedProtocols) from the host.v1 config schema are effectively white lists that give the hosting endpoints control over where they connect to when the forward* booleans are enabled.
We have discussed the possibility of NATing when forwarding connection addresses from the intercepting tunneler to the hosting tunneler. It would certainly be neat, but to my knowledge it’s not high on the list of things folks are asking for.
What is the current best practice, then, for a service that has multiple non-contiguous ports?
For instance, I have a service needing a tunneler with ports tcp/udp:1600, TCP:5501, udp:5555. How can I express that with the least number of policies/configs?
