[j-nsp] in-band management interface vs. re firewall concepts/bcp

[Aaron Dewell]

Sorry!  I got stuck on SRX.  Ignore that lol.

So if you’re only putting lo0 into the VRF, then you’ll need some way to route in and out of the VRF to get there.  That could be via route leaking, etc.  That routing table will have to have a return route to the source, and the main instance will have to have a route to that /32.  You can’t put the management interface (em0, fxp0, vme, etc. depending on platform) into a VRF.  

As you’re route-leaking or whatever in order to get back and forth into the VRF, it really doesn’t buy you much on a Junos platform to put it there in the first place.  Thus, why nobody really does it in Juniper-land.  You could, in theory, only leak your management routes into the VRF and increase your security slightly, but you can also just filter source IPs in your lo0 filter with the same benefit.

You still get the same firewall filter protection (the input-list stuff) if it’s in the main inet.0 instance.  

So the common practice is to write the lo0 filter like this:

from a prefix list listing allowed sources using particular protocols (i.e. ssh) -> accept
anything else -> discard

That can be multiple terms or however you prefer to write it.  

> On Jul 8, 2016, at 11:34 AM, Jason Lixfeld <jason-jnsp at lixfeld.ca> wrote:
> 
> Sorry, I wasn’t trying to suggest I got an error, it was more of a conceptual config paste.
> 
> This is on an EX9200, which I don’t think support security zones?
> 
>> On Jul 8, 2016, at 1:25 PM, Aaron Dewell <aaron.dewell at gmail.com> wrote:
>> 
>> 
>> Did you write those firewall filters that you list?  What was the error that you got?
>> 
>> You’ll have to assign lo0 into a security zone, that might be what’s missing.  
>> 
>> "security zones functional-zone management” must be in inet.0.  You can do other zones in a VRF and do in-band management within them (though it’s slightly recommended against, due to potential of misconfiguration causing a security issue), but this should work.  That’s what Clinton was saying.  
>> 
>>> On Jul 8, 2016, at 11:20 AM, Jason Lixfeld <jason-jnsp at lixfeld.ca> wrote:
>>> 
>>> I’m not quite following.  This won’t work:
>>> 
>>> set interfaces lo0 unit 0 family inet address 10.219.60.54/32
>>> set interfaces lo0 unit 0 family inet filter input-list V4-ACCEPT-COMMON-SERVICES
>>> set interfaces lo0 unit 0 family inet filter input-list V4-ACCEPT-ESTABLISHED
>>> set interfaces lo0 unit 0 family inet filter input-list V4-DISCARD-ALL
>>> set routing-instances MANAGEMENT instance-type vrf
>>> set routing-instances MANAGEMENT interface lo0.0
>>> set routing-instances MANAGEMENT route-distinguisher 21949:21949
>>> set routing-instances MANAGEMENT vrf-target target:21949:21949
>>> 
>>>> On Jul 7, 2016, at 6:07 PM, Clinton Work <clinton at scripty.com> wrote:
>>>> 
>>>> I would still use lo0.0 as your always up in-band mgmt interface.  
>>>> JunOS doesn't support putting management into a routing-instance and I
>>>> have been pushing Juniper for this.   You can use inet.0 for management
>>>> and additional logical routers for data traffic, but that is different
>>>> than a Cisco management VRF.   
>>>> 
>>>> JunOS doesn't have an explicit control-plane interface and you attach
>>>> your control-plane filter to lo0.0 instead.   
>>>> 
>>>> --
>>>> Clinton Work
>>>> Airdrie, AB
>>>> 
>>>> On Thu, Jul 7, 2016, at 11:52 AM, Jason Lixfeld wrote:
>>>>> Hey there,
>>>>> 
>>>>> Coming from a Cisco background, I generally assign a loopback interface
>>>>> as my in-band management channel.  I stick that into my management VRF
>>>>> and that’s that.  Without knowing any better, my instinct would be to do
>>>>> the same in JunOS, but it seems as though lo0 is the control plane
>>>>> interface between user space and the re.  That feels somewhat different
>>>>> to me, because the Cisco equivalent is generally the control-plane
>>>>> “interface”.
>>>> 
>>>>> 
>>>>> So my question is what the best common practise is for an always-up,
>>>>> in-band management channel on JunOS in an exclusively L3 environment
>>>>> (i.e.:  no vlan or irb interfaces used at all in the system) without
>>>>> fully understanding whether that could also be lo0.0, or whether it
>>>>> should be lo0.somethingelse, or whether it should be something else
>>>>> entirely.
>>>> _______________________________________________
>>>> 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
>> 
>