Tutorial: Configure Deny Rules with Domain Routing Using the Access Server CLI⁠

Overview⁠

By default, Access Server supports allowlist rules for domain routing. This tutorial explains how to configure and validate deny rules using the CLI.

You can apply domain routing rules at different levels:

Globally (applies to all users).
Per Group.
Per individual user.

You can use one or more levels at the same time, depending on your access requirements.

Domain routing supports:

Exact domains (for example, example.com) — matches only that domain.
Wildcard domains (for example, *.example.com) — matches the domain and all subdomains.
Wildcard TLDs (for example, *.com) — matches all domains with that top-level domain (TLD).

Deny rules let you block traffic to specific domains, subdomains, or TLDs.

Prerequisites⁠

Access Server 3.2.0 or newer.
Root privileges on your Access Server's console.
DNS server proxy enabled globally.
One or more users or groups configured.

Scenario 1: Deny access to a specific domain⁠

In this scenario, you block access to app1.example.com for users connected to the VPN.

Connect to the console and get root privileges.

Create a global ruleset:

sacli --name "__DEFAULT___default_ruleset" --comment "Default ruleset for global domain rules" AccessControlRulesetsAdd

Example output:
```
1
```

Note this as the returned ruleset ID.

Create a deny rule for app1.example.com:

sacli --ruleset_id "1" --rule_type "domain_routing" --match_type "domain" --match_data "app1.example.com" --action "deny" --position "1" --comment "" AccessControlRulesAdd

Parameter	Value
`ruleset_id`	Use the value from the global ruleset output.
`match_type` with `domain`	Match an exact domain. For example, `app1.example.com`.
`match_type` with `domain_or_subdomain`	Match wildcard domains. For example, `example.com`. Tip Wildcard domain syntax differs between interfaces: CLI: `example.com` Admin Web UI: `*.example.com`
`match_data`	Domain to route.
`action` with `deny`	This will block the traffic to the domain.
`position`	Use the value for the next available position noted above.

Attach the ruleset globally:
```
sacli --user "__DEFAULT__" --position "0" --ruleset_id "1" AccessControlUserRulesetsAdd
```
Tip
Global rules use __DEFAULT__. Replace this value when applying rules to specific users or groups.
Apply the changes:
```
sacli start
```

List rulesets:

sacli AccessControlRulesetsList

Example output:

[
  {
    "comment": "Default ruleset for global domain rules",
    "id": 1,
    "name": "__DEFAULT___default_ruleset",
    "owner": "__DEFAULT__",
    "owner_type": "user_default",
    "position": 0
  }
]

Note the ruleset ID.

List rules in the ruleset:

sacli --ruleset_id '1' AccessControlRulesList

Replace the ruleset_id value with the value from the ruleset list output.

Example output:

[
  {
    "action": "deny",
    "comment": "",
    "id": 1,
    "match_data": "app1.example.com",
    "match_type": "domain",
    "position": 0,
    "ruleset_id": 1,
    "type": "domain_routing"
  }
]

Confirm the rule includes your deny list values. Example:
- action: deny
- match_data: app1.example.com

In this step, connect to the VPN as a user and generate traffic to app1.example.com to verify it's denied.

Connect a VPN client.

From the Access Server console, enable DNS proxy debug logging:

echo "DEBUG_DNSPROXY=true" >> /usr/local/openvpn_as/etc/as.conf && systemctl restart openvpnas

From the client, run:

ping app1.example.com

Example output:

Ping request could not find host app1.example.com. Please check the name and try again.

On the server, run:

grep "DNSPROXY" /var/log/openvpnas.log

Example output:

