Access cifs/smb2 share over edge router

Hi there,
I'm currently trying to get a hold of all the different concepts and configurations of ziti, so apologies if I mix up anything.

I've setup two routers ('ad-ztna01' and 'fsn-ztna01') in different networks. Both with "isTunnelerEnabled": true and "noTraversal": false.
ad-ztna01 is unused here I guess.

My goal is to access this smb2 share on 'u123456.your-storagebox.de' with the windows client from the network of 'fsn-ztna01' (as the share is only reachable on the local network of fsn-ztna01).
A capture with wireshark on ziti-tun0 interface on the windows client shows traffic with questionable source and destination addresses.
I see a DNS query from 99.23.0.1 to 99.23.0.2 and get a reply with an A record to 99.23.0.4 while the true public IP of u123456.your-storagebox.de is 99.23.0.3.
There are packets going on port 139 and 445 but I'm unsure if they pass thru.

All IP addresses are fictitious.
I'm unsure what else I could look on.

I've setup an windows tunneler client with an identity and assigned the role 'storageboxes' to it.

I've created a service storageboxes.svc with configurations 'storageboxes.host.v1', 'storageboxes.intercept.v1' and service policy 'storageboxes.policy.dial' as well as a service-edge-router-policy 'storageboxes.policy.bind'.

{
  "name": "storageboxes.host.v1",
  "configTypeId": "NH5p4FpGR",
  "data": {
    "allowedAddresses": [
      "u123456.your-storagebox.de"
    ],
    "allowedPortRanges": [
      {
        "high": 445,
        "low": 445
      },
      {
        "high": 139,
        "low": 139
      }
    ],
    "forwardAddress": true,
    "forwardPort": true,
    "protocol": "tcp"
  }
}
{
  "name": "storageboxes.intercept.v1",
  "configTypeId": "g7cIWbcGg",
  "data": {
    "addresses": [
      "u123456.your-storagebox.de"
    ],
    "portRanges": [
      {
        "high": 445,
        "low": 445
      },
      {
        "high": 139,
        "low": 139
      }
    ],
    "protocols": [
      "tcp"
    ]
  }
}
{
  "name": "storageboxes.policy.dial",
  "appData": "",
  "serviceRoles": [
    "@1hCiDTGYDQY1nX5OqI3j9P"
  ],
  "identityRoles": [
    "#storageboxes"
  ],
  "postureCheckRoles": [],
  "semantic": "AllOf",
  "type": "Dial"
}
{
  "name": "storageboxes.policy.bind",
  "appData": "",
  "edgeRouterRoles": [
    "@HbKI.e4YRs"
  ],
  "serviceRoles": [
    "@1hCiDTGYDQY1nX5OqI3j9P"
  ],
  "semantic": "AllOf"
}

I would appreciate any help, thank you!

Hi @pgross, welcome to the community and to OpenZiti!

The OpenZiti private DNS feature on every OS varies. On Windows, you'll see the Ziti Desktop Edge for Windows (abbreviated ZDEW or ziti-edge-tunnel if you're running that directly) will use the Windows NRPT in order to determine where DNS requests are to be sent. So the flow would be:

app asks for connection to u123456.your-storagebox.de, windows looks in the NRPT for an entry and sees that a service exists and the request should be delivered to 100.64.0.2 (by default). DNS request goes to 100.64.0.2 (the ziti-edge-tunnel process) and returns an IP in the CGNAT space, for example 100.64.0.27 and the app sends traffic to that IP which is picked up by the ziti tun and off it goes over the overlay.

Are you using the ZDEW or ziti-edge-tunnel directly? To test if the client is intercepting correctly you would need to use nslookup with a server specified (nslookup is not Windows NRPT aware) - or you would use powershell and Resolve-DNSName (which is Windows NRPT aware).

For example, we use mattermost as our chat app and it's protected by OpenZiti

nslookup failure / working:

C:\Users\clint>nslookup mattermost.ziti.com
Server:  pi.hole
Address:  192.168.1.5

*** pi.hole can't find mattermost.ziti.com: Non-existent domain

----------

C:\Users\clint>nslookup mattermost.ziti.com 100.64.0.2
Server:  UnKnown
Address:  100.64.0.2

Non-authoritative answer:
Name:    mattermost.ziti.com
Address:  100.64.0.27

If you're using the ZDEW, do you see any services listed?

Thanks for the fast reply and warm welcome!

Yes, im using ZDEW and I see the storageboxes.svc

DNS lookup seems to work:

PS C:\Users\p.gross> Resolve-DnsName u123456.your-storagebox.de

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
u123456.your-storagebox.de                     A      60    Answer     100.64.0.4


PS C:\Users\p.gross> nslookup
Standardserver:  ad-dc01.ad.xyz.de
Address:  192.168.200.82

> u123456.your-storagebox.de
Server:  ad-dc01.ad.xyz.de
Address:  192.168.200.82

Nicht autorisierende Antwort:
Name:    u123456.your-storagebox.de
Addresses:  2a01:4f8:2b03:u1::2
          23.77.27.42

>

I just saw, that I don't have any terminators (according to ZAC) but I understood that they should be automatically created in my use-case?

Great. Yes you should have a terminator. Without a terminator, the OpenZiti client (in this case the ZDEW) won't know where to send traffic to (that's what the terminator is, where to send traffic to on the OpenZiti overlay).

The next step imo is to run the ziti CLI and policy-advisor. It will tell you if things appear to be setup properly.

Assuming you only have a few identities, I usually run it like this:

ziti edge policy-advisor identities -q

You'll see output like this:

