VPNs, internal addresses and access
You may want to limit the ability to access a Knoc, depending on where your user is logging in to Knocknoc from.
For example, an internal subnet should only be opened up if the user is connecting from an internal IP address range, or if they are connected to a VPN and have an internal IP address.
How allowsto set this throughup
A trust policy decides this. Under Admin > Trust Engine > Policies, add a Knoc option,policy with IPa Known networks restriction and list your office ranges and your VPN pool in CIDR form. Set its response to Block to refuse anyone outside them, or Challenge to let them in once they confirm who they are.
Then attach the policy to the Knoc. On the Knoc's Knoc Options tab, Trust Engine policy is a row of buttons, one for each policy you have. Choosing one shows what it does underneath.
One policy can govern as many Knocs as you like, so the ranges are written once and every Knoc that should be office-only points at the same policy.
The address ranges configured as either an allow-list, deny-list or RFC1918 set.
By default "Anywhere"that is selected,checked
however
A selectingpolicy RFC1918checks willthe enableaddress the person is connecting from, not the addresses the Knoc onlyopens. ifA Knoc that opens 10.32.3.1 does not let in somebody at 11.1.1.1 just because the logging-intarget useris hasa private address. Being able to reach an IPaddress withininside thoseyour ranges.
Alternatively, IP addresses can be entered in either an Allow or Deny list form.
Only when
What the user is connecting from these addresses will the Knoc be enabled and perform the grant process.sees
WhenA ablocked Knoc is disabled, it will still be shown to the connecting user with a note to contact their administrator.administrator, and the attempt is recorded under Blocked Grants. A Knoc set to Challenge shows Verification needed with a Verify button instead.
