[c-nsp] Cisco CBAC one stateful rule on an interface bypasses rules on other interfaces

--===============0775384718846712582==
Content-Type: multipart/signed; boundary="Sig_/9sjba0zvbRTIsYzqmWjoM2Q";
 protocol="application/pgp-signature"; micalg=pgp-sha512
Content-Transfer-Encoding: 7bit

--Sig_/9sjba0zvbRTIsYzqmWjoM2Q
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hello!

I have 2 vlan interfaces with both CBAC (inspect) ACLs.

I noticed that in that case the 2nd CBAC ACL (on the outgoing
interface) is not being processed, even if it would reject the packet.

It is working if traffic goes from an incoming interface without an
inspect rule. The ACL on the out interface is being processed in that
case.

Is that intended behavior, so if one inspect temporary rule exist, the
second ACL is bypassed?

In case I would like to have inspect rules on both interfaces for
traffic to the internet and to have firewalls between the VLANs, what
is the preferred way to handle this?

interface Vlan5
 ipv6 inspect spi-fw-vlan5 in
 ipv6 traffic-filter vlan5-acl-out out

interface Vlan30
 ipv6 inspect spi-fw-vlan30 in
 ipv6 traffic-filter vlan30-acl-out out

Both lists have a deny ipv6 any any at the end and the rejects are
being logged.

If I now try to connect from a machine in VLAN 5 to a machine in 30 to
a destination address/port that is should be rejected by
vlan30-acl-out, the traffic goes through.

If I try to do that from VLAN2 (no ACL attached), the ACL
vlan30-acl-out is being processed and the packet will be rejected.

--=20
kind regards
Marco

Send unsolicited bulk mail to [email protected]

--Sig_/9sjba0zvbRTIsYzqmWjoM2Q
Content-Type: application/pgp-signature
Content-Description: Digitale Signatur von OpenPGP
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEpXefSZn9R6zNZtTQE76RLz2tRfAFAmk7DlwACgkQE76RLz2t
RfBIahAAkq8YZpfbg73sU0wedjJIVehH7RcONoTyTtamWSQjpqMcFhjxCZYtRRqw
FRLJ8g/K/VY72RzDXYHfS/W2xf2GeLqZ2iUqloh+7i12Z94QWdYInvYB+0Whuob7
eqaMGVngiGHQo2FMdLT6cOrLQSV8ymocGFaOXFBqv+FN16nj7Itlh7z+grXUCtoT
3iAvidmD8aoQioGtBYH3k57exmQjzCCeZ67PwT5BWAL2OWTD//EPLgk9LWWSzlvY
K6tvN3Mx+fWJIpqSUgndqgC5LDklcdxM5MFlkB3rbc5BdEh045lwMeII4+YZJNES
l1c5qPpkQBWFc2K/f5MBdPmWD12oBzvsOqbeShH3pobwCbLAudwaowYqr+4voqZZ
HpQVI+scH28Y2bmJnWaZacn9wRAbMKj0VcUxpbnspejfguNyc5lb0jfYF/vuydpg
6VwnOAzV5i30ftr0Vyk15HkId6xoD+9XgtSsSp13kAVBRTIQh2mS0/MAPAJfjYBY
6ZiZDRsxDtSiyJmqeRlaLYPACI6OKvny/EewxzxvI0+GKvh/O4FoxIHIIzflf9v1
B/31kguzGhCvFk4F8FNPpuzViU41Wj6L1ePhjG5GzI3zmj3QdCSzRIIz4RH3EMqq
ufITjb4OeLqr78E6ud0Mqz2YNzoOh5m+l28IhRF1apQll8LFSfE=
=rHdQ
-----END PGP SIGNATURE-----

--Sig_/9sjba0zvbRTIsYzqmWjoM2Q--

--===============0775384718846712582==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KY2lzY28tbnNw
IG1haWxpbmcgbGlzdCAgY2lzY28tbnNwQHB1Y2submV0aGVyLm5ldApodHRwczovL3B1Y2submV0
aGVyLm5ldC9tYWlsbWFuL2xpc3RpbmZvL2Npc2NvLW5zcAphcmNoaXZlIGF0IGh0dHA6Ly9wdWNr
Lm5ldGhlci5uZXQvcGlwZXJtYWlsL2Npc2NvLW5zcC8K

--===============0775384718846712582==--