Cisco ASA Support - Features Question

[alecdhuse]

I'm interested in adding Cisco ASA support to this module. I've been looking at the current syntax / features for iptables here and thinking about how I could adapt this for the ASAs.

There are a few differences between iptables and ASA that might not be compatible and I wanted to get thoughts on this. For example: ASA doesn't have chains, the closest thing might be access-lists. I'd like to get some opinions on if I should try to stick with a 'chain' feature or go with an 'acl' I've given an example what the acl might look like below:

firewall { '000 accept all port 53 traffic from 8.8.8.8': acl => 'access_in', action => 'accept', proto => udp, source => '8.8.8.8', dport => '53', destination => "any", }->

Also for Cisco firewalls the actions are permit and deny. I think the action => 'accept' is pretty clear but someone with only a Cisco firewall background would put action => 'permit' Would it be acceptable for the module to treat accept and permit as the same?

Thanks!

[kbarber]

Can you give a corresponding Cisco ASA configuration sample for the rule above? My memory of Cisco acls is vague.

[alecdhuse]

Sure, I wrote up a few examples already:

Cisco: access-list access_in extended permit udp host 8.8.8.8 eq domain any

Puppet: firewall { '000 accept all port 53 traffic from 8.8.8.8': acl => 'access_in', action => 'accept', proto => udp, source => '8.8.8.8', sport => '53', destination => "any" }->

Cisco: access-list access_in extended deny ip 192.168.0.0 255.255.0.0 any

Puppet: firewall { '001 deny all traffic from 192.168.0.0/16': acl => 'access_in', action => 'deny', proto => ‘ip’, source => '192.168.0.0/16', destination => "any" }->

Cisco: access-list access_in extended permit tcp any host 10.100.25.100 eq 3389

Puppet: firewall { '002 allow remote desktop into 10.100.25.100': acl => 'access_in', action => 'accept', proto => ‘tcp’, source => 'any', destination => ‘10.100.25.100’, dport => ‘3389’ }->

If you need more just let me know.

[alecdhuse]

I'll just start writing with the acl fact and able to use accept/permit and reject/deny. If this needs to be changed later I will do that.

[apenney]

I suspect long term that this module is already way too iptables specific. We've considered just accepting that and renaming it to iptables and not trying to make it a "generic" firewall module with multiple providers. Did you get very far with this work?

I suspect long term a better approach is to make an iptables type/provider and a asa type/provider and then create a new firewall type/provider that is capable of proxying common functionality across the more specific types. It seems like that would allow you to get down and dirty with asa/iptables specific things as well as support the more common and generically portable stuff adequately.

Let me know if you want me to keep this open for longer or if you think this is unfeasible with the current architecture of firewall.

[alecdhuse]

I ended up being saddled with other projects, but I am still very interested in working on a Cisco ASA module. For what I was able to do, it seems a separate module for ASA would be a better option. Feel free to close this, when I get a bit more free time in a few weeks I should be able to start on an ASA module.

Thanks!

[chelnak]

Hello! We are doing some house keeping and noticed that this issue has been open for a long time.

We're going to close it but please do raise another issue if the issue still persists. 😄