Re: PPTP Site-to-Site VPN problem

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Sergio Ricci wrote:
> Hi Ian,
>
> Initially the routes were set via the wizard when configuring the
> demand dial interface. I have subsequantly deleted, re-created, tried
> to modify etc the static routes since. All have produced the same
> result.
> Just for clarification, there is currently only 1x static route on
> each server. The static route details are as below:
>
> Routes on: Server1
> Server1 IP: 192.168.30.4
> Routes: 192.168.31.0 mask 255.255.255.0 192.168.30.4
>
> Routes on: Server2
> Server2 IP: 192.168.31.3
> Routes: 192.168.30.0 mask 255.255.255.0 192.168.31.3
>
> Thanks again.
> Sergio
>
>
> "Ian" <gruntyonline@xxxxxxxxxxx> wrote in message
> news:OpuMK1lyFHA.1168@xxxxxxxxxxxxxxxxxxxxxxx
>> Sergio Ricci wrote:
>>> Ian,
>>>
>>> I will try disabling the firewall to see what happens and let you
>>> know. My understanding has always been that if you route between 2 or
>>> more
>>> different subnets then there has to be a gateway defined. If
>>> routing on a single subnet then no gateway needs to be defined. I
>>> stand to be corrected of course.
>>>
>>> Thanks again for getting back to me.
>>> Sergio
>>>
>>>
>>> "Ian" <gruntyonline@xxxxxxxxxxx> wrote in message
>>> news:e0eoAEgyFHA.1252@xxxxxxxxxxxxxxxxxxxxxxx
>>>
>>>> Sergio Ricci wrote:
>>>>
>>>>> Ian,
>>>>>
>>>>> Yes the routers are able to support VPN connections natively (no
>>>>> problems with client to server VPNs and indeed VPN connections
>>>>> between the servers themselves). The routers are basic no NAT DSL
>>>>> routers. NATing is done by the RRAS service on the servers
>>>>> (Windows 2003 with SP1).
>>>>>
>>>>> The additional NIC's (1 in each server) have static public IP
>>>>> addresses. These NIC's have the default gateways set to the IP
>>>>> address of the DSL routers. Clients behind the servers have their
>>>>> default gateways set to the private IP address of the severs.
>>>>>
>>>>> I'm pretty sure that the issue I'm experiencing is as a result of
>>>>> the fact that the PPP adapters created when the VPN tunnels are
>>>>> established do not have (or do not get configured with) a default
>>>>> gateway. Thanks for replying.
>>>>> Sergio
>>>>>
>>>>> "Ian" <gruntyonline@xxxxxxxxxxx> wrote in message
>>>>> news:u6BrHDfyFHA.2540@xxxxxxxxxxxxxxxxxxxxxxx
>>>>>
>>>>>
>>>>>> Sergio Ricci wrote:
>>>>>>
>>>>>>
>>>>>>> Wendel,
>>>>>>>
>>>>>>> Pls see the output below. The trace was carried out from a
>>>>>>> client on the 192.168.31.0 subnet who's default g/w points to
>>>>>>> the LAN NIC of the RRAS server on the same subnet. NB: I've
>>>>>>> abbreviate the output to 4 hops. The complete output continues
>>>>>>> giving "Request timed out". Tracing route to 192.168.30.5 over a
>>>>>>> maximum of 30 hops
>>>>>>>
>>>>>>> 1 <1 ms <1 ms <1 ms 192.168.31.4
>>>>>>> 2 7 ms 7 ms 7 ms 192.168.31.110
>>>>>>> 3 * * * Request timed out.
>>>>>>> 4 * * * Request timed out.
>>>>>>>
>>>>>>> 192.168.31.110 is the IP address obtained by the RRAS servers
>>>>>>> PPP adapter that is on subnet 192.168.30.0, so it appears to
>>>>>>> get as far as the RRAS router on the other side of the VPN link
>>>>>>> but gets stuck there. I note also that there is *no* default
>>>>>>> gateway set for the PPP adapter and so could this be the cause?
>>>>>>>
>>>>>>> I confirm that both servers are multi-homed with each having 1x
>>>>>>> NIC facing the LAN with no default gateway set and the other
>>>>>>> NIC connected to the DSL router with a static IP address and
>>>>>>> default gateway set. Funnily enough, I am able to configure a VPN
>>>>>>> connection on a
>>>>>>> client on the 192.168.31.0 subnet to connect to the RRAS server
>>>>>>> on the 192.168.30.0 subnet and it works fine.
>>>>>>>
>>>>>>> Please let me know if you need any further info and thank you
>>>>>>> also for you help so far.
>>>>>>>
>>>>>>> Sergio
>>>>>>>
>>>>>>>
>>>>>>> "Wendel Hamilton" <WendelHamilton@xxxxxxxxxxxxxxxxxxxxxxxxx>
>>>>>>> wrote in message
>>>>>>> news:47D20B6B-F0E2-4F81-B9DC-7D51E883799F@xxxxxxxxxxxxxxxx
>>>>>>>> Sergio,
>>>>>>>> Ok I think it is a routing problem.
>>>>>>>> use tracert -d to the remote server and workstations and see
>>>>>>>> where it fails.
>>>>>>>> Could you post the results?
>>>>>>>> I assume that both servers are multi-homed servers. (2 NICs)
>>>>>>>>
>>>>>>>> "Sergio Ricci" wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Yes. Deafult g/w points to the the internal NIC of the RRAS
>>>>>>>>> server. One thing I didn't mention if that both servers are DC's.
>>>>>>>>>
>>>>>>>>> Thanks for replying.
>>>>>>>>> Sergio
>>>>>>>>>
>>>>>>>>> "Wendel Hamilton" <WendelHamilton@xxxxxxxxxxxxxxxxxxxxxxxxx>
>>>>>>>>> wrote in
>>>>>>>>> message
>>>>>>>>> news:0F15E7AE-11C1-4B7A-8476-5A85144B857D@xxxxxxxxxxxxxxxx
>>>>>>>>>> Sergio,
>>>>>>>>>> Does your clients default gateway point to your RRAS servers?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> "Sergio Ricci" wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I've setup (or tired to) a site to site VPN using RRAS in
>>>>>>>>>>> Windows 2003
>>>>>>>>>>> SP1
>>>>>>>>>>> but have a few issues that I hope you may be able to help me
>>>>>>>>>>> resolve:
>>>>>>>>>>>
>>>>>>>>>>> Subnet
>>>>>>>>>>> 192.168.30.0/24<------------------------------------------>Subnet
>>>>>>>>>>> 192.168.31.0/24
>>>>>>>>>>>
>>>>>>>>>>> ClientsA-------Server1----Router1--------Internet--------Router2---Server2-----ClientsB
>>>>>>>>>>>
>>>>>>>>>>> I have setup demand dial connections on both servers
>>>>>>>>>>> (windows 2003+SP1)
>>>>>>>>>>> and
>>>>>>>>>>> they appear to work OK. Note that there are demand dial
>>>>>>>>>>> connections on
>>>>>>>>>>> both
>>>>>>>>>>> servers pointing to the other server. The servers can ping
>>>>>>>>>>> each other.
>>>>>>>>>>> The
>>>>>>>>>>> clients can ping the servers on their subnets but cannot
>>>>>>>>>>> ping any host on
>>>>>>>>>>> the other subnet.
>>>>>>>>>>>
>>>>>>>>>>> All this has led me to think (from other posts I have read)
>>>>>>>>>>> that there
>>>>>>>>>>> may
>>>>>>>>>>> be an issue with the user account and demand dial interface
>>>>>>>>>>> name but I
>>>>>>>>>>> believe I have go them correct.
>>>>>>>>>>>
>>>>>>>>>>> Essentially I would like clients on one subnet to be able to
>>>>>>>>>>> transparently
>>>>>>>>>>> access and connect to servers/clients/hosts on the other
>>>>>>>>>>> subnet. I'm probably missing something quite obvious but at this
>>>>>>>>>>> moment just
>>>>>>>>>>> can't
>>>>>>>>>>> see what it is.
>>>>>>>>>>>
>>>>>>>>>>> Some other bit's of info that you may need: when I
>>>>>>>>>>> originally configured
>>>>>>>>>>> RRAS on both servers I did a custom configuration and
>>>>>>>>>>> selected: NAT,
>>>>>>>>>>> Demand
>>>>>>>>>>> Dial, Firewall, LAN Routing (from memory). All clients have
>>>>>>>>>>> internet
>>>>>>>>>>> access.
>>>>>>>>>>>
>>>>>>>>>>> If you require any further info, please let me know.
>>>>>>>>>>>
>>>>>>>>>>> Thanks in advance for any help/pointers.
>>>>>>>>>>>
>>>>>>>>>>> Kind regards,
>>>>>>>>>>> Sergio
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>> Sergio - A bit off topic to start!! - Are your router capable of
>>>>>> VPN natively?
>>>>>>
>>>>>> What IP addresses are on the additional cards? Are the cards in
>>>>>> the DMZ of your routers or are you using port-forwarding, if so,
>>>>>> what ports are you forwarding.
>>>>>>
>>>>>> Ian
>>>>>
>>>>>
>>>>>
>>>> Have you tried temporarily disabling firewall on RRAS?
>>>>
>>>> I don't think the PPP adaptors need to have default gateways as
>>>> the ip addresses issued will be in the same virtual network.
>>>>
>>>> Ian
>>>
>>>
>>>
>> Hi Sergio
>>
>> Just another thought! When did you set the routes for the VPN? did
>> you specify the routes when you were conifguring the demand dial
>> interface or have you added them manually?
>>
>> Ian

