Why NAT is used in practice:
NAT technology helps conserve IPv4 address space and reduces the likelihood of devices in the operator's network being hacked. On the SSG, two modes can be configured:
Let’s test this:
Test 1. Configuring CGNAT and NAT 1:1 via CLI
Test 2. Configuring CGNAT and NAT 1:1 via GUI
Test 3. Configuring NAT log export to external collector and locally to file
Let’s start testing. The actions can be performed both via the graphical interface of the SSG and through the CLI. The choice of method is up to the client; both methods are presented in the instructions.
Enter the command in the command line:
CGNAT:
fdpi_ctrl load profile --service 11 --profile.name cg_nat --profile.json '{ "nat_ip_pool" : "10.10.10.0/24", "nat_tcp_max_sessions" : 2000, "nat_udp_max_sessions" : 2000 }'
NAT 1:1:
fdpi_ctrl load profile --service 11 --profile.name bi_nat --profile.json '{ "nat_ip_pool" : "10.10.10.0/24", "nat_type": 1 }'
Command values:
load profile
— creating a profileservice 11
— service number on the SSG, for the NAT service it is 11profile.name
— name of the created profile, cg_nat
and bi_nat
profile.json '{ "nat_ip_pool" : "10.10.10.0/26", "nat_tcp_max_sessions" : 2000, "nat_udp_max_sessions" : 2000 }'
— profile settings in JSON format:nat_ip_pool
— NAT pool subnets separated by commas. If the extreme addresses need to be excluded, you can add ~ (10.10.10.0/24~)
at the end, so the pool will contain addresses from 10.10.10.1
to 10.10.10.254
.nat_tcp_max_sessions
— maximum number of TCP sessions per subscriber.nat_udp_max_sessions
— maximum number of UDP translations per subscriber.nat_type
— NAT operation mode. 0 — for CGNAT, 1 — for NAT 1:1. The default is 0, so this field is not specified for CGNAT.Assigning the NAT service to a subscriber is possible by IP or CIDR.
Example of assigning the service by IP:
fdpi_ctrl load --service 11 --profile.name cg_nat --ip 100.64.0.1
Example of assigning the service to the entire CIDR:
fdpi_ctrl load --service 11 --profile.name cg_nat --cidr 100.64.0.0/24
Example of assigning the service by IP:
fdpi_ctrl load --service 11 --profile.name bi_nat --ip 100.64.0.1
Example of assigning the service to the entire CIDR:
fdpi_ctrl load --service 11 --profile.name bi_nat --cidr 100.64.0.0/24
These commands are enough to configure NAT on the SSG. The SSG by default operates in bridge mode, meaning it creates NAT translations and forwards traffic in both directions but does not participate in routing.
To route reverse traffic to the NAT pool towards the subscribers, it will be necessary to create a route to the NAT pool on the router after the SSG and make this route known to the other routers in the network.
Consider a situation where a point-to-point network 10.0.1.0/30 is configured between the routers with the SSG, the router's interface on the subscriber side (R1) has the IP 10.0.1.2, and the router's interface after the SSG (R2) has the IP 10.0.1.1 (see the diagram).
On router R2, it will be necessary to configure the route to the NAT pool. For Cisco-like CLI, the configuration will look like this:
conf t
ip route 10.10.10.0 255.255.255.192 10.0.1.2
It will also be necessary to configure the redistribution of static routes so that the route is known not only to R2 but also to the rest of the network. If OSPF is used:
router ospf 1 redistribute static subnets metric-type 1
Where 1
in router ospf 1
is the OSPF process number on the router.
From the test PC, check the application of NAT:
ping 10.0.1.2
. If R2 is unavailable, check the orientation of the SSG interfaces.
The In interface connects the subscribers, the Out interface connects to the internet.
Determine which interface is which by setting the port connected to the SSG to down on R1 and outputting the status of interfaces on the SSG.
fdpi_cli dev xstat|grep --no-group-separator -B1 "Link status"|paste - -|sort Device 02:00.0: Link status: link down Device 02:00.1: Link status: link up
Check the configuration in fastdpi.conf
If necessary, change the direction and restart the service with the command
service fastdpi restart
For each IP, it is possible to display the current state of the NAT service.
View the number of active sessions and the assigned public address for a specific private address using fdpi_ctrl
:
fdpi_ctrl list status --service 11 --ip 192.168.4.20
Result:
Private subscriber IP addresses are translated into Public IP addresses.
In the same section “DPI/Services”, CGNAT tab.
In the right column "Subscribers", add a subscriber, select the "Unbound" type, enter the subscriber’s IP, select service 11 “CGNAT” or “NAT 1:1”, check the box "Yes" to enable, select the profile, click "Apply" and "Save".
To route reverse traffic to the NAT pool towards the subscribers, it will be necessary to create a route to the NAT pool on the router after the SSG and make this route known to the other routers in the network. The process is the same as in Test 1. The steps and commands do not change.
In the GUI, navigate to DPI > Statistics > NAT Statistics
Check the orientation of the SSG interfaces as shown in Test 1.
In the GUI, navigate to DPI > Statistics > NAT Statistics
Check the number of active sessions and the assigned public address for each private address.
fdpi_ctrl log set nat --export-collector-ip 10.10.10.2 --export-collector-port 514
To export logs, specify the IP address and port of the external collector.
fdpi_ctrl log set nat --export-local-file /var/log/nat.log
To export logs locally, specify the desired file path.