Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 Server Administration Documentation | 2025.1

# Broker and protections

To apply the IP address of a broker user’s workstation against the protections table, prepend the string `proxy-` to the workstation’s IP address.

Before you prepend the string `proxy-` to the workstation’s IP address, make sure that a broker or proxy is in place.

Consider an organization with a remote development site with workstations on a subnet of `192.168.10.0/24`. The organization also has a central office where local development takes place. The central office exists on the `10.0.0.0/8` subnet. A P4 service resides in the `10.0.0.0/8` subnet, and a broker resides in the `192.168.10.0/24` subnet. Users at the remote site belong to the group `remotedev`, and occasionally visit the central office. Each subnet also has a corresponding set of IPv6 addresses.

To ensure that members of the `remotedev` group use the broker while working at the remote site, but do not use the broker when visiting the local site, add the following lines to your protections table:

    list    group    remotedev     192.168.10.0/24              -//...
    list    group    remotedev     [2001:db8:16:81::]/48        -//...

    write   group    remotedev     proxy-192.168.10.0/24         //...
    write   group    remotedev     proxy-[2001:db8:16:81::]/48   //...

    list    group    remotedev     proxy-10.0.0.0/8             -//...
    list    group    remotedev     proxy-[2001:db8:1008::]/32   -//...

    write   group    remotedev     10.0.0.0/8                    //...
    write   group    remotedev     [2001:db8:1008::]/32          //...

The first line denies `list` access to users in the `remotedev` group if they attempt to access P4 Server without using the broker from their workstations in the `192.168.10.0/24` subnet. The second line denies access from the IPV6 `[2001:db8:16:81::]/48` subnet.

The third line grants `write` access to users in the `remotedev` group if they are using the broker and are working from the `192.168.10.0/24` subnet. Users of workstations at the remote site must use the broker. The broker itself does not have to be in this subnet, for example, it could be at `192.168.20.0`.

The fourth line grants access from the IPV6 `[2001:db8:16:81::]/48` subnet.

Similarly, the fifth and sixth lines deny `list` access to `remotedev` users when they attempt to use the broker from workstations on the central office’s subnets (`10.0.0.0/8` and `[2001:db8:1008::]/32`).

The seventh and eighth lines grant write access to `remotedev` users who access the server directly from workstations on the central office’s subnets. When visiting the local site, users from the `remotedev` group must access the server directly.

## dm.proxy.protects configurable

When the Perforce service evaluates protections table entries, the `dm.proxy.protects` configurable is also evaluated. This configurable defaults to `1`, which causes the `proxy-` prefix to be prepended to all client host addresses that connect through an intermediary (proxy, broker, broker, or edge server), indicating that the connection is not direct.

Setting `dm.proxy.protects` to `0` removes the `proxy-` prefix and allows you to write a single set of protection entries that apply both to directly-connected clients and those that connect through an intermediary. This is more convenient but less secure if it matters that a connection is made using an intermediary. If you use this setting, all intermediaries must be at release 2012.1 or higher.

Your search for returned results