Interesting issue with multiple networks

1

Hi there, I’ve got another interesting thing happening on my local machine that I thought I would throw out there, and see what I could have done to make this one happen :wink:

I am on windows 11, and have set up a ziti network for work, and also one for personal. I have the ziti windows tunneller installed.

I also am using wsl2, in which I have installed the linux tunneller on as well, as i use that for dev stuff, getting onto work resources etc.

For the work configuration, I have a *.xyz.local wildcard service setup , for all (0-65535) ports , basically just to let me get anything from the work network for now.

I have a specific web service I am exposing of my personal network, https://service.abc.com:443

Both identities to both fabrics are enabled on the windows client.

Every now and then, I try to go to a service at https://blah.xyz.local, and I actually get the website from https://service.abc.com

Strange?
any ideas?
Thanks

2

so you have the ZDEW installed and you have ziti-edge-tunnel in linux setup. First, that works?!!?!!?? <clint goes to try it> WOAH who knew! In the past there has not been a TUN available, but now there is. That’s neat…

Now that I learned that it’s possible to run ziti-edge-tunnel in WSL, running that along with the ZDEW sounds like a recipe for questionable behavior like this. I expect the integration between WSL and Windows is “a little too tight” and is causing issues here and leading to unexpected behavior. If you want two clients on a single machine, I’d urge you to run an “actual” VM instead of WSL. If you just want WSL to have access to the overlay network of your choice (which is how I do it), then it “should just work”.

Does WSL “not work” with ZDEW running? Is that not happening for you? Or are you trying to have two actually separate clients (if so, I’d recommend using a legit virtual machine, as mentioned)

3

Sorry about that, yep I’ve disabled the tunneller from wsl2. Windows client is still doing the same thing and wsl seems to be happy enough and is resolving what I need it to…so cancel the linux tunneller thing :wink:

However the wildcard thing is strange, my gut feel is that its still something weird going on with my config. I’ll take a fresh look tomorrow and see if I can track down the issue

4

Buckle up… We’re going deep…

Ok so bringing it back to what I think “the problem” is. I’m still worried that somehow “windows” itself is somehow in this mix. I’m gonna recap my understanding and hopefully clarify the setup in my own head.

You have ziti-edge-tunnel running in WSL, using “wsl-identity”, providing access to “*.xyz.local” from within WSL only.

You have ZDEW running in Win11, using “win11-identity”, providing access ONLY to personal service “service.abc.com”. Please confirm this identity only has access to a single service and doesn’t also have access to the wildcard service?

Then, from WSL, when you curl to http://blah.xyz.local, you’re getting access to http://service.abc.com.

I think I might know why. I don’t have an environment with all this setup to test it, but I my WSL ziti-edge-tunnel and my windows ZDEW are assigned both 100.64.0.0 addresses. If that’s the case, the VERY FIRST wildcard service you access will be assigned to 100.64.0.3 — BUT — your windows ZDEW will also assign 100.64.0.3 (in windows) to service.abc.com.

Can you confirm that the tun in linux – and the wintun adapter (adapter ziti-tun0) are both getting the 100.64.0.0 address space assigned to them? I bet that is what happens… I think that’s the case. Assuming it is… Why wildcard is important.

Wildcard IP assignment

When using a wildcard service, for every service you resolve, you will get a new IP address starting at TUN + 1, and that’s why this seems to be ‘random’ to you, because it’ll be dependent on the order in which you access the wildcard services.

Let me illustrate:

  • turn on ZDEW – notice (via ipconfig)
  • turn on linux ziti-edge-tunnel
  • notice both get 100.64.0.0 IP addresses (shown below)
    image
    image1324×165 13.8 KB

Now access blah.xyz.local and then dig it: dig blah.xyz.local and it’ll be assigned IP 100.64.0.3. Now access some OTHER service, foo.xyz.local and dig THAT. you’ll see it’ll be assigned IP 100.64.0.4 and so on…

At this time, using cmd.exe in windows you can try to nslookup… nslookup service.abc.com 100.64.0.2 and I assuming it’s the only service, it will come back as 100.64.0.3…

IMPORTANT NOTE. You now have two services, in two networking spaces, assigned to 100.64.0.3 based on “how OpenZiti works”… And THIS is where I think the problem comes. So depending on what wildcard service you’re accessing after turning ziti on in WSL land, that first service will overlap the ZDEW service…

Is this all making sense??? :slight_smile: It makes sense to me but it’s definitely an intricate web and I’m doing a bunch of hand-waving and assuming. lol

How do you fix this

Ok, so the easiest solution to fix this would be to move your ziti-edge-tunnel to a different IP space

sudo ./ziti-edge-tunnel run /mnt/v/temp/id.json --dns-ip-range 100.64.100.100/16

ifconfig tun0
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 100.64.100.100  netmask 255.255.255.255  destination 100.64.100.100

I think that’s all you need to do… Assuming my hand-waving and assuming is correct :slight_smile:

