Not sure if this helps or not, but I faced a similar issue with this network topology:
- LAN A (OpenStack cluster with a 192.168.2.0/24 internal network, NAT'd to the rest of the LAN via "floating" public IPs on 10.166.140.0/24)
- Jenkins master @ 192.168.2.10 or 10.166.140.10
- Jenkins slave 1 @ 192.168.2.11
- Jenkins slave 2 @ 192.168.2.12
- LAN B (3rd party data center, connected to LAN A via site-to-site VPN which NAT to 10.21.26.0/24 on LAN A)
- Jenkins slave 3 @ 10.21.26.50
- Jenkins slave 4 @ 10.21.26.51
The CLI worked as expected when using the master node's private ip address but not the master node's public ip address.
For example `java -jar jenkins-cli.jar -s http://192.168.2.10:8080/ help` worked, but `java -jar jenkins-cli.jar -s http://10.166.140.10:8080/ help` raised the error "SEVERE: I/O error in channel Chunked connection" on any slave.
The problem was ultimately the software firewall in the OpenStack cluster that only applied to the floating IPs (e.g., 10.166.140.0/24).
The resolution was to allowing UDP ingress on ports 1024-65535 and TCP ingress on ports 1024-65535 where the destination was the Jenkins master node and the source was my slaves public IPs (10.21.26.0/24 and 10.166.140.0/24).
After the firewall change, executing `java -jar jenkins-cli.jar -s http://10.166.140.10:8080/ help` worked as expected on all slaves in both data centers.
My $0.02 - there is some complex networking for CLI connections: there seems to be ICMP, UDP, and TCP in use at the same time, along with random (JNLP?) ports on the server. The CLI client could use connectivity checks and/or clearcut error messages to better explain when connectivity fails for a specific protocol/address/port.