Hi Sergio,
As Ian said, there is no point in having a default gateway on a PPP
interface. A point to point connection is just like a pipe. What goes in one
end comes out the other. There is no routing involved between the ends of
the connection. The data is encrypted and encapsulated, then sent through
the link. At the other end the header is stripped and the packet decrypted.
All the point-to-point link did was move the packet from one site to the
other.

Firewalls between the tunnel endpoints also have no effect on the
traffic. The private network packets are encrypted when they go through
these firewalls. All the firewall sees in the header of the wrapper. It
can't see the encrypted data.

Where routing is important is in getting the traffic to and from the
routers which are the endpoints of the connection. When the connection is
up, it should work just like a simple IP router. If the router is the
default gateway for the LAN, everything should just work.

If you can't connect from a workstation in one site to a workstation in
the other it is a straight forward routing problem. If each router has a
route to the other site through the tunnel (check the routing table on both
routers) and the RRAS router is the default gateway for the LAN in both
sites, it should work. If it doesn't you have a legitimate problem. I would
call PSS.

SP1 for Server2003 tightened up network security (as SP1 for XP did). It
killed a lot of networks which were wrongly configured and a few which were
correctly set up. If your problem is one of the latter PSS should have a fix
for it.


.

Relevant Pages

  • Re: Confusing Route issue.
    ... It seems you have indeed isolated the issue to an XP routing issue. ... The best workaround I can suggest is removing the static routes from all the ... create static routes on the corporate router to the other ... They are opening and saving CAD files from our customer. ...
    (microsoft.public.windowsxp.network_web)
  • Re: Server 2003 RRAS Routing
    ... You simply enable IP routing in RRAS. ... That just enables the router. ... how do I enable Internet routing through RRAS? ... However, when any user attempts to connect to the VPN, they only get routes for the subnet local to the RRAS server. ...
    (microsoft.public.windows.server.networking)
  • Re: getting routes from internet facing routers
    ... Attacker can get the routing info by exploiting routing protocol in ... Just have a proper ACL on the router, ... seeing what private IP routes ... Securing Apache Web Server with thawte Digital Certificate ...
    (Security-Basics)
  • Re: Two Routers VPN Community Wireless
    ... The routing table is standard with the primary gateway at 192.168.12.138. ... I think I have a understanding of how routes work from the PC but combine ... tables in the Router even come into play when the VPN tunnel is established? ... If it would help I can bring the actual routing table in tomorrow from home. ...
    (microsoft.public.windowsxp.network_web)
  • Re: Q: multi-homed server with multiple default routers
    ... Instead only the destination address and routing table are used ... >> to determine the interface and hardware destination. ... to add a permanent route other than adding a default router. ... It is also a method to add one or more permanent routes that are not ...
    (comp.unix.solaris)