Can I block specific IPs/CIDRs or allow only them?

Short answer

Yes. In the Source IP condition, Source IP Type = Manual is selected and the IPs and CIDRs are written; to block them, the condition is bound to the Block action on an HTTP vService, or to the TCP Connection Management action on an L7 TCP vService; to allow only these addresses, the negative (NOT) form of the same condition is used. Long lists are kept in a single Dynamic List condition. For a blacklist applied to all vServices, the IP Intelligence & Reputation screen's Blacklist Content is used, and at the network layer, Firewall is used.

Problem: Specific Addresses Must Be Blocked or Only They Must Be Allowed

The addresses that attack may need to be blocked, or an internal application may need to be reachable only from the corporate networks. For a restriction to be applied only to a specific path (e.g. an admin panel): How do I make the admin panel accessible only from specific IPs?; to route the internal network to separate servers: Can I route only users coming from the internal network (specific IPs) to a test server?

Solution: Four Methods

The methods are alternatives to each other; their scopes are different.

Your situation	Suitable method
The rule will be applied to a single vService (HTTP or L7 TCP); a block or allow list	Method 1: Source IP (Manual) condition + action
The addresses should be blocked on all vServices	Method 2: IP Intelligence & Reputation → Blacklist content
At the network layer, for a specific port	Method 3: Firewall (Manual)
From the command line	Method 4: WEB-CLI

Method 1: Source IP (Manual) Condition + Action Recommended

• How it works Requests coming from the addresses in the condition are met with the action before they reach the Backend Service; if the negated form of the condition is selected, everyone who is not in the list is blocked.
• Where it is openedLoad Balancer → Conditions · Load Balancer → Actions · vService → Details → Actions
• Requirement There is no change on the Backend Service side
• vService type HTTP · L7 TCP (there is no Actions field on a Network vService)

Step-by-Step Configuration

1

Adım 1 Open the condition form

On the Load Balancer → Conditions screen, Add is clicked (how to add).

2

Adım 2 Write the addresses

Condition Name is entered; Criteria = Source IP and Source IP Type = Manual are selected. In the Source IP field, IPv4/IPv6 addresses and CIDR blocks are written separated by a space or a line break (e.g. 203.0.113.0/24); lines starting with # are comments.

Long or frequently changing lists

Criteria = Dynamic List is selected; Key to search is left as the default Client IP address, Search method = IP/cidr match is selected, and one address or block is written on each line of the List field. Condition protocol is selected according to the vService type (HTTP or TCP). The remaining steps are the same.

3

Adım 3 Save the condition

Add is clicked; the condition is added to the list.

4

Adım 4 Open the action form

On the Load Balancer → Actions screen, Add is clicked (how to add).

5

Adım 5 Select the action and the condition

Action Name is entered and the Action Type is selected according to the vService type:

vService	Action type	Setting
HTTP	Block	Execution Level = On request, Deny Type = Standard, Status Code default 403
HTTP, if a page is to be shown to the blocked clients	Show Content	Content Page and Status Code; since the Status code default is 200, 403 is selected
L7 TCP	TCP Connection Management	Action = Reject or Silent drop (Is it possible to reject or silently drop a connection at the TCP level (TCP Connection Management)?)

In the Conditions field, the condition itself is selected for blocking, and its negated form (shown as !ConditionName in the list) for an allow list (Can I use a condition in negated form ("if not")?). Optionally, Hit Counter is turned on.

6

Adım 6 Save the action

Add is clicked; the action is added to the list.

7

Adım 7 Open the vService edit form

On the Load Balancer → Load Balancer vService List screen, the vService is selected and Edit is clicked.

8

Adım 8 Add the action to the vService

The action is selected in the Actions field under Details. Actions are processed in the order in the list; the actions after the one that blocks the request do not run (action ordering).

9

Adım 9 Save

Save is clicked; the rule is applied without a separate deployment step. In a cluster setup, the change is also sent to the peer device automatically with the default auto-sync; if Manual Sync Mode is on, it is sent to the peer device manually.

Verification

1BlockingClient side

A request is sent from an address in the list (on L7 TCP, a connection is made with nc -v).

Command: curl -sI https://www.example.com/

ExpectedHTTP/1.1 403 Forbidden

If an allow list has been set up, an address in the list receives the normal response, and an address not in the list receives 403.

2Action HitsTR7 side

If the Hit counter is on, the Action Hits tab on the vService Dashboard is checked.

ExpectedThe action's counter increases

Method 2: IP Intelligence & Reputation → Blacklist content

• How it works Addresses added to the Blacklist Content list enter the merged blacklist of the device with the User Blacklist category. This category is in the default first rule row of IP Reputation Protection: on vServices with L7 DDoS & Threat Protection on, these addresses are quarantined (where it is used).
• Where it is openedSettings → General Settings → IP Intelligence & Reputation
• Requirement A protection that applies the list: L7 DDoS & Threat Protection on the vService (IP Reputation Protection Active by default), L4 DDoS Protection Blacklist at the network layer, or a Blacklist IP Category condition
• vService type HTTP · L7 TCP

Step-by-Step Configuration

1

Adım 1 Open the screen

The Settings → General Settings → IP Intelligence & Reputation screen is opened (how to edit).

2

Adım 2 Edit the list

