Wireless Access

Reply
Regular Contributor I

netdestination name entries and policy rules

With AOS 6.5 Is it possible to use hostnames in a netdestination and everything behave as if it were a list of IP addresses? If the answer is no, fine.... otherwise, read on.

 

Here's my problem. I have a firewall policy configured that allows ssh from an alias (netdestination) to user, as follows:

ip access-list session test
alias test user svc-ssh permit

When using a hostname within the netdestination the resulting firewall rule fails to work in a stateful manner. For example:

netdestination test
name testpc.domain.com

I see in the firewall states the inbound ssh session is allowed, but there's no return path. 

If I use host instead of name like this:

netdestination test
host 1.2.3.4

Then it works just fine. So the question is whether this ought to work, or not. The controller is running 6.5.4.10

Regular Contributor I

Re: netdestination name entries and policy rules

Having played with this a bit more, it looks like what I want to do isn't possible, though it would be good to have that confirmed....

 

However what's caused confusion is if I try to ssh to a user with this policy from a random machine, which should not be allowed, the firewall state in the controller is listed as allowed.

 

So I see something like:

src: 1.2.3.4 port: 6936   dest: 4.3.2.1 port:22  TCP allow

 

A TCP dump on the user end device suggests this traffic is not getting thorugh, so why does the controller report an allow that shouldn't be and indeed appears not to be?

Re: netdestination name entries and policy rules

May be a basic question, but your controller does have reachable name servers defined so that it can resolve the hostname, correct?

 

When you source traffic from a machine to your wireless user, what role is being applied to the source machine? Is it wireless as well, or wired? Curious if it's on a trusted network which is why you see the traffic allowed.


Charlie Clemmer
Aruba Customer Engineering
Regular Contributor I

Re: netdestination name entries and policy rules

Hey Charlie, yes got DNS setup. I've verified I can resolve the hostname of the machine I'm testing in the netdestination.

 

The source traffic is coming from a machine on our wired network. That traffic would be considered trusted, though the policy applied to the wireless role in play here blocks it.

Guru Elite

Re: netdestination name entries and policy rules

Type "show firewall dns-names" to see what was resolved, if anything for that hostname.


*Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba Networks or Hewlett Packard Enterprise.*
ArubaOS 8.4 User Guide
InstantOS 8.3 User Guide
Airheads Knowledgebase
Airheads Learning Videos
Aruba Central Documentation
Sign up for Security Alerts
Aruba Technical Webinars

Re: netdestination name entries and policy rules

If the traffic is sourced from a trusted network, is there any firewall policy applied to the wired interface?

 

What is the user role and associated policies applied to the user? It sounds like the logic is backwards here ... the wireless user policy is trying to stop traffic sourced not from the user but from somewhere else. If the user role does not allow for ssh from the client, that could explain what you are seeing.


Charlie Clemmer
Aruba Customer Engineering
Regular Contributor I

Re: netdestination name entries and policy rules

"show firewall dns-names" looks ok.

(Arubal2) # show firewall dns-names | include netpc
netpc002.york.ac.uk    74  1      144.32.226.185

 

There's a firewall policy on the wired port of the controllers blocking mDNS traffic. Because the traffic sourced from the wired side of the controller could legitimately be destined for any wireless client, depending on policy, we rely on assigning clients to roles. I can't see how we could assign roles to the wired traffic, but have possibly misunderstood something.

 

In this case a group of machines (robots in a lab environment) need to be able to communicate with each other, and the internet, but nothing else on campus (for reasons) other than SSH from specific machines in the lab.

 

The role I'm assigning to the robots has been given DHCP, DNS, then a set of rules that says:

src:<subnet> dest:<subnet> any allow

src:<alias allowed PCs> dest:user svc-ssh allow

src:any dest:any svc-icmp allow

src:any dest:user any deny

src:user dest:<campus subnets> any deny

allow all

 

The above appears to work just fine providing I use IP addresses in the netdestination containing the allowed PCs. The wireless clients can communicate with each other, they can be reached on SSH only from the intended PCs. They can't reach campus resources but can get to internet resources off campus... It's all good. However as soon as I put a machine into the netdestination by hostname that machine can't SSH.

 

So it doesn't appear to be a problem with the policy but, again, happy to be told there's a better way to achieve this.

Guru Elite

Re: netdestination name entries and policy rules

I feel a diagram would be useful here.


*Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba Networks or Hewlett Packard Enterprise.*
ArubaOS 8.4 User Guide
InstantOS 8.3 User Guide
Airheads Knowledgebase
Airheads Learning Videos
Aruba Central Documentation
Sign up for Security Alerts
Aruba Technical Webinars

Re: netdestination name entries and policy rules

Agreed


@cjoseph wrote:

I feel a diagram would be useful here.


 


Charlie Clemmer
Aruba Customer Engineering
Regular Contributor I

Re: netdestination name entries and policy rules

OK, here's something for starters, hopefully this makes some sense to you folks.

diagram.png

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: