Re: PPTP Site to Site Test VPN will not come up
From: Bill Grant (not.available_at_online)
Date: 02/25/05
- Next message: asdf: "Off-Site Server Recovery"
- Previous message: David Pendleton: "Re: Lousy Performance"
- In reply to: Brian Whiting: "Re: PPTP Site to Site Test VPN will not come up"
- Next in thread: Brian Whiting: "Re: PPTP Site to Site Test VPN will not come up"
- Reply: Brian Whiting: "Re: PPTP Site to Site Test VPN will not come up"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 25 Feb 2005 11:36:01 +1100
To connect, you must use the "public" IP of the answering router. In your
case, that will be the 192.168.0 address of the server, since that subnet
is emulating the Internet.
You do not need to worry about which interface the VPN actually connects
to. That is done automatically, based on the username of the connection
request.
When a RRAS router receives an incoming connection request, it examines
the username. If this username matches one of its demand-dial interfaces, it
assumes it is a router calling and connects to that interface. When the
interface becomes active, the static routes linked to that interface are
added to the routing table to set up the route back to the calling router's
subnet. If there is no match, it is assumed to be a client-server request.
The connection is made to the default "internal" interface, and only a host
route back to the caller is set up. (You may need to read that a couple of
times, s l o w l y !)
Regarding the IP addresses, it becomes even more confusing, because the
connection also receives an IP address from the answering RRAS server!
"Brian Whiting" <nospam@deny.com> wrote in message
news:ObNKiDpGFHA.2384@TK2MSFTNGP10.phx.gbl...
> 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: asdf: "Off-Site Server Recovery"
- Previous message: David Pendleton: "Re: Lousy Performance"
- In reply to: Brian Whiting: "Re: PPTP Site to Site Test VPN will not come up"
- Next in thread: Brian Whiting: "Re: PPTP Site to Site Test VPN will not come up"
- Reply: Brian Whiting: "Re: PPTP Site to Site Test VPN will not come up"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
