Re: ASA dial in VPN policies

DAP?

Regards,
 Joe Sanchez

On Jun 15, 2012, at 12:01 AM, Mahmoud Genidy <ccie.mahmoud_at_gmail.com> wrote:

> Thanks you all guys ,,,
>
> It is clear that the required effort is not justifiable to secure remote
> VPN hosts based on their source address with ASAs, although it is possible
> with work arounds.
>
> Cheers
> Mahmoud
>
> On Wed, Jun 13, 2012 at 7:30 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar>wrote:
>
>> I have not even tried, but wouldn't it work to use a policy on an ACS (5)
>> to do the trick ?
>> After reading some, it seems this is preciselly the type of question that
>> the new ACS policy based configuration tries to address.
>>
>> -Carlos
>>
>> Joseph L. Brunner @ 13/06/2012 01:10 -0300 dixit:
>>
>>> Mahmoud,
>>>
>>> It sounds more and more like a cisco asa vpn is not the right solution
>>> for your client.
>>>
>>> Consider Citrix Xenapp or similar.
>>>
>>> I think your client is trying to solve a human resources problem with
>>> technology. This is where I seek out his boss and confirm that person's
>>> mission.
>>>
>>> -Joe
>>>
>>>
>>> From: marc abel [mailto:marcabel_at_gmail.com]
>>> Sent: Tuesday, June 12, 2012 11:23 PM
>>> To: Mahmoud Genidy <ccie.mahmoud_at_gmail.com>
>>> Cc: Joseph L. Brunner; Cisco certification <ccielab_at_groupstudy.com>
>>> Subject: Re: ASA dial in VPN policies
>>>
>>> You can only establish remote access VPN connections on the primary
>>> interface which has the default route so I don't believe this will work.
>>>
>>> You can not control who can access the ASA via IPSEC by using an
>>> access-list. You would have to apply that to the control plane and that
>>> would affect all VPN groups.
>>>
>>> You can apply an access-list to restrict which resources people can
>>> access once they successfully connect, but to do this you either have to
>>> use vpn filter or specify the "no sysopt connection permit-vpn" which turns
>>> of the bypassing of access-list for the VPN.
>>>
>>> In your case I think the best you are going to do is use a group password
>>> and user authentication rather than a certificate. It wont restrict which
>>> IP they connect from however.
>>>
>>> -Marc
>>>
>>> On Tue, Jun 12, 2012 at 7:47 PM, Mahmoud Genidy <ccie.mahmoud_at_gmail.com<*
>>> *mailto:ccie.mahmoud_at_gmail.com>**> wrote:
>>> Thanks Joseph
>>>
>>> Knowing it is an option configurable with Fortigate I thought there may be
>>> an equivlent in ASA.
>>>
>>> I couldn't undersand your point when you said it is not possible then you
>>> said it can be done using "isakmp profile match identity address"?
>>>
>>> I thought about some alternative solution: To create a second external
>>> outside interface on the ASA and apply ACL on the internet router
>>> connected
>>> to this interface to restrict the VPN access. Another option would be to
>>> apply the ACL on the outside interface its self however I doubt it will
>>> work!
>>>
>>>
>>> On Tue, Jun 12, 2012 at 4:12 PM, Joseph L. Brunner
>>> <joe_at_affirmedsystems.com<**mailto:joe_at_affirmedsystems.com**>>wrote:
>>>
>>> Not possible... practically speaking.. people move around a lot, etc.
>>>>
>>>> If you knew their ip was going to always be X - say you had some
>>>> consultants that only use the vpn from a major site, etc. then it could
>>>> be
>>>> done with isakmp profiles matching "isakmp profile match identity
>>>> address"
>>>> and the like - but remember, we are architects and designers more than we
>>>> are "errand boys" at our level...
>>>>
>>>> Just because some business person has a vision of Acid Burn and Crash
>>>> Override sitting at their Toshiba Tecra's and some neon characters going
>>>> by
>>>> in the background doesn't mean IT works that way...
>>>>
>>>> What works for most must for all :0)
>>>>
>>>> That's how I support it!
>>>>
>>>> -----Original Message-----
>>>> From: nobody_at_groupstudy.com<mailto:n**obody_at_groupstudy.com<nobody_at_groupstudy.com>>
>>>> [mailto:nobody_at_groupstudy.com<**mailto:nobody_at_groupstudy.com>] On
>>>> Behalf Of
>>>> Mahmoud Genidy
>>>> Sent: Tuesday, June 12, 2012 1:51 AM
>>>> To: Cisco certification
>>>> Subject: Re: ASA dial in VPN policies
>>>>
>>>> Let me rephrase the question:
>>>>
>>>> How to restrict remote access VPN users based on their source (Reall) IP
>>>> address in ASA firewall?
>>>>
>>>>
>>>> On Tue, Jun 12, 2012 at 3:17 PM, Joseph L. Brunner
>>>> <joe_at_affirmedsystems.com<**mailto:joe_at_affirmedsystems.com**>>wrote:
>>>>
>>>> This is done in the real world by giving out two vpn groups... not by
>>>>> tweaking little things behind the scenes for the one group...
>>>>>
>>>>> There are other things you probably need to do with your time/life
>>>>> than this...
>>>>>
>>>>> Two groups...
>>>>>
>>>>> -----Original Message-----
>>>>> From: nobody_at_groupstudy.com<mailto:n**obody_at_groupstudy.com<nobody_at_groupstudy.com>>
>>>>> [mailto:nobody_at_groupstudy.com<**mailto:nobody_at_groupstudy.com>] On
>>>>> Behalf
>>>>> Of Mahmoud Genidy
>>>>> Sent: Monday, June 11, 2012 9:31 PM
>>>>> To: Cisco certification
>>>>> Subject: ASA dial in VPN policies
>>>>>
>>>>> Hi Team,
>>>>>
>>>>> Is it possible to have the ASA configured for two different dial in
>>>>> VPN access policies as follows:
>>>>>
>>>>> - - First group of remote dial in VPN users are active
>>>>> directory
>>>>> authenticated and restricted with private certificate
>>>>>
>>>>> - - Second group of remote dial in VPN users are active
>>>>> directory
>>>>> authenticated and restricted based on their source real IP address
>>>>>
>>>>>
>>>>>
>>>>> What may be the options for implementation, and would this require the
>>>>> two groups of users to dial into two different external ASA IP address?
>>>>>
>>>>>
>>>>>
>>>>> The story behind this is that the customer has implemented a Private
>>>>> Certificate as part of remote dial in VPN access authentication. They
>>>>> have some of their remote users not happy with this option as it
>>>>> restricts remote access to specific PC or Laptop where the certificate
>>>>>
>>>> is installed.
>>>>
>>>>> However they need flexibility of connecting from any PC within their
>>>>> remote small office/home where they connect through a gateway with a
>>>>> fixed Real-IP address. So for this group of users they need to
>>>>> implement another policy where they can have access restriction based
>>>>> on their source real IP address. Other users who already happy with
>>>>> the private certificate will stay the same.
>>>>>
>>>>>
>>>>>
>>>>> Cheers
>>>>>
>>>>> Mahmoud
>>>>> CCIE#23690
>>>>>
>>>>>
>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>
>>>>> ______________________________**______________________________**
>>>>> __________
>>>>> _ Subscription information may be found at:
>>>>> http://www.groupstudy.com/**list/CCIELab.html<http://www.groupstudy.com/list/CCIELab.html>
>>>>>
>>>>
>>>>
>>>> Blogs and organic groups at http://www.ccie.net
>>>>
>>>> ______________________________**______________________________**
>>>> ___________
>>>> Subscription information may be found at:
>>>> http://www.groupstudy.com/**list/CCIELab.html<http://www.groupstudy.com/list/CCIELab.html>
>>>>
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> ______________________________**______________________________**
>>> ___________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/**list/CCIELab.html<http://www.groupstudy.com/list/CCIELab.html>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Marc Abel
>>> CCIE #35470
>>> (Routing and Switching)
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> ______________________________**______________________________**
>>> ___________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/**list/CCIELab.html<http://www.groupstudy.com/list/CCIELab.html>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> --
>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Fri Jun 15 2012 - 06:51:56 ART