Mailing List Archive: ipfix is not accounting next-ip firewall actions properly

Hi,

Following simple scenario:

The firewall rule is on *input* of the interface where the traffic from the
source address is coming from:

term force-next-hop {
from {
source-address {
192.168.0.2/32;
}
}
then {
next-ip 192.168.1.1/32;
}
}
term accept {
then accept;
}

The router is multi homed to various ISPs via eBGP full table.

The firewall filter is working very well. All of the traffic from
192.168.0.2 is "nexted" to 192.168.1.1.

*Issue: *However, IPFIX is not considering the next-ip, instead it's acting
like the next-ip would not exist at all. That means, traffic from
192.168.0.2 is reported to be egressing multiple interfaces like the router
would handle it without the next-ip rule. So it seems that the sampling is
taking place before the firewall rule is applied. This is a very unexpected
behaviour. In reality traffic from that source IP is only egressing the
interface that's related to 192.168.1.1.

Currently, sampling is enabled on each interface (*family inet/inet6
sampling input+output*). We've already tried to sample via the firewall
action *sample* instead of the sampling statement *after* the next-ip term.
This did not change anything.

We assume this is a JunOS bug, but maybe we're doing something wrong here
(I cannot imagine but you never know).

HW/SW: MX204 / JunOS 18.3R2-S3.1
Also confirmed with MX480 / 17.3R3-S7.2 / MPC 3D 16x 10GE

More configuration details:
set chassis fpc 0 sampling-instance SAMPLER1
set chassis fpc 0 inline-services flow-table-size ipv4-flow-table-size 10
set chassis fpc 0 inline-services flow-table-size ipv6-flow-table-size 5
set forwarding-options sampling instance SAMPLER1 input rate 1024
set forwarding-options sampling instance SAMPLER1 family inet output
flow-server x.x.x.x port 2055
set forwarding-options sampling instance SAMPLER1 family inet output
flow-server x.x.x.x autonomous-system-type origin
set forwarding-options sampling instance SAMPLER1 family inet output
flow-server x.x.x.x version-ipfix template TEMPLATEv4
set forwarding-options sampling instance SAMPLER1 family inet output
inline-jflow source-address x.x.x.x
set forwarding-options sampling instance SAMPLER1 family inet output
inline-jflow flow-export-rate 400
set forwarding-options sampling instance SAMPLER1 family inet6 output
flow-server x.x.x.x port 2055
set forwarding-options sampling instance SAMPLER1 family inet6 output
flow-server x.x.x.x version-ipfix template TEMPLATEv6
set forwarding-options sampling instance SAMPLER1 family inet6 output
inline-jflow source-address x.x.x.x
set forwarding-options sampling instance SAMPLER1 family inet6 output
inline-jflow flow-export-rate 100

set interfaces ae0 unit 82 family inet sampling input
set interfaces ae0 unit 82 family inet sampling output
set interfaces ae0 unit 82 family inet6 sampling input
set interfaces ae0 unit 82 family inet6 sampling output
[...for every interface...]

Any help is highly appreciated.

Thanks,

Marcel
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Hi,

On 24.06.2020 12:28, Marcel Bößendörfer wrote:
> *Issue: *However, IPFIX is not considering the next-ip, instead it's acting
> like the next-ip would not exist at all. That means, traffic from
> 192.168.0.2 is reported to be egressing multiple interfaces like the router
> would handle it without the next-ip rule. So it seems that the sampling is
> taking place before the firewall rule is applied. This is a very unexpected
> behaviour. In reality traffic from that source IP is only egressing the
> interface that's related to 192.168.1.1.

I have seen things like this with Flow Export on MX before. In my case it was filter based forwarding towards a different RI with different interfaces for TE purposes. In that case the flow export would match the "Original" destination before the FBF took place which lead to wrong flow statistics on $collector.

This was years ago and i never checked back on that, seems like the behavior is still there.

I kind of remember it happening for flow-spec drop/rate-loimit routes/filters as well. So Flow would still report the traffic ingressing the interfaces while the filters were already blocking them. Which in the Case of flow-Spec was a good thing, because you could keep the announcement active as long as the attack lasted.

--
Kind Regards
Tobias Heister
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp