Service address the same as router IP address

1

Hello,

So i have a service. in that service intercept config has 2 addresses(1 normal hostname, 2 ip address of the router server). The int config also specifies ports(ex. 7811, 80 tcp/udp).

When a identity has given dial access to this service, that user cant access any other service anymore or even ssh into the router server even. tunneler logs say that it cant connect to router.

It looks like there is some type of conflict, because of IP beeing the same as routers ip.

Is it possible to have this type of scenario work? How would it work?

2

When you start mixing IP addresses into the intercepts you need to be very careful because it's possible to create loops that aren't obvious. When you say "that user cant access any other service anymore or even ssh into the router server even", that sounds to me like somehow maybe you've overlapped an IP address? OpenZiti operates as a split tunnel, it can't prevent access to things on the network by itself but it's possible you might have inadvertently caused a routing issue. If you don't need the IP for the intercept, it's always easiest to leave them out, sometimes software won't allow for that setup and you must use IP's, so sometimes you need to use em.

Can you diagram what the deployment you want to achieve looks like and could you show me the ziti CLI commands you use to make the services? specifically, I care about how the intercept and host configs were created. I'd like to see the host.v1 and intercept.v1.

3

Hello,

Yes, the IP addresses of services and router do overlap(but not the ports).
Having services intercept address as an IP is a requirement and it must match the router in this case.

Heres the diagram of what i am trying to acheave:
example.drawio (1)

Heres int/host configs for those 2 services:

ziti edge create config service1.host.config host.v1 '{
    "forwardProtocol": true,
    "forwardPort": true,
    "address": "service1-server",
    "allowedPortRanges": [
      {
        "low": 80,
        "high": 80
      },
      {
        "low": 50000,
        "high": 60000
      }
    ],
    "allowedProtocols": [
      "tcp",
      "udp"
    ]
  }'
ziti edge create config service1.int.config intercept.v1 '{
  "protocols":["tcp", "udp"],
  "addresses":["12.34.56.78", "service1.example.com"], 
  "portRanges":[{"low":80, "high":80}, {"low": 50000, "high": 60000}]
}'

ziti edge create config service2.host.config host.v1 '{
    "address": "service2-server",
    "port": 7888,
    "protocol": "tcp"
}'
ziti edge create config service2.int.config intercept.v1 '{
  "protocols":["tcp"],
  "addresses":["12.34.56.78", "service2.example.com"],
  "portRanges":[{"low":7888, "high":7888}]
}'
4

When OpenZiti tunnelers intercept an IP, a route is added to the machine that points all traffic for that IP to the OpenZiti tun interface. Any ports that are not expected/intercepted are simply dropped. There's no way for us to get "split" the IP by port. That's why you can't ssh there when OpenZIti is running.

The simplest answer here, in my opinion, is to add a service to that router that allows interception and offloading of ssh. Then, when OpenZiti is running, the ssh packets would traverse the OpenZiti overlay and the user would know no different. If you want to (though I don't recommend it), you could "wildcard" the port. You can intercept ports [1-65535].

A more complex answer that might not be doable would be to create/use a different IP address or using fqdn-based intercepts.

IP intercepts are tricky. I'd just define what services you want intercepted

5

But it looks like if there are services with IP address of routers IP, the local tunneler cant connect to router itself as well. Everything stops working, all services, tunneler log shows error "unable to connect to Router x".

6

The tunnelers should create special routes (we call them exclusion routes) for controller and router IPs that prevent those IPs from being intercepted as services. If the tunneler can't connect to the router after the service intercepts are set up then something is probably going wrong with the exclusion route creation.

Which tunneler(s) are you using, and on which operating system(s)? Would you be willing to share logs with elevated log levels that show the tunneler starting up and to the point where you see "unable to connect to router" errors?