«

I have setup PPTP using the PIX 506e.

I can connect to the PIX no problem via PPTP, and I get an IP address. But I
cannot access anything in the LAN when I'm connected.

Any Idea's?

In article <z4KJe.212189$on1.208824@clgrps13>,
Travis <> wrote:
:I have setup PPTP using the PIX 506e.

:I can connect to the PIX no problem via PPTP, and I get an IP address. But I
:cannot access anything in the LAN when I'm connected.

Insufficient information.

Have you used a sysopt connection command to bypass ACL checking?
If not have you constructed appropriate ACL entries on your outside
interface?

What syslog messages are coming through?
--
Entropy is the logarithm of probability -- Boltzmann

I have done none of that, I'm some what new to cisco products.

I have the fixup for pptp setup.

What else should I be setting up?..., command wise.


"Walter Roberson" <> wrote in message
news:dd839v$k9g$...
> In article <z4KJe.212189$on1.208824@clgrps13>,
> Travis <> wrote:
> :I have setup PPTP using the PIX 506e.
>
> :I can connect to the PIX no problem via PPTP, and I get an IP address.
> But I
> :cannot access anything in the LAN when I'm connected.
>
> Insufficient information.
>
> Have you used a sysopt connection command to bypass ACL checking?
> If not have you constructed appropriate ACL entries on your outside
> interface?
>
> What syslog messages are coming through?
> --
> Entropy is the logarithm of probability -- Boltzmann

In article <w%MJe.191247$tt5.98119@edtnps90>, Travis <> top-posted:
:> Have you used a sysopt connection command to bypass ACL checking?
:> If not have you constructed appropriate ACL entries on your outside
:> interface?
:> What syslog messages are coming through?

:I have done none of that, I'm some what new to cisco products.
:I have the fixup for pptp setup.

:What else should I be setting up?..., command wise.

If you want your pptp users to bypass security checks:

sysopt connectipn permit-pptp

If you do NOT want your pptp-users to bypass security checks,
then you need to construct an ACL applied to your outside interface.
show access-group
and see if there is one marked 'in interface outside': if so then
the name after the word 'access-group' is the name of the existing ACL
that you would have to add to.

To determine which IPs need to be listed as the sources in the ACL entries,
you need to show vpngroup and look for an entry with the word
address-pool in it. If so, then that will be followed by a pool name.
show ip local pool followed by the pool name, in order to see which
IPs will be temporarily assigned to the pptp clients. Note that the
pool IPs MUST NOT be part of the "inside" interface address range -- that's
a common mistake that it is important to fix.

ip local pool mypool 10.0.0.10-10.0.0.20
object-group network pptp-pool
network-object 10.0.0.10 255.255.255.254
network-object 10.0.0.12 255.255.255.252
network-object 10.0.0.16 255.255.255.252
network-object host 10.0.0.20

To determine which IPs need to be listed as the destination in the ACL
entries, you need to show nat
and see if there is one similar to nat (inside) 0 access-list ACLNAME

If so, then show access-list ACLNAME and see if your pptp addresses
appear in the -destination- fields. If they *do*, then when you are
constructing the outside ACL for the access-group, the local IP
addresses must appear unchanged in the -destination- fields of the ACL entries.

access-list out2in permit ip object-group pptp-pool host 192.168.0.17
access-group out2in in interface outside

If, however, you do not have a nat 0 access-list that lists the pptp
addresses, then the access-list has to have the -external- versions
of the IPs, as determined by looking at show static

static (inside,outside) 80.81.82.83 192.168.0.17 netmask 255.255.255.255
access-list out2in permit ip object-group pptp-pool host 80.81.82.83
access-group out2in in interface outside

If you don't have any relevant nat 0 access-list, and you don't have
any relevant static, and you don't use the sysopt connection command,
then your pptp hosts will not be able to initiate connections inwards
to your machines. Based on your response, I suspect you might not have
any static's set up.


People often turn on the sysopt connection permit-pptp in order to
get the VPN basically working first. A fair number of people leave it
turned on, but it is better security practice to turn off the sysopt
and use explicit ACL entries. Typically if you control both end
networks then you would use nat 0 access-list and then use internal
IP addresses for both sides, but if you do not control the remote
network then you would tend to use nat between you and it.
--
'The short version of what Walter said is "You have asked a question
which has no useful answer, please reconsider the nature of the
problem you wish to solve".' -- Tony Mantler

