 | Akshay Adhikari |
There are a few use cases where traffic has to be sent to a particular destination using PBF rules has to be NATed.
For example:
SMTP traffic should be sent to a security device (zscaler) in the LAN VR. Traffic for app1 should have Dedicated Internet Access (DIA) via the WAN interface in transport VR T1. All other traffic should have DIA via the WAN interface in transport VR T2.
As currently designed, NAT takes place before PBF for a given session. When the first packet for a new session arrives, the NAT module gets to view the packet before the session is created. It looks up the NAT rules, and if a rule matches, then it takes the corresponding action (for example, setting up a NAT binding for the session). PBF module gets to see the first packet later after the session has been created. At this time, it may be too late for PBF to select the next hop, since NAT may already have happened.
At a high level, NAT and PBF cannot be applied together for the same session. To achieve the above use cases, two sessions must be created. S1 in the LAN VR and S2 in the appropriate transport VR. Ensure that NAT rules apply only for transport VR sessions and not LAN VR sessions. Ensure that PBF rules apply only for LAN VR sessions and not transport VR sessions.
Consider the following configuration:
Interfaces. There are two paired TVI interfaces:
- PT-LAN1 (169.254.0.3) <-> PT-T1 (169.254.0.2) is a paired TVI interface to go from LAN VR to T1.
- PT-LAN2 (169.254.0.5) <-> PT-T2 (169.254.0.4) is a paired TVI interface to go from LAN VR to T2.
Zones:
- PT1-T1 in DIA-zone1
- PT-T2 in DIA-zone2
- LAN interface in LAN-zone
IP address of zscaler in LAN-VR:
- ZS1
PBF rules:
- R2: Match app1, source zone LAN-zone
- Set nexthop-address PT-T1 (169.254.0.2). NOTE: Configure only the nexthop-address. Do not additionally configure the routing-instance as T1. The route lookup for the nexthop address will be performed in the LAN VR itself.
- R2: Match app2, source zone LAN-zone
- Set nexthop PT-T2 (169.254.0.4). NOTE: Configure only the nexthop-address. Do not additionally configure the routing-instance as T2. The route lookup for the nexthop address will be performed in the LAN VR itself.
NAT rules:
- R1: Match service SMPT, source zone LAN-zone
- NAT via ZS1
- R2: Match source zone DIA-zone1
- NAT via T1
- R3: Match source zone DIA-zone2
- NAT via T2
Consider an SMTP session. When the first packet arrives, the NAT rule R1 matches and creates the NAT binding. Because interface NAT is in use, the NAT module automatically sets the nexthop interface to ZS1. Once the session is created, PBF policy lookup happens, but does not match any rule. Traffic is NATed and flows through ZS1 as expected.
Now consider an app1 session. When the first packet arrives, NAT rule lookup happens, but does not match any rule (all rules are source-zone based). So first, session S1 is created and then, PBF policy lookup happens, and rule R2 is matched. Since the nexthop address is PT-T1 (169.254.0.2), the route for it will be via the PT-LAN1 interface (169.254.0.3). The traffic is forwarded over that interface. It is then reinjected into the transport VR WAN1, and creates session S2. Here, the ingress interface is PT1-T1, and egress interface is WAN1. Therefore, source-zone based NAT rule R2 does match, and NAT traffic flows through WAN1. None of the PBF rules will match.
The same thing happens for an app2 session.