Network confinement and upstream proxies for web targets

• Back to the WebView main page

Every web session goes through a filtering proxy that runs for this session only.
It lets through the allowed sites of the target and blocks the bastion itself.
A policy can add two network settings for its web targets: a network namespace, and a route.
The route is a direct exit, one upstream proxy or a PAC file.

What the filtering proxy always refuses

• The loopback, unspecified, link-local, multicast and broadcast addresses.
• Every address of the bastion, even when a public name resolves to it.
• Every host that is not in the allowed sites of the target.

The proxy resolves the name, checks the address, then connects to that address.
A DNS answer that changes between the check and the connection cannot reach a refused address.

Network namespace

A policy can start the browsers of its web sessions inside an Artica network namespace.
The browser then sees only the network card of that namespace and uses its DNS servers.
Use it to reach applications of a DMZ or of a customer network that the bastion itself must not route to.

Create the namespace first with the network namespaces feature of Artica, in the Network menu.
Then choose it in the policy, field Network Confinement Of Web Targets.

If the namespace does not exist when the user connects, the session is refused with the reason web_netns_unavailable.
The browser never falls back to the network of the bastion.

Upstream proxy

A policy can send the web traffic of its sessions to an upstream proxy.
The filtering proxy of the session applies the allowed sites first, then goes through the upstream proxy.
An HTTPS site is reached with HTTP CONNECT.
A plain HTTP site is reached with a request in absolute form (GET http://host/path), because many proxies refuse CONNECT outside the SSL ports.
When an account is set, it authenticates with Basic.

Create the upstream proxy

Open RDP Proxy > Web target proxies and click New upstream proxy.

The Policies column counts the policies that use each proxy.

The password is kept in the vault and never shown again.

Then choose the proxy in the policy, field Route Of Web Targets.
The same list offers None (direct connection), the upstream proxies and the PAC files.
A policy uses one route only.

The policy Plant applications sends its web traffic through Corporate proxy.

If the upstream proxy is disabled, or its password cannot be decrypted, the session is refused with the reason web_proxy_unavailable.
The traffic never leaves directly.

Delete or disable an upstream proxy

• A proxy chosen as the route of a policy cannot be deleted.
  The bastion answers proxy_in_use.
  Choose another route in that policy first.
• A proxy cited by the PAC file of a policy cannot be deleted either.
  The bastion answers proxy_in_pac.
  It looks for host:port of the proxy in the text of each PAC file used by a policy, comments included.
  Remove the proxy from that PAC file first, or detach the PAC file from its policies.
• The Policies column counts only the policies that chose the proxy as their route.
  A proxy used only through a PAC file shows 0.
• A disabled proxy stays in the list.
  A policy that chose it refuses its sessions.
  A PAC file that names it skips it.

Route with a PAC file

When one application needs several exits, choose a PAC file instead of a proxy.
The PAC file picks a direct exit or one of the declared proxies for each address.
See PAC files for web targets.

Requirements

The namespace and the upstream proxy need the RDS Proxy engine 12.3.22 and the authenticator 1.7.0.
A PAC file needs the RDS Proxy engine 12.3.25, artica-webview 0.3.3 and the authenticator 1.9.5.
The WebView tab lists the policies that use a namespace or an upstream proxy.

REST API

The PAC routes are listed in PAC files for web targets.