PPTP Site to Site Test VPN will not come up

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?

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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>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?
>
>
>

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:%(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>>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?
>>
>>
>>
>
>

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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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:%(E-Mail Removed)...
>> 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" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>>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?
>>>
>>>
>>>
>>
>>
>
>

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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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:%(E-Mail Removed)...
>>> 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" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed)...
>>>>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?
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

I finally figured that out the hard way. I disabled RRAS then reenabled it.
Then just picked only connect to another network with all the defaults.
This time instead of using the "use server settings to determine IP address"
in the wizard I specified a designated block of addresses on each side that
included the internal addresses. It worked out of the box & I was able to
get a full IPCP packet capture showing the IP settings stream. It's kind of
ironic that without a successful connection there is no packet stream to
analyze for IPCP, it just immediately rejects LCP before the other station
can provide any IPCP responses to show where the disagreement is. I guess
that's not Microsoft's fault, but it did seem easier to figure out using
cisco log entries. What's confusing is why didn't the connection work when
I manually specified the correct inside addresses before?

I am using the PPTP setup as a first step to successfully getting L2TP/Ipsec
going for the connection. Setting both servers to use auto works, but it
just results in a PPTP tunnel since that's the default. When I manually
changed the connection type to L2TP/Ipsec on both sides I got the expected
"certificate needed but not found" error since I don't have certificate
services running yet. I selected pre shared key for testing which
eliminated the cert error but the connection will still not establish. That
confuses me. In Ipsec Monitor I show no IKE SAs the system can use to
establish the required Ipsec quick SAs to encrypt headers or data as
appropriate, but I do show established quick SAs between the systems!
Encryption is set to optional on both sides. This is essentially a straight
out of the box setup still, I didn't change any of the security settings
that I can think of except for the Ipsec pre shared key. Any clues what to
try next?

"Bill Grant" <not.available@online> wrote in message
news:%23bIq%(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> 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:%(E-Mail Removed)...
>>>> 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" <(E-Mail Removed)> wrote in message
>>>> news:(E-Mail Removed)...
>>>>>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?
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

IPSec and certificates are tricky. I don't fully understand all the
implications myself, so I won't attempt to explain them!

"Brian Whiting" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I finally figured that out the hard way. I disabled RRAS then reenabled
>it. Then just picked only connect to another network with all the defaults.
>This time instead of using the "use server settings to determine IP
>address" in the wizard I specified a designated block of addresses on each
>side that included the internal addresses. It worked out of the box & I
>was able to get a full IPCP packet capture showing the IP settings stream.
>It's kind of ironic that without a successful connection there is no packet
>stream to analyze for IPCP, it just immediately rejects LCP before the
>other station can provide any IPCP responses to show where the disagreement
>is. I guess that's not Microsoft's fault, but it did seem easier to figure
>out using cisco log entries. What's confusing is why didn't the connection
>work when I manually specified the correct inside addresses before?
>
> I am using the PPTP setup as a first step to successfully getting
> L2TP/Ipsec going for the connection. Setting both servers to use auto
> works, but it just results in a PPTP tunnel since that's the default.
> When I manually changed the connection type to L2TP/Ipsec on both sides I
> got the expected "certificate needed but not found" error since I don't
> have certificate services running yet. I selected pre shared key for
> testing which eliminated the cert error but the connection will still not
> establish. That confuses me. In Ipsec Monitor I show no IKE SAs the
> system can use to establish the required Ipsec quick SAs to encrypt
> headers or data as appropriate, but I do show established quick SAs
> between the systems! Encryption is set to optional on both sides. This is
> essentially a straight out of the box setup still, I didn't change any of
> the security settings that I can think of except for the Ipsec pre shared
> key. Any clues what to try next?
>
> "Bill Grant" <not.available@online> wrote in message
> news:%23bIq%(E-Mail Removed)...
>> 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" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> 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" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed)...
>>>> 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:%(E-Mail Removed)...
>>>>> 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" <(E-Mail Removed)> wrote in message
>>>>> news:(E-Mail Removed)...
>>>>>>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?
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>