ACL-Based Forwarding Example

This example demonstrates how an ACL-Based Forwarding (ABF) policy can choose to route all traffic from a source client (or clients) out a secondary Internet connection.

Required Information

Required information for this ABF Example

Item

Value

WAN1 Address

203.0.113.31/24

WAN1 Next Hop

203.0.113.1

WAN2 Address

198.51.100.231/24

WAN2 Next Hop

198.51.100.1

Client Address

10.34.0.101

This example assumes the following:

  • Interfaces already setup (WAN1, WAN2, LAN)

  • NAT configured including pools for both the WAN1 and WAN2 interface

  • Default route already in table pointed to the WAN1 next hop

  • Other setup already in place allowing the client to access Internet hosts normally through WAN1 (e.g. DHCP, DNS, etc.)

Check Client Egress

Before starting the ABF configuration, check which interface the client egresses through. Given the starting assumptions, it should egress through WAN1, and an IP address check site access from the client device should return the WAN1 address:

$ curl http://ipcheck.example.com/
Current IP Address: 203.0.113.31

This example used curl on the client, but web browsers will work similarly.

There are numerous IP address check sites around the Internet which can be used for this purpose. In many cases even using a search engine to query “what is my IP address” will show the client address.

Create an ACL

From config mode in the TNSR CLI, create ACL matching the desired traffic. In this example, match the source address of the client which will be redirected out WAN2 by this policy.

tnsr(config)# acl wan2clients
tnsr(config-acl)# rule 10
tnsr(config-acl-rule)# action permit
tnsr(config-acl-rule)# ip-version ipv4
tnsr(config-acl-rule)# source address 10.34.0.101/32
tnsr(config-acl-rule)# exit
tnsr(config-acl)# exit

Note

Using an ACL in this way does not make any decisions on passing or blocking packets, only matching or not matching the ABF policy.

Additional rules on the same ACL can match more clients or different types of packets to direct out WAN2 as needed.

Create an ABF Policy

The next step on the TNSR CLI is to create an ABF policy using that ACL. This policy will be configured to forward traffic out WAN2 to the WAN2 next hop:

tnsr(config)# route acl-based-forwarding policy 1
tnsr(config-abf-policy)# acl wan2clients
tnsr(config-abf-policy)# ipv4-next-hop 1
tnsr(config-abf-policy-ipv4-nh)# ipv4-address 198.51.100.1
tnsr(config-abf-policy-ipv4-nh)# interface WAN2
tnsr(config-abf-policy-ipv4-nh)# exit
tnsr(config-abf-policy)# exit

Attach the ABF Policy

The last configuration step in the TNSR CLI is to attach the ABF policy to the interface where the source client is located, which in this example is LAN:

tnsr(config)# route acl-based-forwarding interface LAN
tnsr(config-abf-interface)# policy 1 ipv4 priority 10
tnsr(config-abf-interface)# exit
tnsr(config)# exit

Check Client Egress Again

With the ABF configuration completely in place, check which interface the client egresses through again. If the ABF configuration was correct, it should egress through WAN2, and an IP address check site accessed from the client should return the WAN2 address:

$ curl http://ipcheck.example.com/
Current IP Address: 198.51.100.231

Tip

If using a web browser on the client, close the browser and reopen it again before this test attempt. This ensures the browser is using a fresh session and won’t attempt to reuse the previous connection.