looking forward to hearing back from you

5

This scenario will be close to what I am looking at configuring. Working for a MSP, I am looking at creating separate Ziti networks for customers. While this will not be a problem for the customers employees, it sounds like it would impact me (assuming what you have said above) is the reason.

6

As long as you only run “one tunneler per machine” you’ll be fine. I am afraid that WSL2 and Windows is ‘close enough’ that the fact that both OS’es are running a tunneler – and both are configured to use 100.64.x.x is what is causing the confusion in Windows…

If you have 100s of identities in your ONE tunneler, it should be just fine. Running a tunneler in a “proper” virtual machine is fine too since that network space is actually separate. I think WSL is just special because in how MS is making WSL use the windows network. I’m not entirely sure - it just feels like a special situation that I don’t think would apply to you?

7

@TheLumberjack Makes total sense! - I had actually thought that as well when mucking around with it. However once I uninstalled the tunneller on wsl, both windows and wsl are getting the same ip for the same dns lookup via the wildcard so I think that cancels out any issues in that regards.

I thought then, it could have been configuration, but using it on my mobile with both networks, it works as expected, so this issue is just specifically with the windows tunneller by the looks.

Note I’m using 2.1.10 latest version from github, as I saw the fix was in for proxy resolution should not be case sensitive · Issue #566 · openziti/ziti-tunnel-sdk-c · GitHub

so here is part of the log , which looks weird

[2023-01-05T03:24:16.173Z]   DEBUG tunnel-cbs:ziti_dns.c:341 ziti_dns_lookup() matching domain[*.xyz.local] found for tnas001.xyz.local
[2023-01-05T03:24:16.173Z]    INFO tunnel-cbs:ziti_dns.c:296 new_ipv4_entry() registered DNS entry tnas001.xyz.local -> 100.64.0.25
[2023-01-05T03:24:16.173Z]    INFO tunnel-cbs:ziti_dns.c:500 format_resp() found record[100.64.0.25] for query[1:tnas001.xyz.local]
[2023-01-05T03:24:16.173Z]   DEBUG tunnel-sdk:ziti_tunnel.c:434 ziti_tunneler_close() closing connection: client[udp:100.64.0.1:54929] service[ziti:dns-resolver]
[2023-01-05T03:24:16.173Z]   DEBUG tunnel-sdk:tunnel_udp.c:112 tunneler_udp_close() closing ziti:dns-resolver session
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range [0-65535]
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range [0-65535] with score 65535
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 447
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T03:24:16.185Z]   DEBUG tunnel-sdk:tunnel_tcp.c:109 new_tcp_pcb() snd_wnd: 65535, snd_snd_max: 65535, mss: 32768
[2023-01-05T03:24:16.185Z]   DEBUG tunnel-sdk:tunnel_tcp.c:398 recv_tcp() intercepted address[tcp:100.64.0.25:443] client[tcp:100.64.0.1:51269] service[selectronics]
[2023-01-05T03:24:16.185Z] VERBOSE tunnel-cbs:ziti_tunnel_cbs.c:287 ziti_sdk_c_dial() ziti_dial(name=selectronics)
[2023-01-05T03:24:16.185Z]   DEBUG tunnel-cbs:ziti_tunnel_cbs.c:356 ziti_sdk_c_dial() service[selectronics] app_data_json[175]='{"connType":null,"dst_protocol":"tcp","dst_hostname":"tnas001.xyz.local","dst_ip":"100.64.0.25","dst_port":"443","src_protocol":"tcp","src_ip":"100.64.0.1","src_port":"51269"}'
[2023-01-05T03:24:16.185Z] VERBOSE ziti-sdk:connect.c:103 conn_set_state() conn[1.0/Initial] transitioning Initial => Connecting

so I’m going to the website https://tnas001.xyz.local. This is then getting sent over to my other private personal fabric, with the service named selectronics.

the selectronics service is set for selpi.abc.com, so nothing to do with tnas001.xyz.local…

selpi resolves to 100.64.0.3
tnas001 resovles to 100.64.0.25

Now, when I turn off my personal fabric. it redirects to another specific service

