# From

## Summary

The **From** URL is the externally accessible URL for a proxied HTTP request.

Specifying `tcp+https` for the scheme enables [TCP proxying](https://www.pomerium.com/docs/capabilities/non-http.md) support for the route; `udp+https` enables [UDP proxying](https://www.pomerium.com/docs/capabilities/non-http/udp.md). (added in v0.29) You may map more than one port through the same hostname by specifying a different `:port` in the URL.

Specifying `ssh` for the scheme enables [native SSH proxying](https://www.pomerium.com/docs/capabilities/native-ssh-access.md).

## How to Configure

The from URL must contain a **scheme** and **hostname**. It can't contain a path. When defining a From URL, you must use `https`, `tcp+https`, `udp+https`, or `ssh`. Pomerium only supports secure schemes.

### Port Matching Behavior

In v0.26, we've updated the route matching behavior. If you do not specify a port number in a route's From URL, the route will match incoming requests with any port number (or no port number). If you do specify a port number, that route will match only requests containing that specific port number.

With a from URL like the one below:

```yaml
from: https://www.example.com
```

Pomerium will match incoming requests on any port:

```yaml
https://www.example.com

https://www.example.com:443

https://www.example.com:8443

https://www.example.com:3000
```

If you specify the port in the From URL, Pomerium will only match incoming requests that specify this port:

```yaml
from: https://www.example.com:8443
```

Previously Pomerium would require an exact match between the incoming request and the From URL port number.

You can revert to the previous behavior by setting the [`match_any_incoming_port`](https://www.pomerium.com/docs/reference/runtime-flags.md) runtime flag to false.

**Core:**

| **YAML**/**JSON** setting | **Type** | **Schemes** | **Usage** |
| :-- | :-- | :-- | :-- |
| `from` | `URL` | `https`, `tcp+https`, `udp+https`, `ssh` | **required** |

### Examples

```yaml
routes:
  - from: https://verify.corp.example.com
    to: https://example.com
  # Native SSH Access
  - from: ssh://ssh.corp.example.com:22
    to: ssh://ssh.local:22
  # TCP tunneling
  - from: tcp+https://ssh.corp.example.com:22
    to: tcp://ssh.local:22
  # UDP
  - from: udp+https://time.corp.example.com:13
    to: udp://time.local:13
```

**Enterprise:**

**Kubernetes:**

See Kubernetes [Ingress](https://www.pomerium.com/docs/deploy/k8s/ingress.md) for more information.

See [**Routing - Route matching order**](https://www.pomerium.com/docs/capabilities/routing.md#route-matching-order) for more information on how Pomerium processes and matches routes.

## Wildcard From Routes

Kubernetes: Wildcard From Routes in Kubernetes are unofficially supported because Pomerium's implementation behaves differently than what Kubernetes defines in their documentation. See [Wildcard Hostnames](https://kubernetes.io/docs/concepts/services-networking/ingress/#hostname-wildcards) for more information.

**Wildcard From Routes** supports the use of a wildcard asterisk (`*`) placed anywhere within the domain name portion of a `from` URL.

Defining a `from` route with `*` will point any matching routes to the defined [To route](https://www.pomerium.com/docs/reference/routes/to.md). This eliminates the need to define multiple near-identical routes in your configuration. ([Autocert](https://www.pomerium.com/docs/reference/autocert.md) will be disabled for hosts that use Wildcard From Routes.)

For example:

```yaml
# Before:
routes:
  - from: https://a.example.com
    to: https://example.com
  - from: https://b.example.com
    to: https://example.com
  - from: https://c.example.com
    to: https://example.com
  - from: https://d.example.com
    to: https://example.com
  - from: https://e.example.com
    to: https://example.com

# After
routes:
  - from: https://*.example.com
    to: https://example.com

# Or

routes:
  - from: tcp+https://*.example.com:22
    to: tcp://example.com:22
```

### Wildcard Processing Behavior

Pomerium processes routes in the order they are defined in the configuration file. However, routes which **don't** contain wildcards (`*`) may take precedence over routes which **do** contain wildcards.

For example, given the routes below, if you send a request to `foo.example.com`, Pomerium would redirect the request to `1.example.com`.

If you send a request to `bar.example.com` (a non-wildcard route), Pomerium would redirect the request to `2.example.com`.

```yaml
routes:
  - from: https://*.example.com
    to: http://1.example.com
  - from: https://bar.example.com
    to: http://2.example.com
```