Re: PPTP Site to Site Test VPN will not come up
From: Brian Whiting (nospam_at_deny.com)
Date: 02/24/05
- Next message: Ian: "Re: WINS issue"
- Previous message: Caimbo: "Re: Cant access the Internet using Wless Routing"
- In reply to: Brian Whiting: "Re: PPTP Site to Site Test VPN will not come up"
- Next in thread: Bill Grant: "Re: PPTP Site to Site Test VPN will not come up"
- Reply: Bill Grant: "Re: PPTP Site to Site Test VPN will not come up"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 24 Feb 2005 11:50:02 -0500
Still no joy on the Remote Router 2 connection. I did test the server using
Computer1 as a dial in receiver and Computer2 as a dial in client & it
connected just fine using both PPTP and L2TP/Ipsec. For the site to site I
tried using the 172.16 addresses matching the NICs for the dd interfaces,
then tried unique 172.16 addresses on the dd interfaces with the same
results. I cannot see where the configuration is incorrect though.
"Brian Whiting" <nospam@deny.com> wrote in message
news:OTg7RbnGFHA.2504@TK2MSFTNGP10.phx.gbl...
> I'm confused about the dd interfaces. They use the 192.168.x.x physical
> interfaces on each machine; why would they be addressed as 172.16? Here
> is the virtual setup:
>
> 172.16.1.x (inside) -> 192.168.0.x (public) - 192.168.0.x (public) <-
> 172.16.0.x (inside)
>
> The Microsoft documentation was not clear on what to address the dd
> interfaces as. The default setting is to obtain an address automatically,
> as if the ISP is providing DHCP, which is what led me to believe that the
> addresses should match the physical IP addresses of the two RRAS servers.
>
> I'll try readdressing the interfaces with the inside addresses, both
> matching the inside physical IPs and on the same network but different
> host addresses on different tests, & see what happens.
>
> "Bill Grant" <not.available@online> wrote in message
> news:%23byiaEiGFHA.3472@TK2MSFTNGP09.phx.gbl...
>> I don't know if the IP addresses you gave to the dd interfaces
>> confuses the system, but it certainly confuses me! The dd interfaces are
>> part of the local 172.16. subnet in each site. Why not give them local IP
>> addresses?
>>
>> The failure to connect doesn't seem to be directly associated with any
>> of this. It looks like the server is not properly configured to accept
>> remote access. Have you set the remote access policy to accept remote
>> connections? Have you tested by making a normal client-server type VPN
>> connection to the server? If this fails, what error message do you get?
>>
>> I can assure that a setup like this will work over a LAN. I have done
>> it several times with W2k and W2k3 RRAS servers for testing. (It also
>> works with virtual servers running under Microsoft VPC).
>>
>> "Brian Whiting" <nospam@deny.com> wrote in message
>> news:erxwuUcGFHA.2524@TK2MSFTNGP15.phx.gbl...
>>>I am currently testing a site to site VPN in a virtualized lab setup. I
>>> have two w2k3 enterprise servers, computer1 and computer2, each with two
>>> ethernet adapters:
>>> Computer1 - MyISP 192.168.0.3/24 and Local Area
>>> Connection 2 172.16.0.2/2
>>> Computer2 - Local Area Connection 192.168.0.8/24 and Local Area
>>> Connection 2
>>> 172.16.1.55/24
>>>
>>> The 192.168.0.0/24 network is representing the internet. I created
>>> demand
>>> dial interfaces on each computer named "Remote Router 2". The demand
>>> dial
>>> interface wizard automatically created a user account named Remote
>>> Router 2
>>> and enabled dial-in for the account. There is an existing remote access
>>> policy named "Connections to Other Access Servers" on each computer.
>>> The
>>> only policy condition is a Day and time restriction that grants access
>>> at
>>> all times during all days of the week. In the network properties of
>>> each
>>> demand dial interface I entered:
>>> Computer1 IP address 192.168.0.3
>>> Computer2 IP address 192.168.0.8.
>>> Computer1's Remote Router 2 destination address is 192.168.0.8 and
>>> Computer2's is 192.168.0.3. In the profile section of the Remote Access
>>> Policies I left the default "server settings determine IP address
>>> assignment". There connection is set to persistent on both sides and
>>> there
>>> are no demand dial filters to specify interesting traffic. The
>>> connection
>>> will always be manually started from either of the computers. There is
>>> a
>>> static route in Computer1 to 172.16.1.0/24 via interface Remote Router
>>> 2.
>>> There is a similar one in computer2 to 172.16.0.0/24 via Remote Router
>>> 2.
>>> Each side is set to not require encryption of traffic but to use an
>>> encrypted password. Each time I try to connect I get an error message
>>> saying a connection could not be established & I might need to check
>>> network
>>> settings. The event log shows a successful authentication at the
>>> receiving
>>> server. Then there is an error message saying a remote connection could
>>> not
>>> be established. In the ppp log I can see a successful CHAP challenge
>>> and
>>> response, then a successful CBCP train with an agreement not to use
>>> callback. CCP goes through some apparently successful negotiations.
>>> IPCP
>>> seems to fail though. Here is the IPCP exchange from the ppp log on
>>> computer2 when it initiates the connection:
>>>
>>> [3992] 02-23 10:50:33:145: >PPP packet received at 02/23/2005
>>> 15:50:33:145
>>> [3992] 02-23 10:50:33:145: >Protocol = IPCP, Type = Configure-Req,
>>> Length =
>>> 0xc, Id = 0x5, Port = 6
>>> [3992] 10:50:33:145: >80 21 01 05 00 0A 03 06 C0 A8 00 03 00 00 00 00
>>> |.!..............|
>>> [3992] 02-23 10:50:33:145:
>>> [3992] 02-23 10:50:33:145: <PPP packet sent at 02/23/2005 15:50:33:145
>>> [3992] 02-23 10:50:33:145: <Protocol = LCP, Type = Protocol-Reject,
>>> Length =
>>> 0x12, Id = 0x4, Port = 6
>>> [3992] 10:50:33:145: <C0 21 08 04 00 10 80 21 01 05 00 0A 03 06 C0 A8
>>> |.!.....!........|
>>> [3992] 10:50:33:145: <00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> |................|
>>> [3992] 02-23 10:50:33:145:
>>> [3700] 02-23 10:50:33:145: Packet received (12 bytes) for hPort 6
>>> [3992] 02-23 10:50:33:145: >PPP packet received at 02/23/2005
>>> 15:50:33:145
>>> [3992] 02-23 10:50:33:145: >Protocol = CCP, Type = Configure-Ack, Length
>>> =
>>> 0xc, Id = 0x3, Port = 6
>>> [3992] 10:50:33:145: >80 FD 02 03 00 0A 12 06 01 00 00 01 00 00 00 00
>>> |................|
>>> [3992] 02-23 10:50:33:145:
>>> [3992] 02-23 10:50:33:145: RemoveFromTimerQ called
>>> portid=112,Id=3,Protocol=80fd,EventType=0,fAuth=0
>>> [3992] 02-23 10:50:33:145: FsmThisLayerUp called for protocol = 80fd,
>>> port =
>>> 6
>>> [3992] 02-23 10:50:33:145: RemoveFromTimerQ called
>>> portid=112,Id=0,Protocol=0,EventType=3,fAuth=0
>>> [3992] 02-23 10:50:33:145: NotifyCaller(hPort=6, dwMsgId=4)
>>> [3992] 02-23 10:50:33:145: NotifyCaller(hPort=6, dwMsgId=0)
>>> [3460] 02-23 10:50:33:145: PppStop
>>>
>>> [3460] 02-23 10:50:33:145: PPPEMSG_Stop recvd
>>>
>>> There is only one IPCP packet in the packet capture stream in Network
>>> Monitor. It originates from Computer1, the called computer, and it has
>>> a
>>> request that specifies its own IP address. In the ppp log it's C0 A8 00
>>> 03
>>> which translates to 192.168.0.3. There is no return IPCP message from
>>> Computer2 at all, just the Protocol-Reject.
>>>
>>> Why can't I get the tunnel established?
>>>
>>>
>>>
>>
>>
>
>
- Next message: Ian: "Re: WINS issue"
- Previous message: Caimbo: "Re: Cant access the Internet using Wless Routing"
- In reply to: Brian Whiting: "Re: PPTP Site to Site Test VPN will not come up"
- Next in thread: Bill Grant: "Re: PPTP Site to Site Test VPN will not come up"
- Reply: Bill Grant: "Re: PPTP Site to Site Test VPN will not come up"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