[2023-01-05T04:05:13.907Z]    INFO tunnel-cbs:ziti_dns.c:296 new_ipv4_entry() registered DNS entry tnas001.xyz.local -> 100.64.0.22
[2023-01-05T04:05:13.907Z]    INFO tunnel-cbs:ziti_dns.c:500 format_resp() found record[100.64.0.22] for query[1:tnas001.xyz.local]
[2023-01-05T04:05:13.907Z]   DEBUG tunnel-sdk:ziti_tunnel.c:434 ziti_tunneler_close() closing connection: client[udp:100.64.0.1:63897] service[ziti:dns-resolver]
[2023-01-05T04:05:13.907Z]   DEBUG tunnel-sdk:tunnel_udp.c:112 tunneler_udp_close() closing ziti:dns-resolver session
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range [0-65535]
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range [0-65535] with score 65535
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 447
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 443 to range 443
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 443 matches range 443 with score 0
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 443 is best match so far
[2023-01-05T04:05:13.910Z]   DEBUG tunnel-sdk:tunnel_tcp.c:109 new_tcp_pcb() snd_wnd: 65535, snd_snd_max: 65535, mss: 32768
[2023-01-05T04:05:13.910Z]   DEBUG tunnel-sdk:tunnel_tcp.c:398 recv_tcp() intercepted address[tcp:100.64.0.22:443] client[tcp:100.64.0.1:54273] service[stafford.esxi]
[2023-01-05T04:05:13.910Z] VERBOSE tunnel-cbs:ziti_tunnel_cbs.c:287 ziti_sdk_c_dial() ziti_dial(name=stafford.esxi)
[2023-01-05T04:05:13.910Z]   DEBUG tunnel-cbs:ziti_tunnel_cbs.c:356 ziti_sdk_c_dial() service[stafford.esxi] app_data_json[175]='{"connType":null,"dst_protocol":"tcp","dst_hostname":"tnas001.xyz.local","dst_ip":"100.64.0.22","dst_port":"443","src_protocol":"tcp","src_ip":"100.64.0.1","src_port":"54273"}'
[2023-01-05T04:05:13.910Z] VERBOSE ziti-sdk:connect.c:103 conn_set_state() conn[0.5/Initial] transitioning Initial => Connecting

To me it looks like its getting confused with which port to match?

8

Hi @cjpit. Thanks for this information. When you state “you are going to the website” - is that in Windows or from linux? It sounds like from windows, but let’s just confirm that too.

I saw your edit too just now, you’re saying that with the personal fabric off (using the UI I assume you disabled the identity) that the same intercpt went to a totally different service?

I’ll have to setup a wildcard service tomorrow and test this out myself. Can you give me some basic idea about how many services are on the far side of the wildcard and how many you hit, any specific conditions you can reproduce etc.

If you’re ok with it - can you send me your ‘feedback’ zip file from “main menu->feedback”? there’s some info in there and logs so if you want to look at the info it collects, please do. If you’re cool with sending that to clint at openziti.org… that’d be hepful for me to look at the full logs.

9

when you go to "https://tnas001.xyz.local/" that will use :443 by default. That's not the port you wanted?

10

That is the right port, it’s just that I have like maybe 10 other services mapping port 443. It looks like it’s trying to match the wildcard rule , which is from 0-65535, but maybe it doesn’t match it, then goes and uses the service stafford.esxi, (which is port 443 as well) - Thats what I was thinking?

I’ll send through the zip, thanks heaps for taking a look when you can.

11

Thanks for sending the logs over. I think I see now what was strange in your log snippet from before. I’m entirely convinced that it’s a bug in the tunneler. Here’s what happens:

  • each of your services being processed by the tunneler
  • stafford.esxi is assigned IP 100.64.0.4
  • a request comes in for matching domain[*.cla.local] found for tnas001.cla.local
  • the tunneler processes the wildcard match and assigns tnas001.cla.local -> 100.64.0.22
  • tunneler correctly returns 100.64.0.22 to the DNS response
  • intercepts the proper IP with on the proper port, but then mismaps the service entirely

I’ll file a bug for this and we’ll get cracking on a fix… Thanks for the details and reporting the issue!

Filed issue Wildcard services not properly mapping port in range · Issue #578 · openziti/ziti-tunnel-sdk-c · GitHub

12

Thank you @TheLumberjack no worries, if you need anything else just let me know, I’ll keep an eye on the github issue

13

Thanks for catching this, @cjpit! I found the issue that was causing the wrong service to be connected, and a pre-release containing the fix is at Release 2.1.11 · openziti/desktop-edge-win · GitHub.

14

Awesome gave it a run this morning and it’s all working great now…Thank you!

1 Like
15

Awesome. Thanks for finding the issue and reporting it and confirming it’s fixed. The official release will come out soon.

16

Seems this bug has come back…
running 2.1.13.0 service 2.1.13

[2023-02-13T03:11:16.294Z] DEBUG tunnel-sdk:ziti_tunnel.c:465 ziti_tunneler_close_write() closing write connection: client[tcp:100.64.0.1:50791] service[xyz]

this is the wrong service its dialing…

17

rebooted and this seemed to fix it, so will put it down to random windows updates or something like that…

18

You’re sure that you didn’t change the overlay at all, right? That particular behavior is not one that is reported as some kind of “random” behavior.

This behavior is usually caused by an administrator configuring the same exact intercept address and port for two separate services by mistake. Detecting that situation at the server is nearly impossible because the client can participate on multiple ziti overlay networks so we need to do it at the client. I can assure you that I’ve not seen a bug like this for well over two years now (if not longer) and none of the other 1000’s of windows users we have seem to have the problem. If you were adding/removing identities it’s possible something didn’t get cleaned up correctly too, a restart would definitely have fixed that situation.

Regardless, glad to hear you’re up and running again!