Thanks guys.
How can I prevent the remote users from going to the internet through the
tunnel, instead use their own internet connection at the remote location?
I've tried different settings and only one way works but in that i can trace
route to the website but can't browse.
regards,
haroon
On Wed, Oct 7, 2009 at 2:49 PM, Tony Varriale <tvarriale_at_flamboyaninc.com>wrote:
> Enable IPSec over udp...sounds like everything else is there. If your
> client is behind nat that will help.
>
> Sent from my iPhone
>
>
> On Oct 7, 2009, at 12:36 PM, Haroon <itguy.pro_at_gmail.com> wrote:
>
> Ryan,
>>
>> Thanks. Screenshots coming up... I do see this on the client:
>>
>> The IP address assigned by the DHCP server... of local LAN I am trying to
>> reach (internal side of concentrator)
>>
>> Transparent Tunneling: Inactive
>> Local LAN: Disabled
>>
>> On the client, Transport Tab, I have:
>> Enabled Transparent Tunneling:
>> IPSec over UDP (NAT / PAT)
>>
>> Allow Local LAN access checked.
>>
>> Only seeing sent traffic stats increasing... I see the connection on the
>> concentrator sessions but no traffic stats.
>>
>> Event log on concentrator:
>> 47380 10/07/2009 13:32:07.340 SEV=7 IKEDBG/27 RPT=57 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> IPSec SA Proposal # 11, Transform # 1 acceptable
>> Matches global IPSec SA entry # 2 Proposal (ESP-3DES-MD5)
>> 47383 10/07/2009 13:32:07.340 SEV=7 IKEDBG/85 RPT=57 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> IKE: requesting SPI! (Protocol=ESP)
>> 47384 10/07/2009 13:32:07.340 SEV=8 IKEDBG/6 RPT=1619 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> IKE got SPI from key engine: SPI = 0x476c2ccb
>> 47385 10/07/2009 13:32:07.340 SEV=9 IKEDBG/0 RPT=21172 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> oakley constucting quick mode
>> 47386 10/07/2009 13:32:07.340 SEV=9 IKEDBG/0 RPT=21173 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> constructing blank hash
>> 47387 10/07/2009 13:32:07.340 SEV=9 IKEDBG/0 RPT=21174 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> constructing ISA_SA for ipsec
>> 47388 10/07/2009 13:32:07.340 SEV=5 IKE/75 RPT=10 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> Overriding Initiator's IPSec rekeying duration from 2147483 to 28800
>> seconds
>> 47390 10/07/2009 13:32:07.340 SEV=9 IKEDBG/1 RPT=31905 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> constructing ipsec nonce payload
>> 47391 10/07/2009 13:32:07.340 SEV=9 IKEDBG/1 RPT=31906 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> constructing proxy ID
>> 47392 10/07/2009 13:32:07.340 SEV=7 IKEDBG/91 RPT=1619 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> Transmitting Proxy Id:
>> Remote host: 192.168.1.160 Protocol 0 Port 0
>> Local subnet: 0.0.0.0 mask 0.0.0.0 Protocol 0 Port 0
>> 47396 10/07/2009 13:32:07.340 SEV=7 IKEDBG/92 RPT=10 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> Sending RESPONDER LIFETIME notification to Initiator
>> 47398 10/07/2009 13:32:07.340 SEV=9 IKEDBG/0 RPT=21175 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> constructing qm hash
>> 47399 10/07/2009 13:32:07.340 SEV=8 IKEDBG/81 RPT=59724 71.1.1.1
>> SENDING Message (msgid=b8e14cb1) with payloads :
>> HDR + HASH (8) + SA (1)
>> total length : 176
>> 47401 10/07/2009 13:32:07.540 SEV=8 IKEDBG/81 RPT=59725 71.1.1.1
>> RECEIVED Message (msgid=b8e14cb1) with payloads :
>> HDR + HASH (8) + NONE (0)
>> total length : 48
>> 47403 10/07/2009 13:32:07.540 SEV=9 IKEDBG/0 RPT=21176 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> processing hash
>> 47404 10/07/2009 13:32:07.540 SEV=9 IKEDBG/0 RPT=21177 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> loading all IPSEC SAs
>> 47405 10/07/2009 13:32:07.540 SEV=9 IKEDBG/1 RPT=31907 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> Generating Quick Mode Key!
>> 47406 10/07/2009 13:32:07.540 SEV=9 IKEDBG/1 RPT=31908 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> Generating Quick Mode Key!
>> 47407 10/07/2009 13:32:07.540 SEV=7 IKEDBG/93 RPT=1594 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> Loading subnet:
>> Dst: 0.0.0.0 mask: 0.0.0.0
>> Src: 192.168.1.160:0
>> 47409 10/07/2009 13:32:07.540 SEV=4 IKE/49 RPT=1594 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> Security negotiation complete for User (UserName)
>> Responder, Inbound SPI = 0x476c2ccb, Outbound SPI = 0x377e408a
>> 47412 10/07/2009 13:32:07.540 SEV=8 IKEDBG/7 RPT=1594
>> IKE got a KEY_ADD msg for SA: SPI = 0x377e408a
>> 47413 10/07/2009 13:32:07.540 SEV=8 IKEDBG/86 RPT=1594 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> pitcher: rcv KEY_UPDATE, spi 0x476c2ccb
>> 47414 10/07/2009 13:32:07.540 SEV=4 IKE/120 RPT=1594 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> PHASE 2 COMPLETED (msgid=b8e14cb1)
>> 47415 10/07/2009 13:32:07.540 SEV=4 NAC/27 RPT=10
>> NAC is disabled for peer - PUB_IP:71.1.1.1, PRV_IP:192.168.1.160
>> 47416 10/07/2009 13:32:31.460 SEV=8 IKEDBG/81 RPT=59726 71.1.1.1
>> RECEIVED Message (msgid=57cfea03) with payloads :
>> HDR + HASH (8) + NOTIFY (11) + NONE (0)
>> total length : 80
>> 47418 10/07/2009 13:32:31.460 SEV=9 IKEDBG/0 RPT=21178 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> processing hash
>> 47419 10/07/2009 13:32:31.460 SEV=9 IKEDBG/0 RPT=21179 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> Processing Notify payload
>> 47420 10/07/2009 13:32:31.460 SEV=9 IKEDBG/36 RPT=18603 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> Sending keep-alive of type DPD R-U-THERE-ACK (seq number 0xe4f69d21)
>> 47422 10/07/2009 13:32:31.460 SEV=9 IKEDBG/0 RPT=21180 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> constructing blank hash
>> 47423 10/07/2009 13:32:31.460 SEV=9 IKEDBG/0 RPT=21181 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> constructing qm hash
>> 47424 10/07/2009 13:32:31.460 SEV=8 IKEDBG/81 RPT=59727 71.1.1.1
>> SENDING Message (msgid=1534da32) with payloads :
>> HDR + HASH (8) + NOTIFY (11)
>> total length : 80
>> 47426 10/07/2009 13:32:41.890 SEV=8 IKEDBG/81 RPT=59728 71.1.1.1
>> RECEIVED Message (msgid=f71b87d3) with payloads :
>> HDR + HASH (8) + NOTIFY (11) + NONE (0)
>> total length : 80
>> 47428 10/07/2009 13:32:41.890 SEV=9 IKEDBG/0 RPT=21182 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> processing hash
>> 47429 10/07/2009 13:32:41.890 SEV=9 IKEDBG/0 RPT=21183 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> Processing Notify payload
>> 47430 10/07/2009 13:32:41.890 SEV=9 IKEDBG/36 RPT=18604 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> Sending keep-alive of type DPD R-U-THERE-ACK (seq number 0xe4f69d22)
>> 47432 10/07/2009 13:32:41.890 SEV=9 IKEDBG/0 RPT=21184 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> constructing blank hash
>> 47433 10/07/2009 13:32:41.890 SEV=9 IKEDBG/0 RPT=21185 71.1.1.1
>> Group [IPSecGroup] User [UserName]
>> constructing qm hash
>> 47434 10/07/2009 13:32:41.890 SEV=8 IKEDBG/81 RPT=59729 71.1.1.1
>> SENDING Message (msgid=93d2ffe7) with payloads :
>> HDR + HASH (8) + NOTIFY (11)
>> total length : 80
>>
>> thanks,
>>
>> Haroon
>>
>> On Wed, Oct 7, 2009 at 12:53 PM, Ryan West <rwest_at_zyedge.com> wrote:
>>
>> Haroon,
>>>
>>>
>>>
>>> I can t comment much on the pptp connection, but with the VPN client,
>>> what
>>> are you seeing in the statistics and secured routes page? How about on
>>> the
>>> concentrator, you should see some client statistics there that would
>>> indicate if you re seeing two-way traffic. Basically I think you should
>>> check out the logs some more.
>>>
>>>
>>>
>>> -ryan
>>>
>>>
>>>
>>> *From:* Haroon [mailto:itguy.pro_at_gmail.com]
>>> *Sent:* Wednesday, October 07, 2009 12:23 PM
>>> *To:* Ryan West
>>> *Cc:* Cisco certification
>>> *Subject:* Re: VPN Concentrator with VPN Clients
>>>
>>>
>>>
>>> Hi Ryan,
>>>
>>>
>>>
>>> Thanks. The concentrator has one interface in the internal LAN
>>> (192.168.1.5) and other one is public... I did try different subnet pool
>>> on
>>> the concentrator and statically route from the internal LAN gateway
>>> (192.168.1.1) to concentrator and back but that didn't work either.
>>>
>>>
>>>
>>> I even tried adding static routes on windows XP machine that I am using
>>> to
>>> test, still nothing.
>>>
>>>
>>>
>>> regards,
>>>
>>>
>>>
>>> haroon
>>>
>>> On Wed, Oct 7, 2009 at 12:02 PM, Ryan West <rwest_at_zyedge.com> wrote:
>>>
>>> Haroon,
>>>
>>> The concentrator usually does RRI. I wasn't really sure, but you did say
>>> that you tried assigning a local pool and statically routing that network
>>> from your router to your concentrator? If the concentrator is on a
>>> logically separate network than what your DHCP is assigning and that
>>>
>> network
>>
>>> is local to the router or the clients, you can see the routing issue
>>> there.
>>> If you want to use it in that manner, the concentrator would need to sit
>>>
>> on
>>
>>> your internal network.
>>>
>>> -ryan
>>>
>>> -----Original Message-----
>>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
>>> Haroon
>>> Sent: Wednesday, October 07, 2009 11:56 AM
>>> To: Cisco certification
>>> Subject: OT: VPN Concentrator with VPN Clients
>>>
>>> Hello Experts,
>>>
>>> Sorry about back to back OT posts but maybe I am too dumb for this crap
>>> and
>>> someone can help me with this.... I am trying to configure CVPN 3030
>>> Concentrator to work with either Microsoft vpn client or Cisco VPN client
>>> 5.0.03.
>>>
>>> I have configured two groups: 1) pptp to work with MS and 2) IPSecGroup
>>> to
>>> work with the cisco vpn client. I cannot make any connection with ms vpn
>>> client, however, I am able to authenticate with active directory and get
>>> an
>>> ip address from our internal dhcp server when I use cisco vpn client(ip
>>> sec
>>> group). After the connection is established, I cannot ping or browse any
>>> servers behind the concentrator. I even tried different subnet dhcp range
>>> and adding static routes on the concentrator and router behind it (local
>>> LAN) but no go.
>>>
>>> I have tried following the cisco documents to the last letter, google
>>> search
>>> and I tried configuring it using my own understanding of this but no
>>> luck.
>>> Is there some setting that I am missing in the concentrator? I don't care
>>> which client I use (MS preferred) as long as concentrator can
>>> intelligently
>>> pass traffic through to the other side as it is with the 4 site to site
>>> VPNs.
>>>
>>> regards,
>>>
>>> Haroon
>>>
>>>
>>> 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
>>
>> _______________________________________________________________________
>>
>
>
> Subscription information may be found at:
>> 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
Blogs and organic groups at http://www.ccie.net
Received on Wed Oct 07 2009 - 16:29:55 ART
This archive was generated by hypermail 2.2.0 : Sun Nov 01 2009 - 07:50:59 ART