Wireless Access

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

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

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.

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.

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

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.

"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.

I feel a diagram would be useful here.

Agreed

---

@cjoseph wrote:

I feel a diagram would be useful here.

---

 

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

I've noticed an anomaly. 

 

When I was troubleshooting this on Friday, "show firewall dns-names" included the name of my test pc and showed it was in use, but did not list an IP address. There was no problem with the controller resolving the name, as I could ping the hostname.

 

When I put the entry back in over the weekend and ran the same command, suddenly the address is there, so I thought that was my mistake and I'd missed it previously. I was wrong.

 

Came into the office this morning, and with the resolved IP listed in the firewall dns-names it's working as expected.

 

I've removed the entry, saved, verified it's gone from the local controller, re-added, saved, verified it's there.... and look. no worky.

However, if I ping the hostname - to check the name resolves correctly, it's then resolved in the firewall.

 

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

(Arubal2) #ping netpc002.york.ac.uk
Press 'q' to abort.
Sending 5, 92-byte ICMP Echos to 144.32.226.185, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0.214/0.2648/0.386 ms


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

I've verified this behaviour with all the hostnames I've added to this netdestination. Left to its own devices the firewall does not resolve the name, but once I ping the host from that controller it works.

 

My conclusion from this is there's no problem with the policy. That works just fine, but there is a problem with the firewall not resolving the name. 

 

This feels like a bug to me.

I've verified the same behaviour on all of our local controllers.

I'm also seeing the same behaviour in my AOS 8 test lab, so perhaps there's something fundamental I'm missing here.... 

The "show firewall dns-names" display has a cache (15 minutes, I think) that expires after it is used.  It is not persistent, so I would not expect to see it all of the time.

I have no idea how this works under the hood, but as the firewall only works on IP addresses, I'm presuming it ought to resolve any hostnames in rules, in order to build the rule set.

 

Whether there's a reliable display of what has been resolved is quite important but secondary to the fact it just as far as I can see it just isn't working. It isn't resolving some of the addresses, and this is demonstrated by the rules not working. There isn't a time element at play as far as I can see.

Please open a tac case.  There could either be a bug or something that we do not understand about your network.

The response from TAC, which makes sense of the problem, is rather than perform DNS lookups of any host names required for rules, and periodically refresh these, what it the firewall actually does is.... nothing at all until a client, or the controller itself, performs a DNS lookup.

 

If that's correct it means, for me, AOS just doesn't have the ability to handle a hostname alias in the firewall. Because we can't use it for inbound connection control at all, and if a client directly uses an IP address, so doesn't perform a DNS lookup, that won't work either.

 

It seems this isn't a bug, but it appears to be a glaring failure of functionality.

 

I hope someone can explain to me why I'm wrong about that.

 

DNS blocking was to make sure that a client did not go to a domain for example or to allow a client to go to a domain.  It would be triggered by a client looking up the domain and we snoop on the responses to program into firewall dns-names.  That would then be used to block the traffic.

It would seem, from rereading your posts that you wanted to allow/block traffic from hosts using a DNS entry.  You are right, that would not work.

 

You can have a netdestination that has a list of ip addresses and hopefully those hosts have a static ip address so you can put it in there and get it to block consistently.

If you wanted to make things really secure, you would just have certificate-based SSH so that users would not be able to guess a username and password.

This particular example has just highlighted the issue, because the name resolution needs to happen independently of the client doing anything.

 

I think this is functionality that's been built for a specific task historically, but that wasn't at all clear to me. I've probably just missed it, but reading the user guide I didn't get any suggestion that host names in a netdestination alias were treated in a special way. I'd rather hoped the AOS firewall worked like any other firewall... but it doesn't, and that's a pita to be honest, but such is life.

 

The issue I'd hoped to get around is an IP address being reassigned to a new host. I can't rely on being told if a host has been decommissioned. If we were building our firewall rules around hostnames this wouldn't be a problem.

 

In the slow transition to AOS8 I've rebuilt most of of firewall rules using hostnames, Now I know that's almost entirely useless, it isn't a lot of work to fix it.... but it's incredibly disappointing.

Netdestinations were always designed as a destination, not a source, so I can see why this would not work. I would recommend opening up a feature request.

Yeah I can see how it's developed over time. Though if you come at it from a firewall rule perspective, they're not destinations... they're aliases.

 

And a netdestination does work perfectly well as a source alias... It's just the DNS resolution bit that's thrown me so much. The fact that even with a netdestination used as a destination, a name entry behaves in this special way that relies on snooping the DNS lookup definitely has some really useful applications, but it breaks the use as a firewall alias for me.

 

But yes, I'll put this through as a feature request... can't hurt.

As an aside, a colleague has just pointed out that the exciting new thing for Firefox of DNS-over-TLS won't work with this.

I think the 3 people that use DNS over TLS would agree.

Pretty soon, everything will be encrypted and there will be a limit to what we can restrict.

Yep... Remember, I don't want to use this for URL restrictions ;)

 

I just want to be able to use hostname aliases with my firewall.

So just to understand, you want to enable SSH from a device that registers in DNS, knowing the some other device could have the same ip address later and would be allowed, as a result if DNS is not purged?  Why not create a subnet for management computers and allow SSH specifically for that subnet so that it is more secure and more deterministic?

I’ve failed to explain the situation well.

 

This particular example isn’t network or server management, we’re across that. We have two lab spaces used by researchers working on cooperative robotics and the requirement is for machines in those labs to be able to ssh to robots on the WiFi. We could create another vlan/subnet and put those PCs on that, but.... there are sufficient reasons not to do that , especially when the right acl will do the job.

 

I don’t know why the research team want to have things restricted in this way, personally I wouldn’t take this approach, but it isn’t my call, it’s my job to help them meet their requirements.