[j-nsp] BCP for filtering management access, system-wide

[Alexander Arseniev]

Hello,

On 25/07/2016 23:34, Jason Lixfeld wrote:
> Hi Chris, et all who have suggested that lo0 is the correct place to put these filters,
>
> I’ve been through the Day One book previously, and I suspect Chip’s Safari link is much the same.  Except here’s my problem after having gone through that framework -
>
> I have my ‘global’ scope (which I believe can also be referred to as inet.0), which holds my MPLS underpinnings - LDP, ISIS and MP-BGP;
> I have my ‘management’ scope, which is inside a VRF-type routing instance, and is also where my management systems reside;
> I have other VRF-type routing instances, where untrusted networks reside;
>
> I want to allow SSH from my management VRF primarily (which is currently attached to lo0.somthing), and from any interfaces inside inet.0 (i.e.: internal point-to-point core/backbone links) as a backup incase my MPLS core explodes.  I want to disallow access from anywhere else.
If I understand correctly,  "other VRF-type instances" need to disallow 
SSH into interface IPs but inet.0 and "management VRF" need to allow that.
Please see 
https://kb.juniper.net/InfoCenter/index?page=content&id=KB23547 for 
JUNOS logic applicable to Your case. To take advantage of this logic, 
You can:
1/ add lo0.X subinterface into each "SSH-prohibited" VRF. It does not 
have to have an IP, just "family inet/inet6" is enough to attach a filter
2/ construct a filter for inet.0 and "management VRF" allowing SSH
3/ construct a separat filter for "other VRF" denying SSH
4/ apply these filters to lo0.0 and other units as needed. You can use 
groups to apply filters en masse.
5/ Job done!

>
> Near as I can tell, on EX physical interfaces, I cannot assign any address at all on an interface unit that is not 0 if it is intended to be ‘untagged’.  This means I have no way to separate interfaces from that are in my global scope from interfaces that are inside a routing instance, be it my trusted management instance or more importantly, inside any of the untrusted routing instances.
>
> This perceived limitation makes it very difficult to use apply-path (which is a super cool hook!) to select interfaces that I would like to accept something like SSH on.  Maybe this is to Chip’s point with regards to his thought that the EX filter space is rather limited, by comparison to other platforms?  Maybe this perceived limitation is just my own ignorance?
>
> This is why I was curious about the filter mechanism in forwarding options, but perhaps there is a way around my current problem preventing me from attaching to lo0 using apply-path?
>
Forwarding-options is not the best method here as You'd need to filter 
separately per routing instance.
HTH
Thx
Alex