# Does the Android client get a different subnet?

**URL:** <https://openziti.discourse.group/t/does-the-android-client-get-a-different-subnet/1478>\
**Category:** Uncategorized\
**Created:** [August 11, 2023, 8:00am UTC](https://openziti.discourse.group/t/does-the-android-client-get-a-different-subnet/1478 "2023-08-11T08:00:42Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![jptechnical](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/jptechnical/32/1089_2.png) [@jptechnical](https://openziti.discourse.group/u/jptechnical)\
**Post date:** [August 11, 2023, 8:00am UTC](https://openziti.discourse.group/t/does-the-android-client-get-a-different-subnet/1478/1 "2023-08-11T08:00:42Z")

</div>

I’m testing with an android and I’m getting a 169 subnet. Is that normal?

 ![Screenshot_20230810-235818](https://global.discourse-cdn.com/free1/uploads/netfoundry/original/2X/2/2f524589350105566f202ab05c08d6afef7d4966.png)

---

<div class="post-metadata">

**Author:** ![scareything](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/scareything/32/106_2.png) [@scareything](https://openziti.discourse.group/u/scareything)\
**Post date:** [August 11, 2023, 1:00pm UTC](https://openziti.discourse.group/t/does-the-android-client-get-a-different-subnet/1478/2 "2023-08-11T13:00:44Z")

</div>

[Yes](https://github.com/openziti/ziti-tunnel-android/blob/main/app/src/main/java/org/openziti/mobile/ZitiMobileEdgeActivity.kt#L129)

---

<div class="post-metadata">

**Author:** ![flamingm0e](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/flamingm0e/32/1183_2.png) [@flamingm0e](https://openziti.discourse.group/u/flamingm0e)\
**Post date:** [August 11, 2023, 1:05pm UTC](https://openziti.discourse.group/t/does-the-android-client-get-a-different-subnet/1478/3 "2023-08-11T13:05:46Z")

</div>

Is this customizable for us to push our own DNS servers?

---

<div class="post-metadata">

**Author:** ![jptechnical](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/jptechnical/32/1089_2.png) [@jptechnical](https://openziti.discourse.group/u/jptechnical)\
**Post date:** [August 11, 2023, 2:27pm UTC](https://openziti.discourse.group/t/does-the-android-client-get-a-different-subnet/1478/4 "2023-08-11T14:27:26Z")

</div>

Should DNS resolution work? I am unable to resolve the hostnames below with the `jptech.ssh.server` attribute, but I can ssh to them fine from `falkor`.

```auto
╭────────────┬─────────────────────┬────────┬────────────────────────────────┬─────────────╮
│ ID │ NAME │ TYPE │ ATTRIBUTES │ AUTH-POLICY │
├────────────┼─────────────────────┼────────┼────────────────────────────────┼─────────────┤
│ -xRENbWvR │ Jp.pixel7 │ Device │ jptech.admin │ Default │
│ 1-lwdbW83 │ linux.jptech.ziti │ Device │ jptech.ssh.server │ Default │
│ poMBu.ev3 │ mac.jptech.ziti │ Device │ jptech.ssh.server │ Default │
│ qcJwu.W83 │ falkor.jptech.ziti │ Device │ jptech.admin │ Default │
│ tJ9Bu.ev3 │ win.jptech.ziti │ Device │ jptech.ssh.server │ Default │
╰────────────┴─────────────────────┴────────┴────────────────────────────────┴─────────────╯

```

edit: it looks like with the ziti client running on my phone the internet doesn’t work. does the ziti client for android work like a VPN and route all traffic through the fabric as the default gateway?

edit2: no, it looks like I can ping IPs, but I can’t resolve addresses, even fabric ones.

---

<div class="post-metadata">

**Author:** ![ekoby](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/ekoby/32/14_2.png) [@ekoby](https://openziti.discourse.group/u/ekoby)\
**Post date:** [August 14, 2023, 12:57pm UTC](https://openziti.discourse.group/t/does-the-android-client-get-a-different-subnet/1478/5 "2023-08-14T12:57:14Z")

</div>

> [@jptechnical](#):
>
> does the ziti client for android work like a VPN and route all traffic through the fabric as the default gateway?

It is designed to only intercept ziti services and let all other traffic bypass. It is done by only adding appropriate routes to the VPN/tunnel interface -- from CGNAT block 100.64.0.0/10 or explicit service  
intercept CIDR blocks