Rules with Policy not working as intended

[Akkertje]

I have the following setup for testing purposes which i am unable to get working properly. i might be doing something wrong but i dont see what.

I have a role in Policy which i named LAB-CORP-ROLE. Clients logging in with dot1x (LAN and WLAN) get the proper Role. With this role i have defined a few basic rules:

I am testing this with LAN, i know we have to manualy rearrange the rules in the EWC, which is realy stupid, but that's my honest opinion...

The role is Contain to vlan, I think this has a implicit permit at the bottom of the rules?
i then allow: Base Services, the predefined ones: Permit IP ARP, BootP Server and DNS.

I created another rules which i called deny RFC's. I want to block all traffic to internal IP adresses and allow DNS, DHCP and ARP.

The client does get an IP but is unable to resolve DNS to an internal DNS server, even while ill explicitly allow udp 53 (to all ip's i suppose) If i add a permit to the IP of the internal DNS server it works fine. This is not what i want to do. I hope i made myself clear and i also hope someone here might be able to tell me what i am doing wrong.

I also tried to change the Access control on this role to Permit and then add the vlan to vlan Egress tab (untagged ofcourse) I can then see the switchport does get the untagged vlan on that port but ni mac adresses are being learned... Seems like a bug as well? Am i doing something wrong?

Kind regards!

[Brian_Anderson]

Would be good to know the outcome of the case when it is resolved. Keep us up to date, always something to add to toolbox if there is a solution.

[Akkertje]

Hi Brian,

This wont be possible i'm afraid. This institution is kind of keen on the security of their network for particular reasons and suggesting a public DNS would not fit in their security plan t.b.h. And for now this is only a test. They want to be able to allow specific ports to specific server in there internal network. Depending on the role u get the right to do RDP etc or nothing at all. So we do need this to work.

Thanks again for thinking with me on this one. I have already created a case because i think this product should be able to do basic stuff like this. This is what the customer bought it for. I just didn't think this would be such a big issue...

[Brian_Anderson]

I've been thinking about this. Should have taken screenshots of the sites I've setup. Most of the time in a situation like this for wired policy, if they don't want to allow any traffic to internal (like you, only want to do DNS to internal server and nothing else) they are open to using an external DNS, like OpenDNS or Google and therefore able to block everything internal. Would that be an option for you?

As I mentioned before, DHCP deny doesn't work on wired policy.

[Akkertje]

Hi JS,

Thanks for this, does help. I get the following:

PID |Rule Type |Rule Data |Msk|PortStr |RS|ST|STDO|VLAN|CoS |Mir|U|
2 |IPDest |10.0.0.0 | 8|All | A|NV| |drop| | |?|
2 |IPDest |172.16.0.0 | 12|All | A|NV| |drop| | |?|
2 |IPDest |192.168.0.0 | 16|All | A|NV| |drop| | |?|
2 |UDPDestPort |53:10.77.248.10 | 48|All | A|NV| |fwrd| | |?|
2 |UDPDestPort |67 | 16|All | A|NV| |fwrd| | |?|
2 |Ether |2054 (0x806) | 16|All | A|NV| |fwrd| | |?|

So it seems that any traffic destined to any of the RFC adresses gets blocked. As the DNS and the DHCP are below those drop rules. Why would DHCP work then and DNS not? Is there any other way i can reach my configuration?

[Akkertje]

Is there any way to check these policy's on HITS (on the CLI) or see the precedence of the rules in the switch itself. That might help me understand and sort out the rules more efficient.