[j-nsp] mx80 napt-44 with ms-mic on 13.2R5
Alexander Arseniev
arseniev at btinternet.com
Wed Oct 8 15:29:43 EDT 2014
The "Session: 1174405192" is a SYN-ACK being returned to Your router
from 199.16.156.102, it cannot establish a session (only SYN can).
Please post Your sanitized config ans ASCII diagram of traffic flow.
Thanks
Alex
On 08/10/2014 19:44, ryanL wrote:
> thx again alex. i've found a clue, but i'm unclear why it's happening.
> my internal host is 10.1.20.55, trying to curl twitter.com, which
> hangs. i'm unclear why that return packet is counted as "Initiator"
> and is "Drop", and why there's two sessions for what is essentially
> the same flow.
>
> i'm opening a jtac case as well for some help, but maybe someone
> understands why a different session is getting created (i think that's
> what is happening?) and doesn't map back to the originating host
> properly.
>
> ry at iad1-er2# run show services sessions extensive
> ms-0/2/0
> Service Set: SSET1, Session: 1174405192, ALG: none, Flags: 0x0040, IP
> Action: no, Offload: no, Asymmetric: no
> TCP 199.16.156.102:443 -> <$natpool-ip>:32769 Drop I 3
> Byte count: 180
> Flow role: Initiator, Timeout: 4
> Service Set: SSET1, Session: 1442840643, ALG: none, Flags: 0x2000, IP
> Action: no, Offload: no, Asymmetric: no
> NAT PLugin Data:
> NAT Action: Translation Type - NAPT-44
> NAT source 10.1.20.55:40128 -> <$natpool-ip>:32769
> TCP 10.1.20.55:40128 -> 199.16.156.102:443 Forward I 2
> Byte count: 120
> Flow role: Initiator, Timeout: 4
> TCP 199.16.156.102:443 -> <$natpool-ip>:32769 Forward O 0
> Byte count: 0
> Flow role: Responder, Timeout: 4
>
> On Wed, Oct 8, 2014 at 1:55 AM, Alexander Arseniev
> <arseniev at btinternet.com> wrote:
>> Juniper MS-MIC NAPT44 is stateful and is based on sessions (internally in
>> MS-MIC the "session" is basically 5-tuple packet info).
>> It does deal with asymmetric traffic within the same router - when
>> client->server packet exits interface1 but server->client packet returns on
>> interface2, this is supported - just assign same service-set to both
>> interface1 and interface2 identically.
>> But in case of 2 separate physical routers, if there is no session info
>> exchange between 2 routers, then asymmetric traffic does not work.
>> You may need this feature
>> http://www.juniper.net/techpubs/en_US/junos13.3/topics/topic-map/nat-interchassis-high-availability-msmic-msmpc.html
>> for the asymmetric traffic to work with NAPT44, but only for failures, not
>> persistent trafic asymmetricity.
>> If Your traffic is persistently asymmetric then MS-MIC is a wrong type of
>> hardware to use, ScreenOS cluster or SRX cluster is the weapon of choice
>> then.
>> Thanks
>> Alex
>>
>> On 08/10/2014 07:34, ryanL wrote:
>>
>> hi. i've got nat working now, much thanks to everyone's tips. a final
>> question on this topic (i promise).
>>
>> how important is it for the ms-mic (in the mx80) to see the in/out
>> traffic happen on the same interfaces? for example, i have multiple
>> transit connections. the nat outbound packet could go out one transit,
>> return via another mx80, and then cross an iBGP session back to the
>> "originating" mx80 where the nat config lives.
>>
>> i've been able to confirm that if i move traffic in and out of the
>> same router, it's no problem. but as soon as i introduce some
>> asymmetry i tend to get into a bind where curl hangs. we can safely
>> assume acl's are not the issue in this scenario, and i'm not using any
>> of the stateful firewall features of the ms-mic.
>>
>> thx!
>>
>> On Wed, Sep 24, 2014 at 11:04 AM, ryanL <ryan.landry at gmail.com> wrote:
>>
>> very much appreciated, alex.
>>
>> On Wed, Sep 24, 2014 at 11:01 AM, Alexander Arseniev
>> <arseniev at btinternet.com> wrote:
>>
>> "service-filter" is a stateless firewall filter which has only 2 actions:
>> either "then service" meaning "divert to Service PIC" (be it MS-PIC, MS-DPC
>> NPU, MS-MIC etc) ; or "then skip" meaning "do NOT divert to Service PIC,
>> route the usual way".
>> "services stateful-firewall" stanza is for defining stateful-firewall
>> (SFW) services on Service PIC itself. This SFW service is less sophisticated
>> than SRX SFW (filters basic attacks like Teardrop/Land but cannot filter
>> more complicated attacks like Winnuke) but has more throughput.
>> There are cases when You have to use both. I.e. to offer granulated SFW
>> service to different customer subnets on same interface and/or spread the
>> load between >1 Service PIC, You have to use both "service-filter" and
>> "services stateful-firewall" stanzas.
>> I suggest You read "Junos Enterprise Routing" book which has excellent
>> primer on Juniper router services (interface-style vs nexthop style, SFW,
>> NAT, also IPSec) - either 1st or 2nd edition is fine since basics did not
>> change between the two.
>> HTH
>> Thanks
>> Alex
>>
>>
>>
>> On 24/09/2014 18:13, ryanL wrote:
>>
>> alex, thank you. very helpful. of course i particularly like your
>> alternative, and that's what i thought i was accomplishing in the first
>> place. guess not!
>>
>> can you explain the diff between `set firewall family inet service-filter`
>> vs the documentation example which references `set services
>> stateful-firewall` as part of the services set, and which is more
>> appropriate to use here in an ms-mic situation?
>>
>> On Wed, Sep 24, 2014 at 10:00 AM, Alexander Arseniev
>> <arseniev at btinternet.com> wrote:
>>
>> I see You are using interface-style NAT - please exclude all control
>> traffic in the service-filters from being diverted to MS-MIC, like below
>> (rough cut, only BGP and BFD are excluded as an example):
>>
>> set firewall family inet service-filter sf-in term 1 from protocol tcp
>> set firewall family inet service-filter sf-in term 1 from port 179
>> set firewall family inet service-filter sf-in term 1 then skip
>> set firewall family inet service-filter sf-in term 2 from protocol udp
>> set firewall family inet service-filter sf-in term 2 from port [ 3784
>> 4784 ]
>> set firewall family inet service-filter sf-in term 2 then skip
>> set firewall family inet service-filter sf-in term 3 then service
>> set firewall family inet service-filter sf-out term 1 from protocol tcp
>> set firewall family inet service-filter sf-out term 1 from port 179
>> set firewall family inet service-filter sf-out term 1 then skip
>> set firewall family inet service-filter sf-out term 2 from protocol udp
>> set firewall family inet service-filter sf-out term 2 from port [ 3784
>> 4784 ]
>> set firewall family inet service-filter sf-out term 2 then skip
>> set firewall family inet service-filter sf-out term 3 then service
>> set interfaces ge-0/0/0.0 family inet service input service-set SSET1
>> service-filter sf-in
>> set interfaces ge-0/0/0.0 family inet service output service-set SSET1
>> service-filter sf-out
>>
>> Alternatively, You can construct service-filters in such a way that only
>> "interested" traffic is diverted to MS-MIC:
>>
>> set firewall family inet service-filter sf-in term 1 from source-address
>> 10/8
>> set firewall family inet service-filter sf-in term 1 from
>> destination-address 0/0
>> set firewall family inet service-filter sf-in term 1 from
>> destination-address 10/8 except
>> set firewall family inet service-filter sf-in term 1 then service
>> set firewall family inet service-filter sf-in term 2 then skip
>>
>> set firewall family inet service-filter sf-out term 1 from
>> destination-address <your nat pool route here>
>> set firewall family inet service-filter sf-out term 1 then service
>> set firewall family inet service-filter sf-out term 2 then skip
>>
>> set interfaces ge-0/0/0.0 family inet service input service-set SSET1
>> service-filter sf-in
>> set interfaces ge-0/0/0.0 family inet service output service-set SSET1
>> service-filter sf-out
>>
>> HTH
>> Thanks
>> Alex
>>
>> On 24/09/2014 17:37, ryanL wrote:
>>
>> thanks for the replies, folks. indeed it was the no-translation thing
>> that is hanging up the commit, and not the reported napt-44 statement. silly
>> defect.
>>
>> i'm using this now:
>>
>> rule NAT-RULE1 {
>> match-direction input;
>> term term-2 {
>> from {
>> source-address {
>> 10.0.0.0/8;
>> }
>> destination-address {
>> 0.0.0.0/0;
>> 10.0.0.0/8 except; #<---- (good suggestion)
>> }
>> }
>> then {
>> translated {
>> source-pool NP2;
>> translation-type {
>> napt-44;
>>
>> and that seems to commit ok.
>>
>> however, implementing this on customer-facing interfaces broke the
>> customer, dropped BGP sessions, etc. my goal is to only nat traffic if it is
>> sourced from 10/8 and destined to anything other than 10/8. the NAT pool is
>> a static discard route exported in iBGP to ensure that this router attracts
>> return internet traffic in order to keep proper state.
>>
>> what am i doing wrong? the documentation is quite poor for this module's
>> implementation, and sadly i don't have a lab to play with.
>>
>> On Wed, Sep 24, 2014 at 2:13 AM, Alexander Arseniev
>> <arseniev at btinternet.com> wrote:
>>
>> napt44 is most definitely is supported on MS-MIC
>>
>> http://www.juniper.net/techpubs/en_US/junos13.2/topics/reference/general/nat-implementations-feature-comparison.html
>> What is not supported is "no-translation" knob.
>> Please change Your config to (rough cut):
>> 1/ delete term-1, and
>> 2/ change term-2 to:
>>
>> + term term-2 {
>> + from {
>> + source-address {
>> + 10.0.0.0/8;
>> + }
>> + destination-address {
>> + 0.0.0.0/0;
>> + 10.0.0.0/8 except;
>> + }
>> + }
>> + then {
>> + translated {
>> + source-pool NP2;
>> + translation-type {
>> + napt-44;
>> + }
>>
>> - then re-test and report back please.
>> Thanks
>> Alex
>>
>>
>> On 24/09/2014 06:47, ryanL wrote:
>>
>> has anyone been successful here? i'm getting the following error, even
>> though juniper's docs seem to indicate this is supported on the ms-mic
>> with
>> 13.2.
>>
>> my ref guides are:
>>
>> http://www.juniper.net/techpubs/en_US/junos13.2/information-products/topic-collections/config-guide-services/index.html?features-ms-mic.html
>>
>> http://www.juniper.net/techpubs/en_US/junos13.2/topics/example/nat-nat44-config-ms-mpc.html
>>
>> ry at iad1-er2# show | compare
>> [edit]
>> + services {
>> + service-set SSET1 {
>> + nat-rules NAT-RULE1;
>> + interface-service {
>> + service-interface ms-0/2/0;
>> + }
>> + }
>> + nat {
>> + pool NP2 {
>> + address <pub_space>/28;
>> + port {
>> + automatic;
>> + }
>> + }
>> + rule NAT-RULE1 {
>> + match-direction input;
>> + term term-1 {
>> + from {
>> + source-address {
>> + 10.0.0.0/8;
>> + }
>> + destination-address {
>> + 10.0.0.0/8;
>> + }
>> + }
>> + then {
>> + no-translation;
>> + }
>> + }
>> + term term-2 {
>> + from {
>> + source-address {
>> + 10.0.0.0/8;
>> + }
>> + }
>> + then {
>> + translated {
>> + source-pool NP2;
>> + translation-type {
>> + napt-44;
>> + }
>> + }
>> + }
>> + }
>> + }
>> + }
>> + }
>> [edit interfaces]
>> + ms-0/2/0 {
>> + unit 0 {
>> + family inet;
>> + }
>> + }
>>
>> [edit]
>> ry at iad1-er2# commit check
>> [edit services]
>> 'service-set SSET1'
>> translation type not supported on ms-interface
>> error: configuration check-out failed
>>
>> [edit]
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>>
>>
>>
More information about the juniper-nsp
mailing list