Security Policies - Remote Access - Default Rules
- Last Updated: December 11, 2025
- 9 minute read
- MOVEit Transfer
- Version 2024.1
- Version 2024
- Documentation
You can add default rules (SETTINGS > Security Policies - Remote Access - Default Rules) to determine which networks or hosts can access MOVEit Transfer.

|
Example Hostname/IP |
Rule |
Expanded meaning |
|---|---|---|
|
|
Allow |
Enables only requests/access from a single IP address. |
|
|
Allow |
"ALLOW 192.168.4.0 through 192.268.4.255" —enables requests from a range of 256 IP addresses. |
10.*.*.* |
Allow | Allow only from private addresses beginning with the network part "10" as shown. |
|
|
Deny |
"DENY" any requests from any attached hosts hanging off 10 subnetworks, as shown. |
|
Allow | "ALLOW" requests from 14 hosts, as shown. |
|
|
Allow |
Enables only from the test host or subdomain. |
|
|
Allow |
"ALLOW" requests from all hosts on the .test.example.com subdomain. |
Understanding Default Machine/Network Access Rules
Remote access rules allow you specify the conditions (rules) that control if a connecting host can establish a session with a MOVEit Transfer organization (org).
- IP address(es) (or matching pattern)
- Domain(s) (or matching pattern)
|
These remote access rule controls... |
Are for... |
|---|---|
|
Administrator and FileAdmin |
Users that connect using a FileAdmin or Admin role. |
| User | Users and TempUsers |
| WebPost | Includes anonymous users who submit webposts into the MOVEit Transfer system but never actually sign on. See the Web Post section for more information. |
| AS2 (interface) | Includes access to AS2 file uploads. For more information, see the AS2 and AS3 topic in Advanced Topics. |
| Trusted Host | Trusted host allows the same privileges as localhost. |
SysAdmin User Rules
Access for SysAdmins is configured in the Remote Access section of the System Settings (SETTINGS > System - Remote Access).
Ad Hoc or Guest Users
For configuring unregistered or Guest Users, see SETTINGS > Ad Hoc Transfer - Access - Unregistered Senders Unregistered Sender Remote Access Rules
These settings may also be overridden by custom IP/hostname rules for particular users. (Some organizations will want to leave these default settings blank and ONLY allow specific IP access for each user.)
By default, system administrators may only sign on from the local console.
By default, anonymous WebPost users may submit information to , but may not create new WebPost folders.
In addition to the access rules for hosts, you can specify a list of trusted hosts for an organization. A host in the Trusted Hosts list will bypass the normal IP lockout and session IP consistency checks. In effect, when a user signs on to the organization from a trusted host, it works like signing on from the localhost. For more information, see the Trusted Hosts section of this document.
Each section contains all current rules. At runtime, the rules will be processed in a top-to-bottom order.
Each rule consists of the following:
- Rule: Whether the rule allows or denies access.
- Hostname/IP: The IP address or hostname of each rule (see the topic titled Using the Expected Syntax).
- Comment: Any hint or notes the administrator wants to provide. Anything typed here is informational only and does not affect any other part of the rule.
In addition, an Edit Access Rules button for each section (below the last rule of the section) opens a separate page for each section, that is, one page each for Administrator and FileAdmin Remote Access Rules, User Remote Access Rules, and Webpost Remote Access Rules.
Rule Actions
Clicking Edit Access Rules for any section of rules opens a separate page for that section. There are separate pages for Administrator and FileAdmin Remote Access Rules (shown below), User Remote Access Rules, and Webpost Remote Access Rules.
Actions include:
- Prioritize.

Move the rule up and down in the
priority list - rules at the top of the list are processed first. (These buttons
appear only when there are two or more rules.) - Edit.
Allows administrators
to change details about the rule; opens the Edit Remote Access Rule page. - Delete.
Remote the rule from the
access list.
In addition, the Add Remote Access Rule link (below the last rule) opens the Add Remote Access Rule page, where new rules can be added.
Using the Expected Syntax
To apply a hostname/IP access rule, use the expected syntax.
- A domain, subdomain, or one network, subnet, or host IP address.
- Optional wildcard characters ("*") can be used in each divided part (octet) of an IP address.
- IP address ranges can be specified using a dash character ("-").
- Only one item is expected for each entry-rule pair. (Whitepace or comma-delimited lists are not expected and will not be handled.)
- Use ranges, wildcards, subnets, subdomains to specify a rule that expands to multiple addresses/hosts.
Syntax for IP addresses
<1rst-part>.<2nd-part>.<3rd-part>.<4th-part>
—Where part denotes an octet of the IP address.
Examples
198.51.100.1 (applies rule to one address, as shown)
203.0.113-255 (applies rule to 112 addresses, as shown)
198.51.100.1-29 (applies rule to range of 29 addresses, as
shown)
198.51.100.* (expands rule to include 256 addresses, as shown)
—Where an octet (or part) can represent 256 individual IP addresses.
Syntax for address ranges
<1rst-part>.<2nd-part>.<3rd-part>.<4th-part-range-start>-<range-end>
—And where range can be specified in any octet of an IP address.
Examples
198.51.100.1-29
198.51.100-101.1
Syntax for host and network names
<sub-domain-host-part>.<second-level-domain-part>.<top-level-domain>
Examples
test.example.com (applies rule only to client requests from
test subdomain/host)
*.example.com (applies rule to client requests originating from the
example.com domain —subdomain ignored)
test.example.com,*.example.net (applies rule to one subdomain on
example.com and any subdomain on example.net)
Add Remote Access Rule and Edit Remote Access Rule Pages

