Dear Matthew,
Thank you for the response.
Yes, we are using NAT44 ED mode and have an output-feature variant
configured on the wan interface.
wan-ens7 output-feature out
Will try to follow the suggestion you posted to re-order the NAT/ACL nodes
so that ACL gets applied post-SNAT of the original
On Tue, Sep 22, 2020 at 12:21 PM Andrew Yourtchenko
wrote:
> I suggest making a unit test that captures this behavior and fails, then
> we can look at what is the best way of fixing it and incorporate into the
> CI...
>
> I remember this type of scenario being addressed once, not sure if it was
But you could probably work around it by having the ACLs on the inner
interface.
[VENKAT]: We currently are following that approach. Setting ACLs on the LAN
interface. But it comes with its own problems.
- First, the WAN interface is wide open to the internet without any FW
rules
-
I suggest making a unit test that captures this behavior and fails, then we can
look at what is the best way of fixing it and incorporate into the CI...
I remember this type of scenario being addressed once, not sure if it was the
same one or not...
But you could probably work around it by
Thank you Andrew for the pointers and setting the expectations for VPP ACL.
On another topic, since the stateful behavior of ACL is per interface, I
setup permit+reflect output ACL on WAN interface ( Internet-facing Public
IP) for internet bound traffic. And I also have to Deny all incoming
> On 17 Sep 2020, at 23:55, Venkat wrote:
>
>
>
>> 2. What happens when ACL config is modified while traffic is flowing? Would
>> the packets continue to hit the special-case "-1" session until the session
>> is timed out and re-claimed? If that's true, then packets would continue to
>>
2. What happens when ACL config is modified while traffic is flowing? Would
the packets continue to hit the special-case "-1" session until the session
is timed out and re-claimed? If that's true, then packets would continue to
sneak through even when a user modifies the ACL from Permit+Reflect to
> On 17 Sep 2020, at 21:21, Venkat wrote:
>
>
> Thanks, Andrew,
>
> And I noticed that sessions get deleted/reclaimed when ACL is disassociated
> from the interface to which it was attached prior.
> Maybe that's one option to have ACL detach and reattach to the interface when
> there is
Thanks, Andrew,
And I noticed that sessions get deleted/reclaimed when ACL is disassociated
from the interface to which it was attached prior.
Maybe that's one option to have ACL detach and reattach to the interface
when there is any modification to the ACL to have immediately expected
behavior
> On 17 Sep 2020, at 19:29, Venkat wrote:
>
>
> Andrew,
>
> I have a few follow up questions on the stated behavior.
>
> 1. Does the behavior you outlined about hitting special-case "-1" entries
> apply to UDP traffic as well if the ACL rule is stateful?
Yup.
>
> 2. What happens when
Andrew,
I have a few follow up questions on the stated behavior.
1. Does the behavior you outlined about hitting special-case "-1" entries
apply to UDP traffic as well if the ACL rule is stateful?
2. What happens when ACL config is modified while traffic is flowing? Would
the packets continue
Thank you Andrew for taking the time and responding to my questions.
Much appreciated.
On Tue, Sep 15, 2020 at 2:01 AM Andrew Yourtchenko
wrote:
> Hi Venkat,
>
> Before doing ACL checks, acl-plugin checks the establshed sessions on
> the given interface.
>
> If an already established session
Hi Venkat,
Before doing ACL checks, acl-plugin checks the establshed sessions on
the given interface.
If an already established session is hit the action is set to "3" and
no further ACL check is done, which is what you see in your output.
For that case, the ACL# in the trace is a special-case
13 matches
Mail list logo