The Edit icon to the left of the Blacklist Content row is clicked; IP addresses or CIDR blocks (IPv4 /8–/32, IPv6 /29–/128) are written line by line, and lines starting with # are comments.

3

Adım 3 Save

The list is saved. Invalid lines are ignored and reported with a badge that shows the number of lines.

4

Adım 4 Turn on the applying protection (if necessary)

The list does not block on its own. If the protection is off in the vService, the L7 DDoS & Threat Protection box under Details in the vService edit form is checked and Save is clicked. Details: Can I block known malicious IPs (IP Reputation / blacklist category)?

A single address

A single address can also be added with Add to blacklist (IP intelligence) from the result card in the IP Lookup tab of the same screen.

Verification

1Blacklist statusTR7 side

The address is queried with IP lookup.

ExpectedOn the blacklist · source User

2Event recordTR7 side

After a request comes from the address, the IP Reputation tab of the Bot/DDoS Event Logs screen is checked.

ExpectedIP Reputation record for the address

Method 3: Network → Firewall (Manual)

• How it works At the network layer, traffic coming to a specific port is dropped according to the source address. User Firewall rules are evaluated in list order, before the permissions generated automatically for vService listening ports (rule evaluation order).
• Where it is openedNetwork → Firewall → Add
• Requirement Firewall edit permission
• vService type HTTP · L7 TCP (independent of the vService, per route table)

Step-by-Step Configuration

1

Adım 1 Open the rule form

On the Network → Firewall screen, Add is clicked (how to add).

2

Adım 2 Define the rule

Route Table (the route table of the vService), Interface, Protocol = TCP and Destination port = the vService port are selected. Source = Manual is selected and the address or CIDR is entered, and Rule = DENY is selected. For "only these addresses", the switch next to the field is set to is false (the rule appears as Unless … in the list).

3

Adım 3 Save

The rule is saved and applied immediately; the new rule is added to the bottom of the list and, if necessary, is moved up with Order.

Management access

A DENY rule whose scope is kept broad (e.g. Protocol = All) can also drop management traffic; the rule is kept narrow with Destination port, and a second management session is kept open while it is applied (best practices).

Verification

1ConnectionClient side

A connection is made to the vService port from the blocked address.

Command: nc -vz -w 5 203.0.113.10 443

ExpectedThe connection times out

Method 4: WEB-CLI

• How it works The condition, action and binding in Method 1 are done with WEB-CLI commands.
• Where it is opened WEB-CLI → lb condition · lb action · lb service
• Requirement WEB-CLI access
• vService type HTTP (example with the Block action)

Step-by-Step Configuration

1

Adım 1 Create the condition

The addresses are written in quotes, separated by spaces (condition criteria):

lb condition add criteria src_ip srcIpType manual src '203.0.113.0/24 198.51.100.7' --name kara-liste

2

Adım 2 Get the condition ID

The --cond field takes the ID of the condition, not its name. The ID is read from the list:

lb condition list

3

Adım 3 Create the Block action

The ID from step 2 is written in place of <condition-id>; for an allow list, ! is placed in front of the ID (--cond '!<condition-id>'):

lb action add type deny name ip-engeli --cond <condition-id>

4

Adım 4 See the existing actions of the vService

lb service show <vService>

The rules.0, rules.1 … lines in the output are the actions defined on the vService.

5

Adım 5 Add the action to the first empty position

--rules.N replaces the existing action at that position; the new action is written to the first empty position. If the vService has no actions, the position is 0; if it has two actions, --rules.2 is used:

lb service update id <vService> --rules.0 ip-engeli

Verification

1BindingTR7 side

The vService record is displayed again.

Command: lb service show <vService>

Expectedip-engeli in the rules lines

A request made from an address in the list receives 403, as in Method 1.

Common Mistakes

• Not defining Trusted proxy while TR7 is behind a CDN or proxy. The condition evaluates the proxy's address; on an HTTP vService, the real client IP is first resolved with Trusted Proxy. The Firewall rule, on the other hand, always looks at the source address of the connection.
• Selecting the condition itself in an allow list. The condition itself blocks the addresses in the list; for an allow list, its negated form is selected.
• Forgetting that allowed addresses can be blocked by other protections. If IP Reputation Protection is on, an allowed address can still be quarantined because of its reputation; these addresses are also added to the Whitelist Content list. The whitelist always takes priority.
• Taking protection exemption lists for allow lists. L7 DDoS Protection and IP Reputation Protection whitelist entries only grant exemption from that protection; they do not block other addresses.
• Saving the addresses without checking them. The Manual field does not check the format of the entered addresses; if all lines are empty or comments, the condition matches no address.
• Writing the condition name in the --cond field or overwriting the existing action with --rules.0 in WEB-CLI. --cond expects the ID of the condition; for --rules.N, the first empty position is first found with lb service show.

How it is done in the documentation

• Source IP · Manual
• Dynamic List · Search Method
• IP Intelligence & Reputation · Blacklist Content
• Firewall · Manual
• WEB-CLI · Examples

Related questions

• How do I make the admin panel accessible only from specific IPs?
• Can I route only users coming from the internal network (specific IPs) to a test server?
• Can I block known malicious IPs (IP Reputation / blacklist category)?
• How do I exempt specific IPs, networks or countries from L4 DDoS protection (Whitelist & Known Peers)?