The fields here define a Hostname/IP address or range combination and whether it will be allowed or denied. The individual rule can be assigned a priority for applying it in combination with other access rules. For a new rule, fill out the fields to create a new remote access rule and then click the Add Entry button. Similarly, for an existing rule, change fields and then click the Update Entry button.
The fields and buttons on this page are:
- Rule: Values you can select are Allow or Deny.
- Hostname/IP: Value of single hostname or an IP address. You can include a
wildcard character ("*") to apply yourAllow or Deny rule to match
a range. Some examples are:
11.22.33.44(a single host), and11.22.33.*(where * means all machines under the11.22.33network) and*.example.edu(where "*" means all hosts using the example.edu domain). - Priority: (Shown for the Add... page only, not Edit....) To specify initial placement in the list (whether at the top, bottom, or in middle). Values you can select are Highest, Middle, or Lowest.
- Comment (Optional): Text entry field.
- Add Entry / Update Entry: Click this button to close this page and add the new rule to - or update the existing rule on - the rules list.
Hostname/IP Masks
Hostname/IP entries can be individual hostnames, individual numeric IP addresses, or masks that allow matching against a range of hostnames or addresses. An asterisk (*) will match any value in a particular position. For example, 2* matches 23 or 213, *cat matches tomcat and bobcat and * matches all of the above.
A dash (-) will match numeric values which fall on or between the numbers on either side of the dash. For example, 2-4 matches 2, 3 and 4 but not 1 or 5.
Allow/Deny Decisions
When an incoming IP address or hostname is tested, rules are processed top-to-bottom. The first rule which applies to the incoming IP or hostname is the rule which actually allows or denies access.
By default, all IP addresses and hostnames are denied if they fall off the end of the list.
- Specific IP addresses and hostnames (for example, 192.168.3.4 or test.example.com) should be at the top.
- Ranges of IP addresses and hostnames (for example, 192.168.3.* or *.example.com) should be in the middle.
- Catch-all entries (for example, 192.*.*.* or *.edu) should be at the bottom.
Console Connections
When a user signs onto the MOVEit Transfer server from a web browser running on the same machine as the MOVEit Transfer server itself, that user is said to be connected to the console if he or she connects to MOVEit Transfer using a URL which begins with http://localhost... or http://127.0.0.1... rather than the usual http://MOVEitDMZ.example.com... URL.
These console connections are NOT subject to the remote access List. This exception prevents SysAdmins from locking themselves out with an empty Access List because they can always sign on from the same machine on which MOVEit Transfer runs.
Trusted Hosts
This feature lets Org admins designate a host as a trusted host for their organization, allowing the host the same privileges as localhost.
Under normal operations, clients that access MOVEit Transfer from any of the local interfaces will bypass the normal IP lockout and session IP consistency checks. This allows services like the MOVEit Transfer FTP server and the MOVEit Transfer SSH server to function properly and present the client's IP address for display and logging purposes. A trusted host will also bypass these checks.

This feature can be used in the following situations:
- Allow machine requests from a Trusted Host to supply an IP address as the effective IP address for machine transactions. (This is the <IPADDRESS> XML element in the MOVEit Transfer API). This feature is most often used when using MOVEit Transfer API within a separate web application to provide single-sign-on access to MOVEit Transfer. It allows the API session to be transferred to the client browser, and back again, and also allows API to present the client's IP address for display and logging purposes.
- Allow MOVEit to redirect to a Trusted Host after completing a non-wizard upload.
- Allow users to sign on from a Trusted Host regardless of other permissions
and/or IP lockouts set for that host.
If someone is continually trying and failing to sign-on as an existing user, the originating IP address may be locked out. Trusted Hosts can be used to override the lockout behavior. The Trusted Hosts entries associated with the user's organization are consulted. If the client's IP address matches a trusted host, that IP address will not be locked out. If the failed attempts are being made as a user that doesn't exist, and no organization is specified, the Trusted Hosts entries for the default organization will be consulted.
- Allow users to change IP addresses within a session if the old or new IP address is trusted, regardless of the IP switching mask.
To add an entry to the Trusted Hosts list:
- Under Trusted Hosts, click Edit Access Rules.
- Click Add Remote Access Rule.
- Enter a hostname or IP address and a description (optional), then click Add
Entry.
The Hostname/IP field can contain either a hostname or an IP address. Both types can contain wildcard characters, and IP addresses can also be in the form of a range. For example: 11.22.33.44, 11.22.33.*, 11.22.33.44-55, jsmith.mycompany.com, *.mycompany.com.
Note: Hostnames and IP addresses are not interchangeable. If myhost1 resolves to 192.168.1.200, and the list contains myhost1 but not 192.168.1.200, then users can access the host via URLs starting with https://myhost1 but not via URLs starting with https://192.168.1.200.After you add the entry, it displays in the list of allowed hosts.
(You can return to the Trusted Hosts list, and the entry also displays there).
To move a host entry:
Use the Arrow buttons to move the entry up and down in the priority list - entries at the top of the list are processed first. (These buttons appear only when there are two or more entries.)
To edit a host entry:
Locate the entry in the list of allowed hosts and click the Edit button. Enter any changes.
To delete a host entry:
Locate the entry in the list of allowed hosts. Next to the entry, select Delete, then select Yes to confirm the deletion.