I'm trying to understand what your telling me, but some info I don't
understand.

I turned my error logging on and it gave me this.

05 13:16:45 305005: No translation group found for udp src
outside:10.0.0.10/137 dst inside:192.168.111.101/137

The 10.0.0.10 is the first address in my pptp pool I setup on the pix. The
192.168.111.101 is my DNS server on the inside of the PIX network.

Any idea's?...,

"Walter Roberson" <> wrote in message
news:dd87iv$pgn$...
> In article <w%MJe.191247$tt5.98119@edtnps90>, Travis <>
> top-posted:
> :> Have you used a sysopt connection command to bypass ACL checking?
> :> If not have you constructed appropriate ACL entries on your outside
> :> interface?
> :> What syslog messages are coming through?
>
> :I have done none of that, I'm some what new to cisco products.
> :I have the fixup for pptp setup.
>
> :What else should I be setting up?..., command wise.
>
> If you want your pptp users to bypass security checks:
>
> sysopt connectipn permit-pptp
>
> If you do NOT want your pptp-users to bypass security checks,
> then you need to construct an ACL applied to your outside interface.
> show access-group
> and see if there is one marked 'in interface outside': if so then
> the name after the word 'access-group' is the name of the existing ACL
> that you would have to add to.
>
> To determine which IPs need to be listed as the sources in the ACL
> entries,
> you need to show vpngroup and look for an entry with the word
> address-pool in it. If so, then that will be followed by a pool name.
> show ip local pool followed by the pool name, in order to see which
> IPs will be temporarily assigned to the pptp clients. Note that the
> pool IPs MUST NOT be part of the "inside" interface address range --
> that's
> a common mistake that it is important to fix.
>
> ip local pool mypool 10.0.0.10-10.0.0.20
> object-group network pptp-pool
> network-object 10.0.0.10 255.255.255.254
> network-object 10.0.0.12 255.255.255.252
> network-object 10.0.0.16 255.255.255.252
> network-object host 10.0.0.20
>
> To determine which IPs need to be listed as the destination in the ACL
> entries, you need to show nat
> and see if there is one similar to nat (inside) 0 access-list ACLNAME
>
> If so, then show access-list ACLNAME and see if your pptp addresses
> appear in the -destination- fields. If they *do*, then when you are
> constructing the outside ACL for the access-group, the local IP
> addresses must appear unchanged in the -destination- fields of the ACL
> entries.
>
> access-list out2in permit ip object-group pptp-pool host 192.168.0.17
> access-group out2in in interface outside
>
> If, however, you do not have a nat 0 access-list that lists the pptp
> addresses, then the access-list has to have the -external- versions
> of the IPs, as determined by looking at show static
>
> static (inside,outside) 80.81.82.83 192.168.0.17 netmask 255.255.255.255
> access-list out2in permit ip object-group pptp-pool host 80.81.82.83
> access-group out2in in interface outside
>
> If you don't have any relevant nat 0 access-list, and you don't have
> any relevant static, and you don't use the sysopt connection command,
> then your pptp hosts will not be able to initiate connections inwards
> to your machines. Based on your response, I suspect you might not have
> any static's set up.
>
>
> People often turn on the sysopt connection permit-pptp in order to
> get the VPN basically working first. A fair number of people leave it
> turned on, but it is better security practice to turn off the sysopt
> and use explicit ACL entries. Typically if you control both end
> networks then you would use nat 0 access-list and then use internal
> IP addresses for both sides, but if you do not control the remote
> network then you would tend to use nat between you and it.
> --
> 'The short version of what Walter said is "You have asked a question
> which has no useful answer, please reconsider the nature of the
> problem you wish to solve".' -- Tony Mantler

In article <mjOJe.191314$tt5.75678@edtnps90>, Travis <> wrote:
:I turned my error logging on and it gave me this.

:05 13:16:45 305005: No translation group found for udp src
utside:10.0.0.10/137 dst inside:192.168.111.101/137

:The 10.0.0.10 is the first address in my pptp pool I setup on the pix. The
:192.168.111.101 is my DNS server on the inside of the PIX network.

:Any idea's?...,

You haven't set up nat 0 access-list nor static
so when the PPTP packets reach your interface and are decapsulated,
the PIX doesn't know where 192.168.111.101 is. The PIX outside
interface only knows about your inside IP addresses if you
nat 0 access-list or static the IPs.
--
Ceci, ce n'est pas une idée.

