Options

NAT question on M-series...

ccie15672ccie15672 Member Posts: 92 ■■■□□□□□□□
So... on the M-120 now with an MS-400 PIC, you can have like 35000 NAT terms configured against it.

Thats great, we need a ton of NAT... like probably close to 18000 terms altogether..

In a term of a NAT rule, you can specify destination prefix-list in the from clause.. also great... how many prefixes can be in that list?

Anyone know or anyone who works at Juniper can find out?
Derick Winkworth
CCIE #15672 (R&S, SP), JNCIE-M #721
Chasing: CCIE Sec, CCSA (Checkpoint)

Comments

  • Options
    AldurAldur Member Posts: 1,460
    Are you trying to do source nat or destination nat?

    I'm assuming that you're talking about destination nat in which case you can only specify 1 destination prefix per term in the from clause.

    The following commit error is given.

    "With translation-type destination static, the from clause must have only one prefix in destination-address or only one range in destination-address-range"

    If you're doing source nat then you can specify as many destination prefixes are you want in the from clause.

    HTH
    "Bribe is such an ugly word. I prefer extortion. The X makes it sound cool."

    -Bender
  • Options
    ccie15672ccie15672 Member Posts: 92 ■■■□□□□□□□
    Source NAT.

    Hey Aldur..

    We are trying to hack our way around that annoying NAT limitation... where you can't use the same pool in multiple NAT rules for a source translation... you know what I am talking about?

    So in our situation, we were thinking of making a "null router" basically virtual-router with no routes in it. It will have multiple sub-interfaces (representing our security tiers) going into a firewall.

    And as packets come in one of these subinterfaces they hit a interface-style NAT service-set, then come back and hit a post-service FBF filter that **** the packet into another virtual-router...

    For return traffic

    Using rib-groups we import that sub-interface into that virtual-router. Establish a BGP adjacency from a loopback in the virtual-router to the firewall over this subinterface... then packets coming back will go out this interface and hopefully hit the interface-style NAT service-set and then route down to the firewall (no post-service filter in this direction...)

    Is this plausible?
    Derick Winkworth
    CCIE #15672 (R&S, SP), JNCIE-M #721
    Chasing: CCIE Sec, CCSA (Checkpoint)
  • Options
    AldurAldur Member Posts: 1,460
    Wow, yes I would say that is a plausible solution but wow, definitely a complex one. In theory it sounds workable but you'll need to do some good testing to make sure.

    Let me know what comes of it, I'd be interested to see how that turns out.
    "Bribe is such an ugly word. I prefer extortion. The X makes it sound cool."

    -Bender
  • Options
    ccie15672ccie15672 Member Posts: 92 ■■■□□□□□□□
    We're abandoning that solution...

    Way too complex.

    I know that the SRX is the next NAT god box and everything, but what do you know of any plans to improve NAT on the M-series? I wish there weren't so many restrictions... the source NAT restriction (can't re-use pool across service-sets) is just killing me... I can't think of a logical reason why this wouldn't be allowed if the service-set is applied against a different service-pic interface that is in a different virtual (or logical) router...
    Derick Winkworth
    CCIE #15672 (R&S, SP), JNCIE-M #721
    Chasing: CCIE Sec, CCSA (Checkpoint)
  • Options
    AldurAldur Member Posts: 1,460
    To bad, I was really curious on how that would turn out. But you're very right, that was a complicated solution and I can only imagine what a nightmare that would be to troubleshoot.

    What version of code are you running?
    "Bribe is such an ugly word. I prefer extortion. The X makes it sound cool."

    -Bender
Sign In or Register to comment.