access-list stops telnet

You cannot use the same access-list for both "nat 0 access-list" and "crypto map match address". Don't re-use any ACL for any purpose: there are cases that are certain not to work, and there are lurking PIX bugs in some of the cases that are supposed to work, and it isn't worth tracking down the problems.

You have something very strange going on in your configuration. Rather than tell you all the things that are odd, I'll set out what is needed to be successful:

- If you want to be able to telnet to a remote PIX itself, then you must do so over a VPN: telnet is not permitted to the outside interface of a PIX. However, ssh is permitted to the outside interface of a PIX.

- If you want to telnet *through* a PIX to a device on the inside, then the above restriction does not apply, The restriction is one of security in configuring the PIX itself.

- Over a VPN, you can telnet to the *public* IP of a PIX, or you can create a "management access" VPN on the inside interface of the PIX and telnet to that inside interface.

- The interface access control list (access-group "in" the interface) has no effect on whether the PIX will accept telnet packets addressed to the PIX itself.

- The command that controls the acceptance of telnet *to the PIX itself* is the "telnet" command. If you want your PIX itself to accept telnet from a remote device, then a telnet command with a matching IP address must exist and the interface "outside" must be used. You used 'inside', which is only for accepting -local- telnet addressed to the PIX itself.

- However, the PIX that you are telneting -through- in order to get to the remote PIX, will still be processing the telnet packets through regular security procedures. Thus those packets must be accepted by default (no access-group for the inside interface), or must be accepted by the access-group on the inside interface, or must be exempted from access-group's by there being a "sysopt connection permit-ipsec" active.

- Regular crypto map rules about what traffic will go through the VPN still apply, so unless you do a "management access" VPN, you would need the *public* IP of the remote PIX in the *destination* field of the crypto map, with the source field being the devices that were allowed to initiate that telne. The source field could be in terms either of internal addresses or in terms of the post-NAT address: if you want to use the internal address for the source, then the nat 0 access-list must have a line listing the -public- IP of the remote PIX in the -destination- [unless you go "management access", in which case it would be the -internal- IP]. Which-ever source IP it is you use in the crypto-map must match the remote PIX's "telnet" command.

I have 2 nat nat (inside) 0 access-list 102 nat (inside) 1 0.0.0.0 0.0.0.0 0 0

nat 0 is only for VPN and nat 1 is for others like access to Internet, and I dont know why it is odd to use the encryption (VPN) access-list for crypto map? and I dont have any access-group at all, because I dont need them.

My question was why if I just say access-list 102 permit ip 192.168.104.0

255.255.255.0 10.10.0.0 255.255.0.0 telnet will work and if I change it to

access-list 102 permit ip host 192.168.104.21 10.10.0.0 255.255.0.0 access-list 102 permit ip host 192.168.104.20 10.10.0.0 255.255.0.0 access-list 102 permit ip host 192.168.104.254 10.10.0.0 255.255.0.0

telnet wont work? (254 is pix inside). Any idea? Rob

PIX manipulates access-lists internally for reasons having to do with adaptive security. When you have an ACL doing double-duty it can be manipulated in two different internal ways at the same time, or the way it is manipulated for one purpose can interfere with its other purpose.

Your posting contained inconsistant information, so we cannot tell what you were really asking. In the most plausible interpretations of your information, you *do* want access-group .

It appears to me that you are using PIX 6.x. PIX 6.x does not have any command to allow you to use the PIX -itself- (e.g., the CLI) to telnet to a remote device, so the local PIX itself will never be the *source* of telnet packets.

You reported earlier that 192.168.104.254 was the -outside- IP of the remote PIX (which leads to a pretty strange topology), which would make it the -destination- of telnet, but in access-list 102, you have it appearing in the *source* field.

You reported earlier that 192.168.104.254 was the -outside- IP of the remote PIX, and that 192.168.104.* is the inside IP range of the local PIX. If that were the case, then if you attempted to use any host inside the local PIX to telnet to the remote PIX, then your local host would observe that the destination was in the same subnet as itself was, and would do a local ARP broadcast to try to locate 192.168.104.254, and that ARP is going to fail because the PIX is not going to proxy-ARP for a remote IP. If you happened to have configured the local hosts to have a host-specific route through the local PIX to reach the remote

192.168.104.254 address, then the PIX would observe that the route to the destination IP (192.168.104.254) was -back- through the inside interface (192.168.104/24) and the PIX would immediately drop the packet because PIX 6 is specifically designed to never route packets back through the same [logical] interface they reached the PIX on.

We must deduce that your description of what you want to do has major mistakes, but we cannot deduce what the true configuration is, so we cannot just give you the corrected configuration lines.

I never reported that 192.168.104.254 is *outside*, I thought this would be abvious that 192.168.104.254 is a private IP and it is inside interface of the remote PIX. And 10.10. is the inside network of head office PIX. access-list 102 is only control the encryption between 2 pixes ( we have site-2-site VPN) and it doesnt do anything else, I dont know why I need another access-list. Did you get any sense of my config? Rob

Unfortunately you did not indicate which of the two machines the access-list 102 was for.

If that access-list is supposed to be on the remote PIX (the one with 192.168.104.* as the inside), then there is the problem that you cannot telnet to the -inside- address of a remote PIX -- not unless the VPN has been designated as a "management access" VPN. If, however, it has been designated as a "management access" VPN then the VPN can only be used to communicate from HQ to the remote PIX

*itself*, and you would need a -second- VPN (second "crypto map" policy) to communicate from HQ "past" the remote PIX to the remote network.

Incorrect. You have nat (inside) 0 access-list 102 and that is one use: that uses access-list 102 to determine what IP addresses are to be translated or not. nat 0 access-list is often used -with- a VPN, but it does not have any VPN function.

The determination of which traffic will go over the VPN is by crypto map NAME POLICYNUMBER match address ACCESSLISTNAME and you showed a crypto map match address 102 . That's a -second- use of access-list 102.

If I recall correctly, the Cisco Bugtracker database records at least one PIX bug having to do with using the same access-list for nat 0 and crypto map match address. There were other bugs recorded for other dual uses of access-lists. I haven't checked up on the status of those bugs recently, but considering that they had been known to be present in 5.2, 5.3, 6.1, and 6.2, I would be surprised if Cisco had managed to root all of them out by whatever unnamed version of PIX's OS that you are using.

Because fixing it is a prerequisite for my being of further assistance in your question.

No. The information you have presented is incomplete or contradictory.

I suggest that a) you fix the problem with using access-list 102 twice; and b) you post the configurations of both PIXes (with passwords and preshared keys obscured), clearly labeled as to which is which, and clearly indicating which host you are telneting from and which host you are attempting to telnet to.