Comware

Hello, the issue I'm having is that when I use an access-list to restrict traffic either inbound or outbound on a VLAN it denies the return traffic that is part of the same session. As an example, lets say I have VLAN 20 and VLAN 30. I have a host in VLAN 30 that I only want to allow telnet traffic to and no other traffic to any other host in that VLAN. In this case I used an outbound ACL configured it as described and applied it to VLAN 30. The result of this is that from a host in VLAN 20 I am able to telnet to the host in VLAN 30 and nothing else as intended; however, from the host in VLAN 30 I cannot get to anything else on the network. When looking at a packet capture from Ethereal it appears that when I ping from the host in VLAN 30 that the ping gets to the host in VLAN 20, but when that host tries to send the reply it is stopped by the switch. I don't know if this should be expected with ICMP traffic, but I should certainly be able to telnet from a host in VLAN 30 to a host in VLAN 20, but again I cannot. I will attach my config to this post. HP support says they are seeing the same behavior in their lab and that it is behaving as it should be, but I just cannot believe that this is consistent with the switch's design.

I'm pretty sure that is expected behaviour.

To get around it, I think there are one of two things you may need which the 5300 does not support.

1. The 'established' command
2. Ability to filter ICMP traffic.

The new 5400/3500 products can do this.

The other way you can attack it is to use the 'permit any any' at the end of your ACL and specifically deny everything else you don't want access allowed to. This isn't as secure but it should let you achieve what you want.

Well, it doesn't just apply to ICMP traffic though. Like I said once I apply the access list I cannot get any traffic from VLAN 30 to any other network. Even tcp sessions, so as an example once the access list is applied I cannot telnet out from a host in VLAN 30 or connect on port 80 to a web server. It effectively prevents you from applying any access lists to restrict traffic with a desintation address of the VLAN being restricted. I can't imagine that is as intended right?

Is there anyone out there using access-lists on the 5308xl that can shed some light, or tell me how you are using them?

If you use that example of trying to telnet out or connect to a web server on port 80 going out from VLAN 30, then you would need to allow for the return traffic in your "sql_out" ACL. The return traffic I believe is going to be sent to a port higher than 1023:

permit tcp 0.0.0.0 255.255.255.255 10.10.30.0 0.0.0.255 gt 1023

I've always found this document quite useful in trying to understand how ACL's work: http://www.samspublishing.com/articles/article.asp?p=376125&rl=1

I think you'll find Chapter 10 and the section about 'Two-way Traffic and the established Keyword', helpful.

Well, that is definitely interesting. I must confess I've worked with Cisco routers and firewalls for some time and to date have not been familiar with the established parameter of an ACL.

One last question and I think I can put this to rest. Can you take a look at page 9-24 of the Advanced Traffic Management guide (ftp://ftp.hp.com/pub/networking/software/6400-5300-3400-AdvTrafficMgmt-Oct2005-59906051.pdf) as they are using an example extended ACL to only allow incoming telnet sessions to a host and then suggest an ACL config for me that would effectively allow only incoming telnet sessions to VLAN 30, but allow hosts on VLAN 30 to connect to hosts outside its VLAN unrestricted?

At that point then I think

With the example on Page 9-42, it uses ACLs only on the 'in', which in my opinion can be easier to implement.

So for your configuration if you want other VLANs to only be able to telnet to a single host on VLAN 30, yet have VLAN 30 be able to communicate freely with the other VLANs, you can do it but once again you have to allow for that return traffic.

If you applied this 'in' for VLAN 1 I think it would achieve the same thing:

ip access-list extended "101"
permit tcp 10.100.11.0 0.0.1.255 10.10.30.4 0.0.0.0 eq 23
permit tcp 10.100.11.0 0.0.1.255 10.10.30.0 0.0.0.255 gt 1023
deny tcp 10.100.11.0 0.0.1.255 10.10.3.0 0.0.0.255
permit ip 10.100.11.0 0.0.1.255 0.0.0.0 255.255.255.255
exit

You would also need a similar ACL for VLAN 20.

With those in place, you may not actually need any ACL's on VLAN 30 then.

I don't profess to be an ACL expert at all, so I may be missing something obvious. If I am hopefully someone else can fill in the blanks or offer another alternative.

Go on and browse google for a "stateful vs stateless acl"

Unlike Router ACLs, firewall is stafeful (i.e., knows state or condition, aware of history and can predict future). TCP is stateful. For a UDP and even ICMP virtual state info is created.

Stateful ACL supporting devices:
HP 7000 series wan router, Cisco PIX, Cisco IOS Reflective ACL (standart feature set) Cisco IOS inspect ACL (security feature set)

OK, well that gets me where I need to be. Thanks to you guys for your answers. I've assigned points, and I think I am ready to go now as I've put together an ACL that given the stateless functionality of the 5308 should at least suit my needs for now.

Thanks again.

Given the stateless nature of the 5308 ACLs I've decided to only allow outbound traffic from my VLAN to a few specific hosts so that I can identify those in my ACL specifically to work around these issues.