Re: Error 720 connecting to server via VPN

Do you have the latest firmware installed on the router? (July 24, 2007, if
you're in Australia)

Also this (from the Netgear troubleshooting page)...

By default the router's firewall is configured to drop (delete) ICMP packets
sent from outside your network to the WAN port. Your VPN may require the
ICMP packets. To accept them:

Log in to the router using a browser by typing http://192.168.0.1 or
http://192.168.1.1.

Type admin for the username and password for the password (unless you change
the password from the default). Older routers use 1234 for the default
password.

Select WAN Setup > Advanced > Respond to Ping on Internet Port. Click Apply.

Also found this:

Port Forwarding for the Netgear DG834G
(PPTP)
http://portforward.com/english/routers/port_forwarding/Netgear/DG834G/Point-to-Point_Tunneling_Protocol.htm


--
Merv Porter [SBS-MVP]
============================

"Craig Hughes" <CraigHughes@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:7942D52F-1FE1-4B5B-81DE-5A97E513D929@xxxxxxxxxxxxxxxx
Netgear D834Gv3

"Merv Porter [SBS-MVP]" wrote:

Which Netgear router are you using onthe SBS network?

--
Merv Porter [SBS-MVP]
============================

"Craig Hughes" <CraigHughes@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:987450BF-A910-4451-893D-3FBD5533765A@xxxxxxxxxxxxxxxx
Hi Joe,

I think I understand.

I've checked the system log and found the following...

A connection between the VPN server and the VPN client XXX.110.88.173
has
been established, but the VPN connection cannot be completed. The most
common
cause for this is that a firewall or router between the VPN server and
the
VPN client is not configured to allow Generic Routing Encapsulation
(GRE)
packets (protocol 47). Verify that the firewalls and routers between
your
VPN
server and the Internet allow GRE packets. Make sure the firewalls and
routers on the user's network are also configured to allow GRE packets.
If
the problem persists, have the user contact the Internet service
provider
(ISP) to determine whether the ISP might be blocking GRE packets.

So that clearly suggests the GRE is being blocked.

The problem is I don't know how to enable a protocol. The PPTP port is
open. Should I setup a firewall rules to allow port 47? But I think
from
your last message, that's not the answer.

Thanks,

Craig

"Joe" wrote:

Craig Hughes wrote:
Hi Russ,

Port 1723 (PPTP) is allowed in my router for any WAN users to the
server.

I've not got a rule for GRE (Port 43 I think) as I read it was a IP
protocol
rather than TCP or UDP. My router only allows TCP, UDP or TCP/UDP.
Should
I create a rule for port 43 as TCP/UDP?

My router is Netgear. I can't see any existing rule I can select
for
GRE or
port 43.


It's 47, it is a protocol and therefore has no connection with TCP or
UDP ports (most protocols don't use ports) and if you selected 'PPTP
Service' or similar on a Netgear machine then TCP/1723 and GRE are
both
included. If you enable logging on that rule, you'll see (when the
system finally works) an initial TCP/1723 handshake followed by
numerous
GRE packets, which carry the encrypted data.

> The Client I'm trying to connect is on the same subnet as the
server,
> 255.255.255.0.

No, that's the netmask. That may or may not be the same, but the
network
address, which is the IP address ANDed with the netmask (in this case
the first three octets of the IP address) must be different. This is
the most common cause of your particular problem. Your SBS has one of
the most common private network addresses (192.168.0.) and there's a
fair chance that the remote router also uses it. If so, one or the
other
must change, and I'd recommend using the Change IP Address wizard on
the
SBS to alter the LAN network address to something much higher, like
192.168.55. so it is unlikely to conflict with any default anywhere
else.

Do you get any entry in the System event log on the SBS? If the TCP
connection works but GRE is blocked, then there will be a message to
that effect. Using the same network address at both ends produces
unpredictable errors, as there is confusion in routing, and some
messages will get through, some won't. Sometimes you'll get the System
message, sometimes not. Usually the process will fail during
authentication, when several pieces of data need to be exchanged and
some get dropped.







.

Relevant Pages

  • Re: Linux als Router
    ... # Enter all trusted network interfaces here. ... # which should be available to the internet and set FW_ROUTE to yes. ... space separated list of ports, ... # Packets to silently reject without log message. ...
    (de.comp.os.unix.linux.misc)
  • RE: Mapping Class A network ( any easy trick?)
    ... and wondering how I can map the network ... packets per second rate to ask for. ... This will read the payloads.conf file which may have multiple payloads ... per port. ...
    (Pen-Test)
  • Re: Update: UDP 770 Potential Worm
    ... > I still believe that the packets may be the result ... with the goal of knocking machines ... the network immediately after the 'attack', ... destined to port if you haven't sniffed it somehow? ...
    (Incidents)
  • Re: UDP vs TCP
    ... TCP for instance will break up a large packet into smaller ... into the packets and then the receiving app would have to read ... Network Layer -> ethernet ... DOMAIN over port 53 ...
    (microsoft.public.vb.enterprise)
  • Re: Linksys WPC54G card utility contains spyware?
    ... >>sending packets to Akamai via the daylight port. ... >establish the network connection... ... I'm still trying to figure out the content of the daytime port ... It doesn't look like any daytime service data that I have ...
    (comp.security.firewalls)