Mobile Client to Internal Web Server

Hi all, what am I missing.

What I am trying to do it connect a mobile client to a web server. I have used the quickstart installer and fully on-prem. Mobile edge client is installed on Android mobile and it will connect to the controller and I can see the test service available.

I used the Quick Service to create my test service.

I have 3 web servers on an internal network, I have 1 server with edge router installed which is in the same subnet as the 3 web servers.

I have attached an image of our network and an image of what I setup for the service.

Thanks

Hi @mphayesuk,

Thanks for these details! Very helpful. To me, things appear to be setup correctly from what I can see. Your @RU1 user should have one service showing up in the android app named "Test2". It should be able to send traffic to "https://mms.ziti.local:443" (you obviously don't need to supply the port). That traffic will tunnel through the public edge router in the DMZ through to the private edge router in DMZ 2 and should offload from that router towards 192.168.11.100:443 (which is your server 4) shown.

I assume things are NOT working -- which is why you posted. :slight_smile: If it was me, here are the things I would check in order. Unfortunately, I don't think most of these are exposed in the ZAC yet so you'll need to use the ziti CLI and it's easier for me to copy/paste those commands into the forum. I hope that's ok...

First, verify both routers are online. You should see two and both with "online" true:

ziti edge list edge-routers

Check that there's a link between the routers. You should see one link between the two routers

ziti fabric list links

ssh to server 5 -- confirm that it can access the target service using curl or openssl:

curl -sk https://192.168.11.100:443

run policy advisor and make sure the @MM01 identity can 'bind' the service and that @RU1 can 'dial' the service:

ziti edge policy-advisor identities -q

You should see something like:

OKAY : clint (1) -> docker.whale (1) Common Routers: (1/1) Dial: Y Bind: N
OKAY : ip-172-31-11-231-edge-router (1) -> docker.whale (1) Common Routers: (1/1) Dial: N Bind: Y

If all those things are ok -- next I would look at the logs from the phone and see if there's any hints in the logs as to what might be going wrong. If nothing, then look at the logs from first the MMS01 router, then the DMZ Zone 1 router to make sure there's nothing going wrong.

If you see any errors, often they'll be enough to understand what went wrong but please email them to help @ openziti.org if you want to send them to me/us to look at.

Hopefully that helps!

Ok, so even though in the UI the 2 Edge routers are both online, when I run your command I can see Certificate errors:

I ran the commands on the Controller/EdgeRouter/Console server:

root@T1S-MGS-ZTG01:~# ziti fabric list links
[ 0.036] INFO ziti/ziti/cmd/helpers.StandardErrorMessage: Connection error: Get https://T1S-MGS-ZTG01:1280/fabric/v1/links: tls: failed to verify certificate: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "T1S-MGS-ZTG01-edge-controller-root-ca Root CA")
Unable to connect to the server: tls: failed to verify certificate: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "T1S-MGS-ZTG01-edge-controller-root-ca Root CA")
root@T1S-MGS-ZTG01:~# ziti edge list edge-routers
RESTY 2024/05/20 00:44:00 ERROR Get "https://T1S-MGS-ZTG01:1280/edge/management/v1/edge-routers": tls: failed to verify certificate: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "T1S-MGS-ZTG01-edge-controller-root-ca Root CA"), Attempt 1
RESTY 2024/05/20 00:44:00 ERROR Get "https://T1S-MGS-ZTG01:1280/edge/management/v1/edge-routers": tls: failed to verify certificate: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "T1S-MGS-ZTG01-edge-controller-root-ca Root CA"), Attempt 2
RESTY 2024/05/20 00:44:00 ERROR Get "https://T1S-MGS-ZTG01:1280/edge/management/v1/edge-routers": tls: failed to verify certificate: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "T1S-MGS-ZTG01-edge-controller-root-ca Root CA"), Attempt 3
RESTY 2024/05/20 00:44:00 ERROR Get "https://T1S-MGS-ZTG01:1280/edge/management/v1/edge-routers": tls: failed to verify certificate: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "T1S-MGS-ZTG01-edge-controller-root-ca Root CA"), Attempt 4
RESTY 2024/05/20 00:44:01 ERROR Get "https://T1S-MGS-ZTG01:1280/edge/management/v1/edge-routers": tls: failed to verify certificate: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "T1S-MGS-ZTG01-edge-controller-root-ca Root CA"), Attempt 5
error: unable to list entities at https://T1S-MGS-ZTG01:1280/edge/management/v1/edge-routers in Ziti Controller at https://T1S-MGS-ZTG01:1280/edge/management/v1. Error: Get "https://T1S-MGS-ZTG01:1280/edge/management/v1/edge-routers": tls: failed to verify certificate: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "T1S-MGS-ZTG01-edge-controller-root-ca Root CA")
root@T1S-MGS-ZTG01:~#

Ah. Those errors are coming from the ziti cli itself. It's got the old certificate from your first install cached i think. Were you able to use the ziti cli to login? You might need to remove the $HOME/.config/ziti folder and login again.

Can you make sure you can use the cli to login? Because you had to recreate the network, the cached certificates I think are causing troubles.

Ok, removing that directory fixed those certificate errors and I can now also login voa the CLI.

Running the ziti edge list edge-routers returns a list containing the 2 edge routers that I have

Running ziti fabric list links returns:
root@T1S-MGS-ZTG01:~# ziti fabric list links
╭────┬────────┬──────────┬─────────────┬─────────────┬─────────────┬───────┬────────┬───────────╮
│ ID │ DIALER │ ACCEPTOR │ STATIC COST │ SRC LATENCY │ DST LATENCY │ STATE │ STATUS │ FULL COST │
├────┼────────┼──────────┼─────────────┼─────────────┼─────────────┼───────┼────────┼───────────┤
╰────┴────────┴──────────┴─────────────┴─────────────┴─────────────┴───────┴────────┴───────────╯
results: none