2026-04-16T21:05:11+0000 [stdout#info] [DNSPROXY] OUT: '[335] Received query from 172.27.232.2:53380'
2026-04-16T21:05:11+0000 [stdout#info] [DNSPROXY] OUT: '[335] Deny query for app1.example.com. IN A: domain is blocked'

Scenario 2: Deny a specific domain and allow a wildcard⁠

In this scenario:

Deny: app1.example.com
Allow: *.example.com

Connect to the console and get root privileges.

Create a global ruleset:

sacli --name "__DEFAULT___default_ruleset" --comment "Default ruleset for global domain rules" AccessControlRulesetsAdd

Example output:
```
1
```

Note this as the returned ruleset ID.

Add rules to deny the specific domain and allow a wildcard domain:

sacli --ruleset_id "1" --rule_type "domain_routing" --match_type "domain" --match_data "app1.example.com" --action "deny" --position "1" --comment "" AccessControlRulesAdd
sacli --ruleset_id "1" --rule_type "domain_routing" --match_type "domain_or_subdomain" --match_data "example.com" --action "nat" --position "2" --comment "" AccessControlRulesAdd

Parameter	Value
`ruleset_id`	Use the value from the global ruleset output.
`match_type` with `domain`	Match an exact domain. For example, `app1.example.com`.
`match_type` with `domain_or_subdomain`	Match wildcard domains. For example, `example.com`. Tip Wildcard domain syntax differs between interfaces: CLI: `example.com` Admin Web UI: `*.example.com`
`match_data`	Domain to route.
`action` with `deny`	This will block the traffic to the domain.
`position`	Use the value for the next available position noted above.

Attach the ruleset:
```
sacli --user "__DEFAULT__" --position "0" --ruleset_id "1" AccessControlUserRulesetsAdd
```
Tip
Global rules use __DEFAULT__. Replace this value when applying rules to specific users or groups.
Apply changes:
```
sacli start
```

List rulesets:

sacli AccessControlRulesetsList

Example output:

[
  {
    "comment": "Default ruleset for global domain rules",
    "id": 1,
    "name": "__DEFAULT___default_ruleset",
    "owner": "__DEFAULT__",
    "owner_type": "user_default",
    "position": 0
  }
]

Note the ruleset ID.

List rules in the ruleset:

sacli --ruleset_id '1' AccessControlRulesList

Replace the ruleset_id value with the value from the ruleset list output.

Example output:

[
  {
    "action": "deny",
    "comment": "",
    "id": 1,
    "match_data": "app1.example.com",
    "match_type": "domain",
    "position": 1,
    "ruleset_id": 1,
    "type": "domain_routing"
  },
  {
    "action": "nat",
    "comment": "",
    "id": 2,
    "match_data": "example.com",
    "match_type": "domain_or_subdomain",
    "position": 2,
    "ruleset_id": 1,
    "type": "domain_routing"
  }
]

Confirm your rules are correct. From our example:
- The deny rule is first.
- The allow rule follows.

In this step, connect to the VPN as a user and generate traffic to app1.example.com to verify it's denied, while traffic to the rest of *.example.com is allowed.

Connect a VPN client.

From the Access Server console, enable DNS proxy debug logging:

echo "DEBUG_DNSPROXY=true" >> /usr/local/openvpn_as/etc/as.conf && systemctl restart openvpnas

From the client, run:

ping app1.example.com

Example output:

Ping request could not find host app1.example.com. Please check the name and try again.

Test the allowed domain:

ping app2.example.com

Example output:

Reply from 100.64.0.1: bytes=32 time=116ms TTL=49
Reply from 100.64.0.1: bytes=32 time=116ms TTL=49
Reply from 100.64.0.1: bytes=32 time=114ms TTL=49
Reply from 100.64.0.1: bytes=32 time=115ms TTL=49

On the server, run:

grep "DNSPROXY" /var/log/openvpnas.log

Example output:

2026-04-16T21:16:41+0000 [stdout#info] [DNSPROXY] OUT: '[867] Received query from 172.27.236.2:60873'
2026-04-16T21:16:41+0000 [stdout#info] [DNSPROXY] OUT: '[867] Forwarding query for app2.example.com. IN A'
2026-04-16T21:16:41+0000 [stdout#info] [DNSPROXY] OUT: '[867] Received response'
2026-04-16T21:16:41+0000 [stdout#info] [DNSPROXY] OUT: '[867] Changed address for app2.example.com: 192.0.2.1 -&gt; 100.64.0.1'

Tutorial: Configure Deny Rules with Domain Routing Using the Access Server CLI⁠

Overview⁠

Prerequisites⁠

Scenario 1: Deny access to a specific domain⁠

Scenario 2: Deny a specific domain and allow a wildcard⁠

Was this information helpful?