Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Cisco (http://www.velocityreviews.com/forums/f27-cisco.html)
-   -   access-list stops telnet (http://www.velocityreviews.com/forums/t57072-access-list-stops-telnet.html)

Rob 03-22-2006 03:34 PM

access-list stops telnet
 
Hi,
I have a small remote office with 2 office machines(known users) and few
public machines (unknown users), the public machines need Internet only.
This office has a s2s VPN to 10.10.0.0. in order to secure it I am using the
following access-lists: 192.168.104.254 is the remote 501 PIX in that
office.

My problem is that I cannot telnet to this pix from 10.10 network eventhough
I have access-list line 3 in place. Can someone help me.
Thanks-Rob

PIX(config)# sho ru | include 102
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
nat (inside) 0 access-list 102
crypto map xyz 1 match address 102

PIX(config)# sho telnet
10.10.0.0 255.255.0.0 inside
192.168.104.0 255.255.255.0 inside

By the way, if I change accees-lists to "access-list 102 permit ip
192.168.104.0 255.255.255.0 10.10.0.0 255.255.0.0" telnet will work but
thats not what I am looking for because of the security issue.






Walter Roberson 03-22-2006 04:36 PM

Re: access-list stops telnet
 
In article <44216e9e$1@news.sentex.net>, Rob <Rob@hotmail.com> wrote:
>I have a small remote office with 2 office machines(known users) and few
>public machines (unknown users), the public machines need Internet only.
>This office has a s2s VPN to 10.10.0.0. in order to secure it I am using the
>following access-lists: 192.168.104.254 is the remote 501 PIX in that
>office.


>My problem is that I cannot telnet to this pix from 10.10 network even
>though I have access-list line 3 in place.


>PIX(config)# sho ru | include 102
>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
>nat (inside) 0 access-list 102
>crypto map xyz 1 match address 102


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.


>PIX(config)# sho telnet
>10.10.0.0 255.255.0.0 inside
>192.168.104.0 255.255.255.0 inside
>
>By the way, if I change accees-lists to "access-list 102 permit ip
>192.168.104.0 255.255.255.0 10.10.0.0 255.255.0.0" telnet will work but
>thats not what I am looking for because of the security issue.



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.

Rob 03-23-2006 02:50 PM

Re: access-list stops telnet
 

"Walter Roberson" <roberson@hushmail.com> wrote in message
news:e2fUf.170833$sa3.119727@pd7tw1no...
> In article <44216e9e$1@news.sentex.net>, Rob <Rob@hotmail.com> wrote:
> >I have a small remote office with 2 office machines(known users) and few
> >public machines (unknown users), the public machines need Internet only.
> >This office has a s2s VPN to 10.10.0.0. in order to secure it I am using

the
> >following access-lists: 192.168.104.254 is the remote 501 PIX in that
> >office.

>
> >My problem is that I cannot telnet to this pix from 10.10 network even
> >though I have access-list line 3 in place.

>
> >PIX(config)# sho ru | include 102
> >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
> >nat (inside) 0 access-list 102
> >crypto map xyz 1 match address 102

>
> 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.
>
>
> >PIX(config)# sho telnet
> >10.10.0.0 255.255.0.0 inside
> >192.168.104.0 255.255.255.0 inside
> >
> >By the way, if I change accees-lists to "access-list 102 permit ip
> >192.168.104.0 255.255.255.0 10.10.0.0 255.255.0.0" telnet will work but
> >thats not what I am looking for because of the security issue.

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



Walter Roberson 03-23-2006 03:35 PM

Re: access-list stops telnet
 
In article <4422b5ca$1@news.sentex.net>, Rob <Rob@hotmail.com> wrote:

>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?


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.

>and I dont have any access-group at all, because I dont need them.


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 .


>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?


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.

Rob 03-23-2006 04:12 PM

Re: access-list stops telnet
 

"Walter Roberson" <roberson@hushmail.com> wrote in message
news:_ezUf.176653$B94.28150@pd7tw3no...
> In article <4422b5ca$1@news.sentex.net>, Rob <Rob@hotmail.com> wrote:
>
> >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?

>
> 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.
>
> >and I dont have any access-group at all, because I dont need them.

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

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



Walter Roberson 03-23-2006 06:29 PM

Re: access-list stops telnet
 
In article <4422c902$1@news.sentex.net>, Rob <Rob@hotmail.com> wrote:

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


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.

>access-list 102 is only control the encryption between 2 pixes ( we have
>site-2-site VPN) and it doesnt do anything else,


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.

>I dont know why I need another access-list.


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

>Did you get any sense of my config?


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.


All times are GMT. The time now is 12:55 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.