Ok.

So what do I enter into my PIX to make this work?


"Walter Roberson" <> wrote in message
news:dd8eq9$5ef$...
> In article <mjOJe.191314$tt5.75678@edtnps90>, Travis <>
> wrote:
> :I turned my error logging on and it gave me this.
>
> :05 13:16:45 305005: No translation group found for udp src
> utside:10.0.0.10/137 dst inside:192.168.111.101/137
>
> :The 10.0.0.10 is the first address in my pptp pool I setup on the pix.
> The
> :192.168.111.101 is my DNS server on the inside of the PIX network.
>
> :Any idea's?...,
>
> You haven't set up nat 0 access-list nor static
> so when the PPTP packets reach your interface and are decapsulated,
> the PIX doesn't know where 192.168.111.101 is. The PIX outside
> interface only knows about your inside IP addresses if you
> nat 0 access-list or static the IPs.
> --
> Ceci, ce n'est pas une idée.

access-group out2in in interface outside
access-list out2in permit udp object-group pptp_pool_ips object-group pptp_destinations eq 137
access-list out2in permit tcp object-group pptp_pool_ips object-group pptp_destinations eq www

nat (inside) 0 access-list nonat_acl
access-list nonat_acl permit ip object-group pptp_destinations object-group pptp_pool_ips

network-object host 10.0.0.10
network-object host 10.0.0.11
network-object host 10.0.0.12
object-group network pptp_pool_ips

network-object host 192.168.111.101
network-object host 192.168.111.93
network-object host 192.168.111.116
object-group network pptp_destinations

In article <IbPJe.191507$tt5.165579@edtnps90>,
Travis <> wrote:

:So what do I enter into my PIX to make this work?

:> In article <mjOJe.191314$tt5.75678@edtnps90>, Travis <>
:> wrote:

:> :05 13:16:45 305005: No translation group found for udp src
:> utside:10.0.0.10/137 dst inside:192.168.111.101/137

:> :The 10.0.0.10 is the first address in my pptp pool I setup on the pix.
:> The
:> :192.168.111.101 is my DNS server on the inside of the PIX network.
--
This signature intentionally left... Oh, darn!

I'm just about to enter this into my pix. I just had one question.

any reason why you have 3 ramdom addresses listed for 2 diff networks?

"Walter Roberson" <> wrote in message
news:dd9cob$dti$...
> access-group out2in in interface outside
> access-list out2in permit udp object-group pptp_pool_ips object-group
> pptp_destinations eq 137
> access-list out2in permit tcp object-group pptp_pool_ips object-group
> pptp_destinations eq www
>
> nat (inside) 0 access-list nonat_acl
> access-list nonat_acl permit ip object-group pptp_destinations
> object-group pptp_pool_ips
>
> network-object host 10.0.0.10
> network-object host 10.0.0.11
> network-object host 10.0.0.12
> object-group network pptp_pool_ips
>
> network-object host 192.168.111.101
> network-object host 192.168.111.93
> network-object host 192.168.111.116
> object-group network pptp_destinations
>
> In article <IbPJe.191507$tt5.165579@edtnps90>,
> Travis <> wrote:
>
> :So what do I enter into my PIX to make this work?
>
> :> In article <mjOJe.191314$tt5.75678@edtnps90>, Travis
> <>
> :> wrote:
>
> :> :05 13:16:45 305005: No translation group found for udp src
> :> utside:10.0.0.10/137 dst inside:192.168.111.101/137
>
> :> :The 10.0.0.10 is the first address in my pptp pool I setup on the pix.
> :> The
> :> :192.168.111.101 is my DNS server on the inside of the PIX network.
> --
> This signature intentionally left... Oh, darn!

In article <HQ2Ke.194074$tt5.160111@edtnps90>,
Travis <> wrote:
:I'm just about to enter this into my pix. I just had one question.

:any reason why you have 3 ramdom addresses listed for 2 diff networks?

Typing more than 3 for an example gets tiresome.
The pptp_pool_ips object should list all of your PPTP pool IPs,
and the pptp_destinations object should list all internal hosts that your
PPTP users are allowed to communicate with.
--
"I will speculate that [...] applications [...] could actually see a
performance boost for most users by going dual-core [...] because it
is running the adware and spyware that [...] are otherwise slowing
down the single CPU that user has today" -- Herb Sutter