PPTP Site to Site Test VPN will not come up

Discussion in 'Windows Networking' started by Brian Whiting, Feb 23, 2005.

  1. 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 and Local Area
    Connection 2
    Computer2 - Local Area Connection and Local Area Connection 2

    The 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
    Computer2 IP address
    Computer1's Remote Router 2 destination address is and
    Computer2's is 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 via interface Remote Router 2.
    There is a similar one in computer2 to 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
    [3992] 02-23 10:50:33:145: FsmThisLayerUp called for protocol = 80fd, port =
    [3992] 02-23 10:50:33:145: RemoveFromTimerQ called
    [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 There is no return IPCP message from
    Computer2 at all, just the Protocol-Reject.

    Why can't I get the tunnel established?
    Brian Whiting, Feb 23, 2005
    1. Advertisements

  2. Brian Whiting

    Bill Grant Guest

    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).

    Bill Grant, Feb 24, 2005
    1. Advertisements

  3. 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.

    Brian Whiting, Feb 24, 2005
  4. 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, Feb 24, 2005
  5. Brian Whiting

    Bill Grant Guest

    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

    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!

    Bill Grant, Feb 25, 2005
  6. 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?

    Brian Whiting, Feb 25, 2005
  7. Brian Whiting

    Bill Grant Guest

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

    Bill Grant, Feb 25, 2005
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.