Re: PPTP Site to Site Test VPN will not come up
From: Bill Grant (not.available_at_online)
Date: 02/25/05
- Next message: bill: "vpn network drives"
- Previous message: NFSnewbie: "NFS shares"
- In reply to: Brian Whiting: "Re: PPTP Site to Site Test VPN will not come up"
- Messages sorted by: [ date ] [ thread ]
Date: Sat, 26 Feb 2005 10:59:05 +1100
IPSec and certificates are tricky. I don't fully understand all the
implications myself, so I won't attempt to explain them!
"Brian Whiting" <nospam@deny.com> wrote in message
news:Odn8PT0GFHA.584@TK2MSFTNGP14.phx.gbl...
>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: bill: "vpn network drives"
- Previous message: NFSnewbie: "NFS shares"
- In reply to: Brian Whiting: "Re: PPTP Site to Site Test VPN will not come up"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
