The GRE setting makes sense. The traffic in both directions is encrytped
and encapsulated, so blocking GRE in either direction will cause the
connection to drop. Can't think of any reason for TCP filters to cause
problems. All the TCP traffic between client and server (apart from 1723)
should be "inside" the encypted and encapsulated packet.
Al Stephenson wrote:
> Ok...I did more checking and noticed that I wasn't allowing GRE out
> from the inside...I turned that on and have been able to successfully
> connect but only if I allow all TCP traffic through... Is there
> another tcp port other than 1723 that is needed to establish the
> connection?
>
> "Al Stephenson" wrote:
>
>> Thanks for your response...I rechecked and I am allowing tcp port
>> 1723 and IP protocol 47 through the firewall.. I can connect
>> successfully internally to the VPN...
>>
>> At one point I even opened up all tcp, udp and IP protocols (only
>> for a few minutes mind you) and still could not connect from
>> outside..Any further help would be appreciated..
>>
>> Thanks
>>
>> "Bill Grant" wrote:
>>
>>> Can you connect from a client machine on the LAN? If you can,
>>> the problem is probably not on the server.
>>>
>>> As well as forwarding tcp port 1723, the firewall must not
>>> block GRE (IP protocol 47). Note it is a protocol, not a port!
>>>
>>> Al Stephenson wrote:
>>>> Hi All!
>>>>
>>>> I have a Windows 2003 server 1 NIC that I cannot connect any
>>>> clients too. I have checked and rechecked the firewall and it is
>>>> routing the vpn client traffic properly to the server running RAS.
>>>> I believe the problem is a routing problem on the server.
>>>>
>>>> In the IPRouterManager file I have an error message that says
>>>> ProcessDefaultRouteChanges: Not default route <ip address of VPN
>>>> client>
>>>>
>>>> Has anyone ran into this before...I have disabled and reconfigured
>>>> the RAS service more times than I would want to admit to....
>>>>
>>>> Thanks in advance for your help...
|
Similar Threads
