NAT-VPP Case

introduction introduction this guide provides a step by step tutorial for configuring the network address translation (nat) capabilities of the asterfusion et2500 open intelligent gateway running asternos vpp what this guide will accomplish what this guide will accomplish by following this guide, you will start with an unconfigured asternos vm and progressively build a complete, policy based nat gateway the scenarios covered are policy based snat configuring the gateway to intelligently apply nat to one internal network (vlan 10) while allowing another (vlan 20) to be routed without nat dnat (destination nat) publishing a service from the private internal network (vlan 10) to the outside world, making it accessible via the gateway's public ip address multi pool snat modifying the initial configuration to apply nat to both internal networks (vlan 10 and vlan 20), intelligently mapping each vlan to its own dedicated public ip address from a nat pool preparation and environmental overview preparation and environmental overview topology map topology map network planning and preparation (phase 1) network planning and preparation (phase 1) before you begin, please prepare your lab environment the only prerequisite tasks are to physically connect the devices as shown in the topology and pre configure the static ip addresses on the two end user pcs (the internal server pc and the external client pc) the asternos vm should start in a clean, unconfigured state this guide will walk you through the steps to configure your asternos vm to match the target configuration plan outlined in the table below lab components (phase 1) lab components (phase 1) device type / operating system role in topology key function in this guide et2500 / asternos nat gateway device under test (dut) for nat configuration physical pc / windows internal server (vlan 10) server in the nat zone (vlan 10) physical pc / windows internal client (vlan 20) client in the non nat zone (vlan 20) physical pc / windows external client external user for testing dnat target configuration plan (phase 1) target configuration plan (phase 1) device / logical interface ip address / subnet default gateway notes / connection point asternos vm (wan) 192 168 200 166/24 192 168 200 1 connects via ethernet1 to external switch asternos vm (vlan 10 gw) 10 10 10 1/24 logical gateway for vlan 10 (interface vlan 10) asternos vm (vlan 20 gw) 10 10 20 1/24 logical gateway for vlan 20 (interface vlan 20) internal server pc 10 10 10 99/24 10 10 10 1 in vlan 10, connects to asternos ethernet2 internal client pc 10 10 20 100/24 10 10 20 1 in vlan 20, connects to asternos ethernet3 external client pc 192 168 200 177/24 192 168 200 1 connects to external switch upstream gateway 192 168 200 1 (to internet) provides internet access for the wan segment required tools required tools to verify the dnat configuration in part four, we will use the netcat (ncat exe) utility please prepare this tool in advance and place it in an easily accessible location (e g , the desktop) on both pcs building the basic network building the basic network this section covers the initial setup of the wan interface, internal vlans, and all necessary ip addresses to build our network foundation this prepares the gateway for the advanced policy based nat configuration in the next part configuration steps configuration steps step 1 login and enter configuration mode first, log in to the asternos vpp virtual machine the default credentials are admin / asteros after logging in, you will be at the linux shell prompt ( admin\@sonic $ ) enter the asternos command line interface (cli) admin\@sonic $ sonic cli enter the global configuration mode sonic# configure terminal step 2 configure wan interface and default route configure the external facing ethernet1 interface and set the default route for all outbound internet traffic configure the wan interface sonic(config)# interface ethernet 1 sonic(config if 1)# ip address 192 168 200 166/24 sonic(config if 1)# no shutdown sonic(config if 1)# exit configure the default route #remember to replace 192 168 200 1 with your actual upstream gateway's ip address #remember to replace 192 168 200 1 with your actual upstream gateway's ip address sonic(config)# ip route 0 0 0 0/0 192 168 200 1 step 3 configure internal vlans and interfaces now, we will create two separate internal networks (vlan 10 and vlan 20) and assign a physical port to each create the vlans sonic(config)# vlan 10 sonic(config vlan 10)# exit sonic(config)# vlan 20 sonic(config vlan 20)# exit configure ethernet2 as an access port for vlan 10 sonic(config)# interface ethernet 2 sonic(config if 2)# no router interface sonic(config if 2)# switchport access vlan 10 sonic(config if 2)# no shutdown sonic(config if 2)# exit configure ethernet3 as an access port for vlan 20 sonic(config)# interface ethernet 3 sonic(config if 3)# no router interface sonic(config if 3)# switchport access vlan 20 sonic(config if 3)# no shutdown sonic(config if 3)# exit configure the layer 3 gateway interfaces (svis) for each vlan # configure the gateway for vlan 10 # configure the gateway for vlan 10 sonic(config)# interface vlan 10 sonic(config vlanif 10)# ip address 10 10 10 1/24 sonic(config vlanif 10)# exit # configure the gateway for vlan 20 # configure the gateway for vlan 20 sonic(config)# interface vlan 20 sonic(config vlanif 20)# ip address 10 10 20 1/24 sonic(config vlanif 20)# exit verification check basic connectivity verification check basic connectivity before proceeding, verify that both internal pcs can communicate with their respective gateways command from your internal server pc (10 10 10 99) , ping its gateway ping 10 10 10 1 command from your internal client pc (10 10 20 100) , ping its gateway ping 10 10 20 100 conclusion if both pings are successful, your basic network structure is correctly configured, and you are ready to proceed to the next part differentiated outbound access policy based nat differentiated outbound access policy based nat this section is the core of our advanced configuration we will create an intelligent access control list (acl) to apply different nat policies to vlan 10 and vlan 20, perfectly replicating the logic from the isr topology diagram configuration steps configuration steps step 1 define the nat boundary and enable nat globally first, we must activate the nat engine and define the external facing interface as the boundary where nat policies are enforced define the wan interface as the nat boundary sonic(config)# interface ethernet 1 sonic(config if 1)# nat zone 1 sonic(config if 1)# exit enable the nat service globally sonic(config)# nat enable step 2 create the "smart" acl for policy control this acl will act as our "traffic director " it contains rules to explicitly exempt vlan 20 traffic from nat while permitting vlan 10 traffic for nat processing rule priority is determined by the rule id number; higher numbers are processed first create the acl table sonic(config)# access list l3 smart nat acl ingress create rule to exempt vlan 20 (high priority) this rule matches traffic from the vlan 20 subnet and applies the no nat action, instructing the nat engine to bypass it sonic(config l3 acl smart nat acl)# rule 20 packet action no nat src ip 10 10 20 0/24 create rule to permit vlan 10 (low priority) this rule matches traffic from the vlan 10 subnet and applies the permit action, allowing it to be processed by the nat engine sonic(config l3 acl smart nat acl)# rule 10 packet action permit src ip 10 10 10 0/24 #exit #exit sonic(config l3 acl smart nat acl)# exit step 3 deploy the acl and the global snat engine with the policy defined, we now deploy it to the vlan interfaces and create the nat "execution engine" that will handle the permitted traffic deploy the "smart" acl to both vlan interfaces by binding the acl to the vlan interfaces, we ensure all traffic entering the routing engine is first classified by our policy # bind acl to vlan 10 # bind acl to vlan 10 sonic(config)# interface vlan 10 sonic(config vlanif 10)# acl smart nat acl sonic(config vlanif 10)# exit # bind the same acl to vlan 20 # bind the same acl to vlan 20 sonic(config)# interface vlan 20 sonic(config vlanif 20)# acl smart nat acl sonic(config vlanif 20)# exit create the global snat engine this simple nat binding will process any traffic that is permitted by the acl # create the nat address pool # create the nat address pool sonic(config)# nat pool wan pool 192 168 200 166 # create a global nat binding without an acl # create a global nat binding without an acl sonic(config)# nat binding global snat wan pool verification check nat translations verification check nat translations verify the nat path (vlan 10) from your internal server pc (10 10 10 99) , ping its gateway ping t 8 8 8 8 on the asternos vm,check the nat table sonic# show nat translations verify the non nat path (vlan 20) to definitively prove that vlan 20 traffic is being routed without nat, we must capture the packets as they exit the wan interface using port mirroring (span) configure span on the asternos vm this will copy all traffic exiting the wan port (ethernet1) to an unused port (e g ,ethernet4) sonic(config)# mirror session 1 span direction tx src ethernet 1 dst ethernet 4 connect a separate pc with wireshark to the physical port corresponding to ethernet4 and start capturing traffic while capturing, on the internal client pc (10 10 20 100) , start a standard ping ping t 8 8 8 8 expected result in the wireshark capture, you will see icmp packets with the original, untranslated source ip address this is the definitive proof that the no nat rule is working as intended publishing an internal service dnat configuration and verification publishing an internal service dnat configuration and verification now that outbound traffic is working, the final part is to configure dnat (destination network address translation) this will allow external users to access a service running on your private internal network this is commonly known as "port forwarding " configuration steps configuration steps step 1 add the dnat port forwarding rule and save configuration this step tells the gateway to forward incoming traffic on a specific public port to our internal server after adding this final rule, we will save the entire configuration to ensure it persists after a reboot on your asternos vm , enter the global configuration mode (sonic(config)#) add the static dnat rule this rule maps port 8080 on the public ip to port 80 on the internal server sonic(config)# nat static tcp 192 168 200 166 8080 10 10 10 99 80 dnat save the complete configuration sonic(config)# exit sonic# write step 2 prepare the internal test service to verify the dnat rule, we need a simple service running on our internal server that can accept the forwarded connections we will use the versatile netcat tool for this on your internal server pc (10 10 10 99), open a command prompt (cmd) navigate to the directory where you have placed ncat exe start netcat in listening mode on port 80 it will now act as a simple server c \users\youruser> ncat l p 80 note the command prompt will show only a blinking cursor, indicating it is waiting for a connection keep this window open if a windows firewall prompt appears, be sure to "allow access " verification verification with the dnat rule configured and the internal service running, we will perform a final end to end test verification operation on your external client pc (192 168 200 177), open a new command prompt (cmd) navigate to the directory where you have placed ncat exe use netcat to connect to the public ip and forwarded port of the asternos gateway c \users\youruser> ncat 192 168 200 166 8080 delving into the data plane capturing the evidence note because dnat is configured as a static rule, its active sessions are handled directly by the high performance vpp data plane for maximum speed therefore, they are not visible in the standard show nat translations command we must use the vppctl utility to see the evidence directly from the data plane on your asternos vm , while the netcat connection is active, go to the linux shell execute the following command to find the session related to your external client pc sudo docker exec syncd vppctl show nat44 sessions | grep 192 168 200 177 expected result and interpretation the output will show a complete tcp session entry, proving that both dnat and the return path snat are working in the data plane the o2i (outside to inside) flow line is the dnat proof it shows a packet from the external client (192 168 200 177) destined for the public port (192 168 200 166 8080) being rewritten with the new destination of the internal server (10 10 10 99 80) the i2o (inside to outside) flow line is the return snat proof it shows the reply from the internal server (10 10 10 99 80) has its source rewritten to appear as if it came from the gateway's public port (192 168 200 166 8080) conclusion the successful two way communication, combined with this specific data plane evidence, provides definitive proof that your nat gateway is fully and correctly configured for both snat and dnat operations (advanced) upgrading to multi pool policy nat (advanced) upgrading to multi pool policy nat this section guides you through modifying the completed phase 1 configuration to achieve a more advanced nat scenario our new goal instead of exempting vlan 20 from nat, we will now apply nat to both internal networks, but intelligently map each vlan to its own dedicated public ip address this guide assumes you have completed phase 1 and are starting from that final configuration state we will now modify it topology map topology map network planning and preparation (phase 2) network planning and preparation (phase 2) with our new goal, the logical configuration of our network components will be updated the key changes are the nat gateway will now be assigned two public ip addresses on its wan interface the internal client (vlan 20) is no longer in a "non nat" zone; its traffic will now be processed by nat and mapped to a second, dedicated nat pool lab components (phase 2) device type / operating system role in topology key function in this guide et2500 / asternos 07 nat gateway device under test (dut) for multi pool nat physical pc / windows internal server (vlan 10) server in nat zone (mapped to pool 1) physical pc / windows internal client (vlan 20) client in nat zone (mapped to pool 2) physical pc / windows external client external user for testing nat target configuration plan (phase 2) device / logical interface ip address / subnet default gateway notes / connection point asternos vm (wan) 192 168 200 166/24 192 168 200 167/24 192 168 200 1 connects via ethernet1 to external switch asternos vm (vlan 10 gw) 10 10 10 1/24 logical gateway for vlan 10 asternos vm (vlan 20 gw) 10 10 20 1/24 logical gateway for vlan 20 internal server pc 10 10 10 99/24 10 10 10 1 in vlan 10, connects to asternos ethernet2 internal client pc 10 10 20 100/24 10 10 20 1 in vlan 20, connects to asternos ethernet3 external client pc 192 168 200 177/24 192 168 200 1 connects to external switch upstream gateway 192 168 200 1 (to internet) provides internet access for the wan segment configuration steps configuration steps step 1 modify wan interface (add secondary ip) to apply nat using a second public ip, the gateway must first "own" that ip we will add 192 168 200 167 as a secondary address on our existing wan interface sonic# configure terminal sonic(config)# interface ethernet 1 sonic(config if 1)# ip address 192 168 200 167/24 secondary sonic(config if 1)# exit step 2 remove old nat policy before building the new logic, we must completely remove the old "snat & no nat" policy unbind acl from vlan interfaces #this removes the "traffic director" from the vlan interfaces #this removes the "traffic director" from the vlan interfaces sonic(config)# interface vlan 10 sonic(config vlanif 10)# no acl smart nat acl sonic(config vlanif 10)# exit sonic(config)# interface vlan 20 sonic(config vlanif 20)# no acl smart nat acl sonic(config vlanif 20)# exit delete the global snat binding and pool sonic(config)# no nat binding global snat sonic(config)# no nat pool wan pool delete the old "smart" acl sonic(config)# access list l3 smart nat acl sonic(config l3 acl smart nat acl)# no rule 20 sonic(config l3 acl smart nat acl)# no rule 10 sonic(config l3 acl smart nat acl)# exit sonic(config)# no access list smart nat acl step 3 configure new multi pool nat policy now we build the new, more advanced logic from scratch create two new nat pools sonic(config)# nat pool pool pc1 192 168 200 166 sonic(config)# nat pool pool pc2 192 168 200 167 create two new acls (to classify traffic) sonic(config)# access list l3 acl pc1 ingress sonic(config l3 acl acl pc1)# rule 10 packet action permit src ip 10 10 10 0/24 sonic(config l3 acl acl pc1)# exit sonic(config)# access list l3 acl pc2 ingress sonic(config l3 acl acl pc2)# rule 10 packet action permit src ip 10 10 20 0/24 sonic(config l3 acl acl pc2)# exit create new nat bindings sonic(config)# nat binding bind pc1 pool pc1 acl pc1 sonic(config)# nat binding bind pc2 pool pc2 acl pc2 apply new acls to vlan interfaces sonic(config)# interface vlan 10 sonic(config vlanif 10)# acl acl pc1 sonic(config vlanif 10)# exit sonic(config)# interface vlan 20 sonic(config vlanif 20)# acl acl pc2 sonic(config vlanif 20)# exit save the new configuration sonic(config)# exit sonic# write step 4 verification now we verify that both vlans are being correctly nat'd to their different public ips the pc setups (10 10 10 99 and 10 10 20 100) remain unchanged from phase 1 test 1 (vlan 10) from your internal server pc (10 10 10 99) , start a ping to the external client pc (192 168 200 177) on your asternos vm , check the nat table show nat translations expected result you will see entries showing 10 10 10 99 being translated to 192 168 200 166 test 2 (vlan 20) from your internal client pc (10 10 20 100) , start a ping to the external client pc (192 168 200 177) on your asternos vm , check the nat table again show nat translations expected result you will see new entries showing 10 10 20 100 being translated to 192 168 200 167 conclusion conclusion this guide has demonstrated that asternos vpp is a powerful, high performance, and flexible nat gateway solution the completed experiments verify that asternos vpp provides the essential capabilities required for complex enterprise and service provider edge scenarios