In article , wrote: :On a Cisco PIX 525 if I say :-
:access-list t1 permit ip hosta hostb : OR :access-list t2 permit ip any hostb
:This means that I'm allowing all IP traffic from HostA or "any" through :to HostB.
Both would be syntax errors on the PIX ;-)
access-list t1 permit ip host HostA host HostB access-list t2 permit ip any host HostB
:Heres the doubt...
:What exactly do I mean by IP traffic??
:1) Does it mean that it includes all protocols working at the IP level :including ICMP , IGRP and a few more??
Yes.
:OR
:2) Does it simply mean allowing all traffic originating from Host A :which uses the IP protocol ; of which TCP is also a part? (This means :I'm allowing practically all connections from Host A to Host B)
Same thing. TCP and UDP are protocols at the same level as ICMP, ESP, GRE, and so on. As a small matter of semantics, though, note that UDP and most other kinds of traffic does not have "connections" as such.
:OR
:3) Does it mean that all traffic which has the IP address of Host A is :allowed to get to Host B ? (This sounds ridiculous...)
If the packet isn't in IP format, then it doesn't have an IP address. So again this comes out as the same thing as the above two.
An example of something which is *not* IP would be IPX or Appletalk.
There is one thing I should say, though, and that even if you permit "ip", that TCP and ICMP and a few other protocols will always have their state tracked. Whether you "permit tcp" or "permit ip", if the packet is a TCP packet, the rule will only affect -new- connections (those in SYN state without an ACK); after the TCP connection is successfully negotiated (sequence number exchange) then it is the active connection table that governs whether further packets in that specific flow are permitted; that connection table will be examined before the ruleset is examined.
If a TCP packet should happen along which has ACK or SYN ACK and there is no entry for that flow in the connection table, then that packet will be dropped no matter what the rules say, because that packet is attempting to violate the stateful protections that the PIX maintains.
Thus, permitting "ip" is -not- really the same as saying "all traffic" is permitted... traffic that violates state rules that the PIX knows about will be dropped before hitting the rules.
:--->If its 1 then do I have to keep writing rules for each protocol I :want to use?eg. If i want to initiate a connection btw Host A and B I :have to write :-
: access-list t1 permit ip hosta hostb (To permit usage of IP :Protocol) : access-list t1 permit tcp hosta hostb eq 23 (To permit usage of TCP :Protocol : for telnet purposes)
No, it scans from top to bottom, and as soon as there is a match it takes the action (permit or deny) of the corresponding line. If it scans down and matches on the general characteristic of being an IP packet, then it gets through before looking at any line further on.
:--->If its 2 which looks likely
: Will only this suffice? : access-list t1 permit tcp hosta hostb eq 23 and also allow IP in the :process?
TCP is a subset of IP. That line (if put into the proper syntax) would permit IP packets with using the TCP protocol that had a source of HostA to initiate connections to destination HostB provided the destination port was 23.
: and does this have any value at all incase the TCP rule is present? : access-list t1 permit ip hosta hostb
If that second rule is above the TCP one, the TCP one would never be examined, as outlined above. If the second rule were below the TCP one, then tcp 23 would be allowed through by the first, and the second would allow the remaining kinds of IP.
Does the general rule after a specific rule "have any value" ? Yes in a few cases: a) you have different 'log' or 'level' modifiers for the different cases; b) you want the different cases to register differently in the hitcounts when you "show access-list" c) you are in the process of developing your ACLs and you have identified the subset that you think you need (or you've gotten of doing so and want to get some live testing in, or your bosses are after you to get the device up...), but you know or suspect there might be some cases you missed, that you don't want to deny until you have finished your rule build-up.