ziti edge policy-advisor identities -q
ERROR: quickstart-router
  - Identity does not have access to any services. Adjust service policies.

OKAY : red-router (2) -> blue-hello (3) Common Routers: (2/2) Dial: Y Bind: N

ERROR: Default Admin
  - Identity does not have access to any services. Adjust service policies.

OKAY : blue-router (2) -> blue-hello (3) Common Routers: (2/2) Dial: N Bind: Y

See how in this example, I have an identity named 'blue-router' that has Bind permission to the 'blue-hello' service? Make sure you have an identity that can bind your service. Often this will be a router or ziti-edge-tunnel etc in some private networking space.

You could also limit the information shown to just the service in question with the services subcommand if you want:

ziti edge policy-advisor services blue-hello -q
OKAY : red-router (2) -> blue-hello (3) Common Routers: (2/2) Dial: Y Bind: N

OKAY : blue-router (2) -> blue-hello (3) Common Routers: (2/2) Dial: N Bind: Y

I'm sure you have a Dial, let's make sure you have a Bind?

Well I guess you narrowed down the problem:

root@ad-ztna01:~# ziti edge policy-advisor identities -q
OKAY : fsn-ztna01 (1) -> storageboxes.svc (1) Common Routers: (1/1) Dial: N Bind: Y

ERROR: p.gross (0) -> storageboxes.svc (1) Common Routers: (0/0) Dial: Y Bind: N 
  - Identity has no edge routers assigned. Adjust edge router policies.

But I honestly have no glue about how to bind the router to the service.
If I look at the router in ZAC, I see 'storageboxes.svc' as an associated service.

I've now created a new router policy, now showing this

root@ad-ztna01:~# ziti edge policy-advisor identities -q
OKAY : fsn-ztna01 (1) -> storageboxes.svc (1) Common Routers: (1/1) Dial: N Bind: Y 
OKAY : p.gross (1) -> storageboxes.svc (1) Common Routers: (1/1) Dial: Y Bind: N 

great. now after a moment you should be able to see terminators:

ziti edge list terminators

Cool. After that, assuming the offload config is correct, things should be working? Are you getting furthe along?

yes, I see the terminator now but unfortunately it's still not working.

root@ad-ztna01:~# ziti edge list terminators
╭────────────────────────┬──────────────────┬────────────┬─────────┬────────────────────────┬──────────┬──────┬────────────┬──────────────╮
│ ID                     │ SERVICE          │ ROUTER     │ BINDING │ ADDRESS                │ IDENTITY │ COST │ PRECEDENCE │ DYNAMIC COST │
├────────────────────────┼──────────────────┼────────────┼─────────┼────────────────────────┼──────────┼──────┼────────────┼──────────────┤
│ 7Csi7kEaGgk10K6opDweyR │ storageboxes.svc │ fsn-ztna01 │ tunnel  │ 7Csi7kEaGgk10K6opDweyR │          │    0 │ default    │            0 │
╰────────────────────────┴──────────────────┴────────────┴─────────┴────────────────────────┴──────────┴──────┴────────────┴──────────────╯
results: 1-1 of 1

Do I need 'bindUsingEdgeIdentity' in the host config?

No, you don't need that. Let's look now at the logs from the client side (and see if there's anything interesting in there) and if not, the next step would be to look a the logs from the far side tunneler.

There will likely be helpful logs in there telling us what went wrong, and where/why.

The tunnel log from the windows client (C:\Program Files (x86)\NetFoundry Inc\Ziti Desktop Edge\logs\service):

[2024-08-03T06:58:15.383Z]    INFO ziti-sdk:channel.c:775 reconnect_channel() ch[1] reconnecting in 128977ms (attempt = 25)
[2024-08-03T06:58:15.383Z]   ERROR ziti-sdk:channel.c:903 on_channel_connect_internal() ch[1] failed to connect to ER[fsn-ztna01] [-4081/operation canceled]
[2024-08-03T06:58:16.971Z]    INFO tunnel-cbs:ziti_dns.c:509 format_resp() found record[100.64.0.7] for query[1:u256416.your-storagebox.de]
[2024-08-03T06:58:18.055Z]    INFO tunnel-cbs:ziti_dns.c:509 format_resp() found record[100.64.0.7] for query[1:u256416.your-storagebox.de]
[2024-08-03T06:58:27.487Z]    WARN ziti-edge-tunnel:tun.c:483 refresh_routes() failed to create exclusion route[49.12.246.226]: 1168(Der Vorgang wurde erfolgreich beendet.

but I'm unable to find the log on the edge router. I deployed it using the debian package (not quickstart).
I'll try to use another service endpoint (http maybe) because I want to rule out that it could be a problem with the smb2 protocol or WINS.

apparently the client is unable to connect to the edge router.
here Tunnel unable to reach local router you proposed to check the router config. Mine looks as follows:

listeners:
# bindings of edge and tunnel requires an "edge" section below
  - binding: edge
    address: tls:0.0.0.0:3022
    options:
      advertise: fsn-ztna01.xyz.de:3022
      connectTimeoutMs: 5000
      getSessionTimeout: 60
  - binding: tunnel
    options:
      mode: host #tproxy|host

fsn-ztna01.xyz.de is publicly resolvable and 3022/tcp is opened in the firewall.

good news but rather humiliating, I forgot that the cloud provider had an own firewall in place, blocking access to 3022 even if I allowed access locally.

thank you very much for narrowing the issue down!

Sounds like things are working now then, that's great. If you end up hitting any more bumps along the way just let us know and I'm sure we'll get it sorted. :smiley:

1 Like