Egress PE NAT44
Last updated
Last updated
Load nat44.vpn.lab1.init.cfg
L3VPN is fully setup. The R1-R2 link is in the global table, and is an internet connection. R2 learns 8.8.8.8/32 via R1 over the BGP session.
Using the egress PE NAT technique, allow any networks in RFC1918 space from VPN_A and VPN_B to NAT to the internet, using R2’s Gi2.12 address.
The egress PE NAT feature allows a single egress PE to provide VRF-to-global NATing for multiple VRFs. The egress PE enables NAT inside on the MPLS interfaces, and uses the service label to determine the VRF of the incoming packet. This is used as additional information in the stateful NAT entry.
To begin, we must define all of the VRFs locally on R2.
We then need to originate a default route and advertise it via VPNv4. R2 configures a static route that points to R1 in the default VRF, which is redistributed into the BGP VRF.
Finally we configure the NAT rules. An extended ACL is used to match RFC1918-sourced traffic. NAT inside is set on the MPLS interfaces, which will receive the VPN traffic, and NAT outside is set on the external-facing interface which is in the default VRF. One NAT rule per VRF is required.
We can ping 8.8.8.8 from the loopback of each CE:
R2 is able to keep track of which VRF the packet belongs to based on the incoming service label. This is kept as a flag on the NAT entry. When return traffic arrives on Gi1.12, the NAT entry contains which VRF the traffic must be NATed back to.
For this reason, VRF-to-VRF cannot work on the egress PE. Let’s say that interface Gi2.12 was in an INET VRF. The customer VRFs could import the 0/0 route from the INET VRF. However, all traffic from any customer VRF would arrive at R2 with the INET VRF service lable. R2 can no longer differentiate between VRFs. This is why we are forced to do VRF-to-default NAT when using the egress PE NAT feature.
