[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3971
  • Last Modified:

Unable to connect to VPN through NetGear FVX538 VPN ProSafe Firewall.

I have had so much trouble using the Netgear VPN firewall and the VPN client software that I have decided to abandon this setup and venture into something new.
I'm now trying to set up a VPN with the provided, free software that comes with Windows XP Pro and Windows Server 2003.  I have successfully setup the VPN servers-side with Tech Republic's help and white papers and I have also setup the client-side of the VPN as well.
Now I'm at the part where I'm using pptpsvr.exe and pptpclnt.exe (free from Microsoft) to test whether or not the request from the client is making it through the NetGear firewall and making it to the VPN server. Then the VPN server should reply back to the client with "x" number of GRE packets.
This is my problem. I can't get a reply from the VPN server so I assume that the request is not making it past the firewall. I have opened up port 1723 and forwarded it directly the static IP of the VPN server. My client is on another network with an IP of 192.168.0.x while the network I'm trying to connect to is on network 192.168.1.x. I did read that I have to set up IP protocol 47 as well. To my knowledge this IP protocol 47 is not TCP/UDP port 47. I don't know how to configure this IP protocol 47 on my FVX538 VPN ProSafe firewall in order to allow my VPN request to reach the server. Any ideas out there on how to configure this IP protocol 47?
I need this issue to be resolved asap in order to keep my boss happy!
0
HbugProject
Asked:
HbugProject
1 Solution
 
fruhjCommented:
I have a 538 at a clients and it works great.
I don't remember forwarding port 47, just the 1723 one.
They are using the vpn server in Windows, and it connects like a champ from my home network -so the trip is similar
home 192.168.15.x to theinternet, then public IP of the router, then to the private 192.168.1.x address of the server.
Can you try to connect to the VPN from INSIDE the network first - to verify you have it right?
0
 
HbugProjectAuthor Commented:
Yes I was able to connect to the VPN inside the network. I connected just fine with no problems at all. I just can't seem to connect to it from outside the network.
0
 
Rob WilliamsCommented:
Protocol 47 (GRE) is usually forwarded by simply enabling VPN pass-through" or "PPTP pass-through". However, on the Netgear routers I have worked with, this is not an option. Instead enabling port forwarding using their built-in PPTP port 1723 service, enables this automatically. If you manually create a new service for port 1723 rather than using the existing one, this does not seem to be the case. If blocked GRE is the problem you most often get a #721 connection error.
As for the pptpsvr/ pptpclnt I have never had it work as it is supposed to. If you enable it on the server and try to connect, the server does seem to present a message that the GRE packets were received. But I have never had it show that they were sent back. I suspect you would have to enable port forwarding and configure the firewall on the client to have it function in that way, such as in a site to site PPTP VPN configuration.

First test I would do is from the VPN server go to  http://www.canyouseeme.org  and test for port 1723. This will at least verify that the port forwarding is functioning. From this site you can also verify the IP to which yo are connecting is correct.
0
New Tabletop Appliances Blow Competitors Away!

WatchGuard’s new T15, T35 and T55 tabletop UTMs provide the highest-performing security inspection in their class, allowing users at small offices, home offices and distributed enterprises to experience blazing-fast Internet speeds without sacrificing enterprise-grade security.

 
HbugProjectAuthor Commented:
RobWill,
That was informative because I did find an issue with my rule I created on the firewall. I went to canyouseeme.org and I tested port 1723 and it was successful. However, they gave me a different IP than the one I had in the rule which was my outside IP that I totally forgot about. So I configured my outside IP address in the rule as well.

So this is how I have my rule set up now in my firewall:
service - PPTP (TCP 1723) + None
Action - Allow always
Send to LAN Server - 192.168.1.x (internal IP of my VPN server)
WAN Users - Any
Public Destination IP Address - Other Public IP Address
                                            209.175.252.x (the IP that canyouseeme.org gave me)
QoS Priority - None
Log - Always

I'm still getting an error 800: Unable to reach VPN server from outside the network.
0
 
Rob WilliamsCommented:
>>"Public Destination IP Address - Other Public IP Address
                                            209.175.252.x (the IP that canyouseeme.org gave me)"
Is this part of the Netgear configuration or just informing of the VPN client connection information. It is the IP the client should be connecting to.
Also I would completely disable any software firewalls on the VPN server, just as a test. Firewalls such as Windows built-in, ZoneAlarm, Symantec, McAfee and such can block the VPN. One other I have come across is, if using Symantec for virus protection, it's Internet Worm Protection feature can cause problems.
If still not working see if you can connect the remote client directly to it's modem by-passing the router as a test. If you do so make sure virus protection, Windows updates and such are in place.
0
 
HbugProjectAuthor Commented:
Problem solved. I was using the wrong internal IP address as the host IP for the VPN configuration. Since I corrected it, it works fine now.
0
 
Rob WilliamsCommented:
Ah, That would do it <G>. Thanks for the update.
--Rob
0
 
ee_ai_constructCommented:
PAQ / Refund
ee ai construct, community support moderator
0

Featured Post

[Webinar] Cloud and Mobile-First Strategy

Maybe you’ve fully adopted the cloud since the beginning. Or maybe you started with on-prem resources but are pursuing a “cloud and mobile first” strategy. Getting to that end state has its challenges. Discover how to build out a 100% cloud and mobile IT strategy in this webinar.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now