Do you think I need to re-create my services now that I have fixed the certifiate issue errors?

I don't think you will need to touch the services, no. I think your issue right now is that your private router can't form a link to the public router based on the fact there's no link.

I expect you want the private dmz2 router to dial out to the router in dmz1? Can you check the link listener configuration on that router? Make sure your dmz2 router can connect to the address and port in the dmz1 router configuration.

That make sense?

Ok, so the yml config file on DMZ2 has the correct entries in to reach DMZ1, I have checked the firewall logs and traffic is allowed.

Where do I need to check the "link listener configuration"

I also ran the edge policy-advisor identities -q on the controller and got the following response:

root@T1S-MGS-ZTG01:~# ziti edge policy-advisor identities -q
OKAY : RU1 (2) -> Test2 (2) Common Routers: (2/2) Dial: Y Bind: N

OKAY : RU1 (2) -> TestMMS-Service (2) Common Routers: (2/2) Dial: Y Bind: N

ERROR: T1S-MGS-ZTG01-edge-router

  • Identity does not have access to any services. Adjust service policies.

ERROR: Default Admin

  • Identity does not have access to any services. Adjust service policies.

OKAY : MMS01 (2) -> Test2 (2) Common Routers: (2/2) Dial: N Bind: Y

OKAY : MMS01 (2) -> TestMMS-Service (2) Common Routers: (2/2) Dial: N Bind: Y

Link listeners are configured in the config file. You'll also need to make sure the port is available for the other router to reach it. Only one side needs to be open so one router can reach the other to form the connection.

From the DMZ 2 server, can you issue an openssl s_client -connect dmz1.server1:port | openssl x509 -text and can you confirm the certificate that's returned matches that advertised link? From our other conversation:
Identity Enrollment Uses Local Hostname and not External Hostname - #4 by TheLumberjack the relevant section is the "link listeners" from:

And routers at:

ctrl -> endpoint
link -> listeners -> advertise
listeners -> address

The router in dmz 2 will reach out to the router in dmz 1 based on that "link -> listeners -> advertise" field.

When setting up the routers, that's another field that's easy to miss. It's generally controlled by the ZITI_ROUTER_ADVERTISED_ADDRESS variable when running the quickstart.

It should look something like this:

link:
  dialers:
    - binding: transport
  listeners:
    - binding:          transport
      bind:             tls:0.0.0.0:10080
      advertise:        tls:ec2-3-142-245-63.us-east-2.compute.amazonaws.com:10080

Is that advertise address correct and when you issue the openssl connect request, does the DNS sans returned have this value? Example mine looks like this:

            X509v3 Subject Alternative Name:
                DNS:localhost, DNS:ec2-3-142-245-63.us-east-2.compute.amazonaws.com, DNS:ip-172-31-11-231, IP Address:127.0.0.1

Ok, I can confirm that the certificate mates the advertised one in DMZ1.

This is my config from DMZ2, I did the auto enroll on the DMZ2 server (in case that makes a difference)

v: 3
identity:
cert: /opt/openziti/ziti-router/certs/cert.pem
server_cert: /opt/openziti/ziti-router/certs/server_cert.pem
key: /opt/openziti/ziti-router/certs/key.pem
ca: /opt/openziti/ziti-router/certs/ca.pem
ctrl:
endpoint: tls:T1S-MGS-ZTG01:6262
link:
dialers:
- binding: transport
edge:
heartbeatIntervalSeconds: 60
csr:
country: US
province: NC
locality: Charlotte
organization: NetFoundry
organizationalUnit: Ziti
sans:
dns:
- localhost
ip:
- 192.168.11.253
- 127.0.0.1
listeners:

  • binding: edge
    address: tls:0.0.0.0:443
    options:
    advertise: 192.168.11.253:443
  • binding: tunnel
    options:
    mode: tproxy
    resolver: udp://192.168.11.253:53
    lanIf: eth0
    dnsSvcIpRange: 100.64.0.0/10

Ok, so doing some digging around and I found this on my DMZ2 Edge server:

{"error":"error dialing outgoing link [l/TJw2FtdgFTxlpe38kxPTm@1]: error dialing payload channel for [l/TJw2FtdgFTxlpe38kxPTm]: dial tcp 10.10.5.250:10080:

Where has it got port 10080 from? And is this an important error?

Yes. port 6262 is import for the DMZ 2 router to get to the controller, 10080 is important for the DMZ 2 router to connect to (and forma a link) to the DMZ 1 router.

So yes you'll need to make sure that 10.10.5.250:10080 is available from the DMZ 2 router to connect to DMZ 1

1 Like

That looks better, now I have a link:

Great! Now, does your service work? :slight_smile:

I am going to say yes, even though at the moment it doesnt.

I get a certificate warning from my webserver which means it works :slight_smile:

But what my webserver does at the moment is a redirect, so no matter what address you type in to the webserver it will always redirect you to the common domain name.

So with that in mind I guess all that I would need to do is add that address to the service config here:

image

Yep! :slight_smile: Even getting a 404 would have indicated success. HTTPs is fickle for sure. If you can set it, often you can get away with just using the Host header. For example with curl, you oftne need to add it if your proxy is looking for that header:

curl -H "Host: my.actual.server.name" https://some.other.intercept.here

Seems like you've got it all fixed up though! :slight_smile:

Yep, I can have a propper play around after I update my notes.

Once again a massive thanks for the support this community is giving me, its really appreciated.

1 Like