Thus the standard practice has always been to protect lo0 with a firewall filter that just allows through the source IPs that you want. There’s really no gain from using a VRF for it, though people with a Cisco background tend to expect it, thus why it’s being added now-ish.
> On Jul 8, 2016, at 12:31 PM, Jason Lixfeld <jason-j...@lixfeld.ca> wrote: > > That’s interesting. I wouldn’t have expected to hear that about Juniper. > > Thanks for the insight! > >> On Jul 8, 2016, at 2:19 PM, Aaron Dewell <aaron.dew...@gmail.com> wrote: >> >> >> Yes, though there are occasional issues such as sshd only binding to the >> local IPs within inet.0. Whether that’s working yet or not will depend on >> version and the enhancement request previously mentioned. Last I heard, >> that was going to be a 16.1 or farther out feature, but it depends on which >> daemon, which platform, and which release. Doing management within a VRF is >> a new thing for Juniper and the feature is still in process of coming out. >> I would expect various issues with it, even if some things work. >> >>> On Jul 8, 2016, at 12:06 PM, Jason Lixfeld <jason-j...@lixfeld.ca> wrote: >>> >>> So if my management stations are is in the same VRF as lo0, no leaking >>> should be required. >>> >>> Of course, this implies that the underpinnings of route redistribution >>> (i.e.: connected/static into MP-BGP) inside the VRF are all present, so the >>> routing table on the EX knows how to get everywhere inside that VRF. >>> >>>> On Jul 8, 2016, at 1:52 PM, Aaron Dewell <aaron.dew...@gmail.com> wrote: >>>> >>>> >>>> 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-j...@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.dew...@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-j...@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 <clin...@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@puck.nether.net >>>>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>>>>>> >>>>>>> _______________________________________________ >>>>>>> juniper-nsp mailing list juniper-nsp@puck.nether.net >>>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>>>>> >>>>> >>>> >>> >> > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
