VRF and PAT/NAT

[GustavO]

I have a solution currently running on a cisco isr2811 and an ASA5510 which does the following:

On the isr2811 i got a number of customers all coming in on separate vlan's, every customer assign at least one private subnet (non-unique) on their vlan. In the isr I use VRF's and 1:1 NAT to have all customer's subnets NAT:ed to something unique, ie. customer on vlan 10 can use 192.168.0.0/16 and i translate it to 10.10.0.0/16, 192.168.0.0/16 on vlan 20 is translated to 10.20.0.0/16 and so on. After that it hits the ASA5510 which does PAT translation for the whole 10.0.0.0/8 and sends it out through a single public interface. The attached picture gives a good description of the situation.

If possible, I would want to do all of the above in one single J2320, both VRF or something similar to handle the overlapping subnets and PAT to just have to handle the public interface. Any ideas as how to achieve this? If that is not possible, i could do the PAT in the ASA and just the VRF-part in the J2320, as I do with the isr2811 today.

Any suggestions would be gladly considered, thanks in advance!

[mikep]

Hi,

you can do this by using lt-interface (you need two logical units per VRF) IMHO. Nat-Rule vrf1 makes the first NAT (from 50.50.1/24 to 20.1.1/24) inside VRF. Nat-Rule public PATs 20/8 to 10.10.20.2. Like that:

lab@J6350-081-112# show routing-instances
nat-test {
    instance-type virtual-router;
    interface lt-0/0/0.0;
    interface ge-0/0/3.100;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop 40.40.0.2;
        }
    }
}

ab@J6350-081-112# show interfaces

lt-0/0/0 {
    unit 0 {
        encapsulation frame-relay;
        dlci 100;
        peer-unit 1;
        family inet {
            address 40.40.0.1/16;
        }
    }
    unit 1 {
        encapsulation frame-relay;
        dlci 100;
        peer-unit 0;
        family inet {
            address 40.40.0.2/16;
        }           
    }
}
ge-0/0/2 {
    unit 0 {
        family inet {
            address 10.10.20.1/24;
        }
    }
}
ge-0/0/3 {
    vlan-tagging;
    unit 100 {
        vlan-id 100;
        family inet {
            address 50.50.1.1/24;
        }
    }
}

lab@J6350-081-112# show security
nat {
    source {
        pool vrf1 {
            address {
                20.1.1.0/24;
            }
            port no-translation;
        }
        pool public {
            address {
                10.10.20.1/32;
            }
        }
        rule-set vrf1 {
            from zone vrf1;
            to zone vrf1;
            rule vrf1 {
                match {
                    source-address 50.50.1.0/24;
                }
                then {
                    source-nat pool vrf1;
                }
            }      
        }
        rule-set public {
            from interface lt-0/0/0.1;
            to interface ge-0/0/2.0;
            rule public {
                match {
                    source-address 20.0.0.0/8;
                }
                then {
                    source-nat pool public;
                }
            }
        }
    }
}

zones {
    security-zone trust {
        tcp-rst;
        interfaces {
            ge-0/0/0.0 {
                host-inbound-traffic {
                    system-services {
                        http;
                        https;
                        ssh;
                        telnet;
                        dhcp;
                        ping;
                        snmp;
                    }
                }
            }
            ge-0/0/2.0 {
                host-inbound-traffic {
                    system-services {
                        all;
                    }
                    protocols {
                        all;
                    }
                }
            }
            lt-0/0/0.1 {
                host-inbound-traffic {
                    system-services {
                        all;
                    }
                    protocols {
                        all;
                    }
                }
            }
        }
    }
    security-zone untrust {
        screen untrust-screen;
    }
    security-zone vrf1 {
        interfaces {
            lt-0/0/0.0 {
                host-inbound-traffic {
                    system-services {
                        all;
                    }
                    protocols {
                        all;
                    }
                }
            }
            ge-0/0/3.100 {
                host-inbound-traffic {
                    system-services {
                        all;
                    }
                    protocols {
                        all;
                    }
                }
            }
        }
    }
}
policies {
    from-zone trust to-zone trust {
        policy default-permit {
            match {
                source-address any;
                destination-address any;
                application any;
            }
            then {
                permit;
            }      
        }
    }
    from-zone trust to-zone untrust {
        policy default-permit {
            match {
                source-address any;
                destination-address any;
                application any;
            }
            then {
                permit;
            }
        }
    }
    from-zone untrust to-zone trust {
        policy default-deny {
            match {
                source-address any;
                destination-address any;
                application any;
            }
            then {
                deny;
            }
        }
    }
    from-zone trust to-zone vrf1 {
        policy default-permit {
            match {
                source-address any;
                destination-address any;
                application any;
            }
            then {
                permit;
            }
        }
    }
    from-zone vrf1 to-zone trust {
        policy default-permit {
            match {
                source-address any;
                destination-address any;
                application any;
            }
            then { 
                permit;
            }
        }
    }
    from-zone vrf1 to-zone vrf1 {
        policy default-permit {
            match {
                source-address any;
                destination-address any;
                application any;
            }
            then {
                permit;
            }
        }
    }
}

lab@J6350-081-112# show routing-options
static {
    route 20.1.1.0/24 next-hop 40.40.0.1;
}
 

Kind Regards

Michael Pergament

Juniper Networks

[GustavO]

Hi Michael,

First of all a huge thanks for your help. I've set up a test environment with your configuration as a starting point and I'm moving along in the right direction.

