0

I'm having difficulties with something I initially thought would be rather simple. I need to apply an outbound firewall filter on an MX10003's management interface. I'm currently using Lo0.0 as the management interface. If you're familiar with DISA STIG, the particular Vul ID is V-17822. The wording reads as though it is for a true OOBM interface, which this isn't. I figured I would still be able to apply a filter because the section talking about the outbound filter states "Verify that the egress filter blocks any traffic exiting the management interface that was not originated by the managed elements . Verify that the destination address is the NOC address space".

So I "show int terse" and grab the ipv6 address and link local address of Lo0.0 and begin making the filter as follows:

filter OUTBOUND {
term 1 {
    from {
        source-address {
            2001:db8::100/128;
            fe80::100/128;
        }
    }
    then accept;
}
term DEFAULT_DENY {
    then {
        log;
        syslog;
        discard;
    }
}

Interface:

show configuration interfaces lo0 unit 0

family inet6 {
no-redirects;
filter {
    output OUTBOUND;
}
address 2001:db8::100/128;

I commit confirmed the configuration and, to my surprise, my ssh connection drops immediately. Once the configuration rolled back and I was able to access the router, I tried to inspect the firewall log to identify what happened. I noticed some additional link local addresses being discarded so, for testing, I modified the source-address to be fe80::/64 and commit confirmed again. This time, I maintained my session. The questions I have regarding this are:

Why would putting an outbound filter on Lo0.0 with such a simple term cause me to lose connectivity?

Additionally, this doesn't seem like it would be best practice to me. Would it be better to go further into detail with the outbound filter to specify destination ports, next headers, and destination addresses for management and control plane traffic?

Thanks for the help!

3
  • 1
    Hi Ben, by "not originated by the managed elements" you mean the device itself right? if yes, sounds to me that you need host-inbound/ host-outbound filters rather than regular(stateless) filters. On the other hand recall that stateless filtes are 'lazy' and we need to be explicit on what to allow/deny. Here is an example allowing ssh: juniper.net/documentation/en_US/junos/topics/example/… HTH – DRP Apr 3 '20 at 6:27
  • @DRP The "elements" was throwing me off too. I'm pretty certain that it is a typo and should be singular. I copied and pasted that directly from the STIG check that I'm trying to answer to. I believe the intent of the check is to make certain that the device is only receiving and sending desired traffic. The rule title states "The management interface is not configured with both an ingress and egress ACL". The inbound filter I've built already is a lot more granular with terms for ssh, ntp, snmp, etc and I'm not having any issues with it. – Ben Apr 3 '20 at 11:55
  • @DRP additionally, I should state that the rule is specifically geared towards a physical OOBM interface. However, I'm currently using the logical interface on a dedicated routing-instance specifically for management traffic. – Ben Apr 3 '20 at 11:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.