I am used the older 8.0.X ASA software, so here's another confusion I have with the new 9.1x code. I unfortunately don't have an ASA 9.1x handy to try out these commands.
1. Here below is two different ways of creating the same service object as I understand. The first way is how I am used to doing it in the earlier code. And the second way is how it is with the new 9.1x code, I believe. My question is, what is the difference here ?(other than the fact that the second method allows the same object for both tcp and udp) and more importantly will the new 9.1x code accept either of these formats when I create a service object?
object-group service admin tcp
port-object eq 80
port-object eq 443
object-group service admin
service-object tcp http
service-object tcp https
2. The same question applies when creating network objects. In the two different methods below, will the ASA 9.1x accept either of these commands? also is one method better than the other in 9.1x?
object-group network remote-nets
network-object 10.8.0.0 255.255.0.0
network-object 10.9.0.0 255.255.0.0
object network remote-nets
subnet 10.8.0.0 255.255.0.0
subnet 10.9.0.0 255.255.0.0
The ACL syntax is not really that different compared to when you are using "object-group network" or "object network" in the ACL.
As a combined example allowing traffic from networks under "object-group" to a new under "object" would look like this
access-list TEST permit ip object-group OBJECT-1 object OBJECT-2
access-list TEST permit tcp object-group OBJECT-1 object OBJECT-2 eq www
access-list TEST permit udp object-group OBJECT-1 object OBJECT-2 eq domain
access-list TEST permit icmp object-group OBJECT-1 object OBJECT-2 echo
So only difference is the keyword/parameter "object-group" or "object" depending which type the following object actually is.
If you want to add the 2 created "object network" under an "object-group network" then you would use this format
object-group network remote-nets
network-object object remote-net1
network-object object remote-net2
So as you can see we need the "network-object object" to indicate that we are adding an actual "object" under this "object-group".
With regards to the traffic flow question there are many different situations.
- If you have no ACLs configured to the ASA interfaces then the "security-level" value determines from which interfaces networks you can initiate connections to which interfaces networks. (Allow from higher to lower)
- If you are using ACL on the interface then that will determine how traffic can be initiated. Typically ACLs are attached inbound direction so they only control connections initiated from behind that interface.
- Whether you use interface ACLs or not there are couple of situations where you might need additional commands on the ASA.
- If you have 2 interfaces with equal "security-level" and want to keep it that way and also want to allow traffic between them you need to have the command "same-security-traffic permit inter-interface"
- If you have a single interface which has traffic incoming to it and then forwarded back out through that interface then you will need the command "same-security-traffic permit intra-interface". The most common situation for this is when you have VPN Clients which need to connect to the Internet through the VPN connections to the ASA (outside interface) same naturally applies to connections between VPN connections.
In the new software you wont need to configure any NAT between your local interfaces if you dont want to NAT the networks.
The exception to this comes usually with VPN traffic. Then NAT0 is usually needed. Since both your VPN traffic and Internet traffic usually flow between "inside" and "outside" interface that means that if there is no NAT0 configuration the traffic gets matched to the Dynamic PAT.
Hope this helps
You can use whichever one you like.
Do notice that they are used in a different way in the ACL statement for example.
If I were to use your above examples in an ACL that would allow all HTTP/HTTPS traffic they would look like this
access-list TEST permit tcp any any object-group admin
access-list TEST permit object-group admin-2 any any
I tested the above on my firewall just to give an example. I created the other "object-group" with another name as it naturally would not let me use 2 sama named "object-group".
The actual ACL created above would look like this in the "open" form.
access-list TEST; 4 elements; name hash: 0xd37fdb2b
access-list TEST line 1 extended permit tcp any any object-group admin (hitcnt=0) 0x258ea30a
access-list TEST line 1 extended permit tcp any any eq www (hitcnt=0) 0xc56dc15e
access-list TEST line 1 extended permit tcp any any eq https (hitcnt=0) 0x702064c1
access-list TEST line 2 extended permit object-group admin-2 any any (hitcnt=0) 0xd42bcde9
access-list TEST line 2 extended permit tcp any any eq www (hitcnt=0) 0xc56dc15e
access-list TEST line 2 extended permit tcp any any eq https (hitcnt=0) 0x702064c1
So the end result in the actual ACL is the same but the configuration format a bit different. I think the option to group all different protocols and ports under a single "object-group" would give a lot more flexibility to make rules. You wouldnt be limited to grouping together just TCP Ports but could combine UDP and ICMP for example.
As you can see the "object-group" you used before is just meant to group together certain TCP Ports and use them at the end of the ACL to tell the ports that need to be opened.
With the new "object-group" configuration option you would actually write "permit object-group admin" instead of "permit tcp". The "object-group" would actually tell what protocol is allowed and what ports belonging to it (if applicable).
So you are free to choose which one to use.
Hope this helps