I have gotten as far as I have traffic running from the non-public subnet (50.50.1.0/24 in your example) to the outside world as the translated address 10.10.20.2. A couple of questions I've not been able to find an answer to:

 1 I only have one vlan/vrf/lt/virtual-router setup as of now (vlan100 with 50.50.1.0/24), when i add the second, third (and so on) customer, what parts of the configuration do I need to be specific for each user and what part can be global? Of course a small-as-possible configuration is preferred for each new customer to ease management.

 2 The main objective with this setup is to use the SIP alg together with PAT to hide a large number of phones at different customer premises behind one single public address. Hence, i need the SIP alg on the PAT (but not the first NAT) to avoid all the issues related to SIP and NAT/PAT. At the moment i have global sip alg (set security alg sip) but that seem to apply the sip alg on the first nat (the SIP packet is overwritten with the 20.1.1.0/24-subnet) and not the pat. Is it possible to enable the alg for just the last PAT (in the "public" rule-set)?

 3 How many customers/vlans is it possible to add to this setup? As i understand it the 2320 has a limitation of 20 virtual routers, so I suppose 20 is the maximum?

 4 The way I understand the lt interface and the virtual-router, is this: The ingress interface ge-0/0/3.100 and a lt interface (lt-0/0/0.0) is added to the virtual router. The virtual router's next hop 40.40.0.2 makes the traffic exit through lt-0/0/0.0 (40.40.0.1) to lt-0/0/0.1 (40.40.0.2), since lt-0/0/0.0 and lt-0/0/0.1 are in the same subnet (40.40.0/16). The NAT is (when?) in vrf1 upo egress or ingress? A new lookup is done which routes the packet from lt-0/0/0.1 to ge-0/0/2.0 where the rule-set "public" does the PAT to the public address.

 5 In a traceroute the 40.40.0.2 hop is visible to the customer. In the case where I can use the same lt-interface(s) for all customers, this isn't a problem since i can easily use a public address for this purpose. But in the case where every customer/vlan needs a separate lt-interface(s), this wouldn't be good since i would need to use rfc1918-addresses and they could overlap the customer's subnet. Although using non-public addressing for those kind of purposes (even if overlapping) isn't all that bad, I'd rather avoid it if possible.

Thanks once again!

[mikep]

Hi,

 1 I only have one vlan/vrf/lt/virtual-router setup as of now (vlan100 with 50.50.1.0/24), when i add the second, third (and so on) customer, what parts of the configuration do I need to be specific for each user and what part can be global? Of course a small-as-possible configuration is preferred for each new customer to ease management.

[Michael] You would need to configure new IP address, new zone, new policies, new VRF, two new lt-units, new VRF-NAT. In other words: a lot. However, you could right a macro which would do all this automatically once you have to add new customer.

 4 The way I understand the lt interface and the virtual-router, is this: The ingress interface ge-0/0/3.100 and a lt interface (lt-0/0/0.0) is added to the virtual router. The virtual router's next hop 40.40.0.2 makes the traffic exit through lt-0/0/0.0 (40.40.0.1) to lt-0/0/0.1 (40.40.0.2), since lt-0/0/0.0 and lt-0/0/0.1 are in the same subnet (40.40.0/16). The NAT is (when?) in vrf1 upo egress or ingress? A new lookup is done which routes the packet from lt-0/0/0.1 to ge-0/0/2.0 where the rule-set "public" does the PAT to the public address.

[Michael] Your understanding is absolutely correct.

  5 In a traceroute the 40.40.0.2 hop is visible to the customer. In the case where I can use the same lt-interface(s) for all customers, this isn't a problem since i can easily use a public address for this purpose. But in the case where every customer/vlan needs a separate lt-interface(s), this wouldn't be good since i would need to use rfc1918-addresses and they could overlap the customer's subnet. Although using non-public addressing for those kind of purposes (even if overlapping) isn't all that bad, I'd rather avoid it if possible.

[Michael] You cannot use the same interface in multiple VRFs.

I do not know the answer for 2 and 3 from the top of my head. I will come back to you if I know more.

Kind Regards

Michael Pergament

Juniper Networks

[GustavO]

Ok so I've now set up a second vlan/vrf/zone and everything but something fails :-( With the attached configuration, I am able to get traffic through from vlan100 but not from vlan110. A traceroute from vlan110 to the outside shows the hop to 40.40.0.6 but not further so i suppose there is something wrong with the PAT-part. As usual, any comments welcome!

Since my post can't exceed 20k characters, configuration is on pastebin, here:

http://www.pastebin.org/722 

[GustavO]

Since I'm not able to the the PAT part of this working OK (since it seems the SIP ALG must be active on a global level) I've decided to buy another security context for the asa5510 and put the j2320 behind it and just do the NAT in it (the same thing i do with a isr2811 today) but am a bit puzzled about the setup. The amount of configuration and the complexity of it makes me think that there must be some other way.

If I go by the example above, but don't do the PAT-part, I still need, for every customer:

 * Two lt-interface units

 * A virtual-router routing instance

 * The interface and address facing the customer end

 * Nat rule-set and source nat pool

 * Security settings

 * A new zone for the customer vlan interface

 * Addresses (unique) for routing between the lt- and physical interfaces 

All in all, a _very_ big amount of error-prone configuration. The ISR2811 need about four lines for every new customer...

So what i'm trying to achieve is having different customers on one physical interface (say ge-0/0/0), but separate vlan, subnet overlapping allowed. On another interface (say ge-0/0/1) i want one unit/vlan where traffic is translated from the 192.168.0.0/16 on ge-0/0/0.<unit> to 10.<unit>.0.0/16, with no inspection or anything, just a no-port translated NAT.

Is there any way to accomplish this with a simpler configuration than the method above?

Any hints, thoughts, suggestions are welcome!