Re: PPTP Site to Site Test VPN will not come up
From: Brian Whiting (nospam_at_deny.com)
Date: 02/25/05
- Next message: Steven Platt: "Re: Cannot connect to internet behind NAT"
- Previous message: Robert L [MS-MVP]: "Re: Can't Browse the Domain"
- In reply to: Bill Grant: "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: Fri, 25 Feb 2005 09:18:02 -0500
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%23VtGFHA.2384@TK2MSFTNGP10.phx.gbl...
> 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: Steven Platt: "Re: Cannot connect to internet behind NAT"
- Previous message: Robert L [MS-MVP]: "Re: Can't Browse the Domain"
- In reply to: Bill Grant: "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
|
