Comware

Hello,

when I set an outbound acl for an interface, all traffic is blocked correctly, however the traffic for the management

processor is not. Is this documented somewhere or a bug?

Cheers,

      Thomas

Could you post a snippet of the config in question (and obfuscate whatever is necessary)?

Hello,

interface GigabitEthernet1/0/24
 port link-mode route
 packet-filter ipv6 3001 outbound
 ipv6 address 2A01:x:y:z::2/64

acl ipv6 number 3001
 rule 0 permit ipv6 source 2A01:a:b:c::/56
 rule 10 deny ipv6 logging

 from my provider I have a /64 transfer network and a /56 routed network. My switch has an ip address inside the /64

network. With the above configuration I can ssh into my switch using an IPv6 address on the public internet. This should

not be possible since the packets travelling back from my switch to a system on the internet should be blocked by the outbound ACL. However if I remove rule 0 from the above ACL systems which are route over the switch can no longer

contact the Internet as they should. Inbound ACLs work as they should.

I noticed this problem while debugging Police Based Routing. Since I have two uplinks with two different IPv6 address spaces. Both have a /64 transfer and a /56 network routed, I wanted to make sure that I don't get asymmetric routing eg packets comming in through one uplink and get answered on another uplink. This worked quite well for everything but not for the service processor eg sshing in to the switch from the internet. Inbound ACL apply as they should.

This is with the latest firmware available.

Cheers,

       Thomas

Unless its some bug the only thing I can currently think of is if that /64 is part of your /56 and because of that is being allowed.

For example:

linknet: 2A01:a:b:c::1/64

routed (with 2A01:a:b:c::1 as nexthop): 2A01:a:b::/56

What if you try something like:

acl ipv6 number 3001

 rule 0 deny ipv6 source 2A01:a:b:c::/56

 rule 10 deny ipv6 logging

That is flipping rule 0 so it becomes an deny instead of allow. If the traffic gets blocked now you can go further and experiment with the prefix size to determine why that rule thinks your /64 is part of that larger /56.

By the way in order to protect the mgmt interface(s) I would go for a inbound acl instead of outbound (or both if you want to avoid leaking of for example logging information).

Hello,

I already experimented and my conclusion is that it does not work. The question is why: Is it a bug or is it documented somewhere? And obviously I'm using inbound ACLs to protect my management processor. However outbound ACLs should apply to all traffic or should be documented. Also one thing that makes me think if I switch back to Cisco is the ACL logging. It is useless because you can't find out which source ip/destination ip source port destination port is triggering the ACL. So currently I can see this:

Jan  7 00:01:05 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  215 packet(s)
Jan  7 00:06:05 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  764 packet(s)
Jan  7 00:11:05 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  171 packet(s)
Jan  7 00:46:05 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  65 packet(s)
Jan  7 01:01:05 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  213 packet(s)
Jan  7 01:06:05 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  789 packet(s)
Jan  7 01:11:05 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  146 packet(s)
Jan  7 01:46:05 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  63 packet(s)
Jan  7 01:51:05 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  2 packet(s)
Jan  7 02:01:05 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  202 packet(s)
Jan  7 02:06:05 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  795 packet(s)
Jan  7 02:11:05 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  148 packet(s)
Jan  7 02:46:05 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  65 packet(s)
Jan  7 03:01:05 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  167 packet(s)
Jan  7 03:06:05 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  822 packet(s)
Jan  7 03:11:05 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  156 packet(s)
Jan  7 03:46:05 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  62 packet(s)
Jan  7 03:51:05 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  3 packet(s)
Jan  7 04:01:05 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  195 packet(s)
Jan  7 04:06:06 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  806 packet(s)
Jan  7 04:11:06 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  143 packet(s)
Jan  7 04:46:06 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  63 packet(s)
Jan  7 04:51:06 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  2 packet(s)
Jan  7 05:01:06 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  194 packet(s)
Jan  7 05:06:06 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  780 packet(s)
Jan  7 05:11:06 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  169 packet(s)
Jan  7 05:46:06 merlin %%10ACL/6/ACL_STATIS_INFO(l):  Number 3101   rule 175 deny ip logging  65 packet(s)

 Which is honestly totally useless. I hope that I'll find a command that enables me to see the individuals packets properties.

Cheers,

      Thomas

My interpretation of your config:

interface GigabitEthernet1/0/24
 port link-mode route
 packet-filter ipv6 3001 outbound
 ipv6 address 2A01:x:y:z::2/64

is that anything that is being sent out on gi 1/0/24 (that is traffic towards whatever is connected to gi 1/0/24) will first pass ACL 3001 which defines what is allowed or not (that is if its ipv6 traffic).

Regarding your log question that looks more like a stat dump every 5min than the actual traffic log.

I guess is this we see in your log output:

"

Set the interval for generating and outputting IPv4 packet filtering logs.

acl logging frequence <frequence>

Required. By default, the interval is 0. No IPv4 packet filtering logs are generated.

"

I think this is what you want:

"

Use an ACL to filter incoming or outgoing IPv4 or IPv6 packets. With a basic or advanced ACL, you can
log filtering events by specifying the logging keyword in the ACL rules and enabling the counting function.

"

However you have already setup logging for rule 10 so I dunno...

acl ipv6 number 3001
 rule 0 permit ipv6 source 2A01:a:b:c::/56
 rule 10 deny ipv6 logging

Perhaps you need to tweak your info-center configuration regarding logbuffer so it will accept all log levels (and not just informational and upwards)?

In a hardening guide for comware there was written that logbuffer and loghost should be configured to only accept "informational" level and upwards (to protect the cpu from unneccessary work) - im thinking of the "logging" keyword perhaps sits in a different loglevel currently not covered by your info-center configuration?

It may be caused by the  packet-filter default action in place.

It should be " packet-filter default deny" to deny everything that is not specified in the ACLs.

** Be carefull before changing this. You mau lose conectivity if there is no ACLs permiting the access.

Somenthing like that after applying:

[HP5900IRF]display packet-filter statistics interface Vlan-interface 30 outbound
Interface: Vlan-interface30
 Out-bound policy:
  ACL 3030
   rule 5 permit tcp destination 172.25.30.10 0 destination-port eq 3389 logging counting (624 packets)
   rule 10 deny icmp destination 172.25.30.12 0 logging counting

  Default action: Deny

It may help

Thanks,

Joel