Error 721 on Win2K VPN (Yes 47 IP enabled!!) 3

[Seeruk]

Here we go this might be lengthy but I want to provide all information needed!!!

Basically I have a Standalone Win2k server in a NT4 domain which I am setting up as the VPN server.

Two nics installed - I dont use a firewall, instead I use TCP filters to stop unwanted stuff.
I have TCP/UDP ports 80, 1489, and 1723 enabled along with IP Protocol 47 on both cards.
Our ISP provides us with static IP which is mapped to NIC2 and NIC1 is the internal lan card.
Yes the test user has diallin access both in the domain account in the NT arena and on a local account on the win2k server.
The server can be pinged through from the client and the normal funtionality of browsing etc is there at the client.
The server also can access the net

I'm out of ideas totally and it seems every bboard on the net can only suggest enabling IP Protocol 47 as a solution but it is enabled.
i am thinking its possibly a routing thing as I had a friend who solved it through routing but I dont know much on this subject

Please for the love of god tell me something to get this darn thing working as I am going crazy having spent 2 weeks working on it!!

 

[h4nym]

Seeruk et al

Solution to having to do these interactively each time u reboot is:

1. Create a batch file to add the route - type route add at the command prompt for details...

2. Create a scheduled task to run the batch file at system startup - don't put it into the Programs | startup - that only triggers when someone logs in

hth & gl

Hany

 

[EdibleDormouse]

Hey bradsm, I have exactly this problem: error 721 trying to VPN into a Win2K server behind my DG814 router. Simply doesn't work, even with the Win2K box in the DMZ. VPN "passthrough" works going out through the DG814 to connect to a VPN on the net, but it doesn't work when connecting back in.

I reckon the DG814 doesn't support proto 47 inbound.

My VPN works no probs when I connect over the LAN w/o going through the Netgear.
More info on Proto 47:
(Generic Routing Encapsulation - associated with PPTP for the VPN)

http://www.networksorcery.com/enp/protocol/gre.htm

Also Netgear don't (yet) support UPnP, which is a really useful thing to have as well. I'm contemplating getting the Draytek Vigor (

http://www.draytek.co.uk)

which supports VPN in spades.

How did you get on with the Intertex ?

 

[nomicism]

I also got 721 even I used pptpclnt and pptpsrv and the result seemed all right.

 

[EddieVenus]

just for your consideration, IP prtocol 47 a.k.a GRE is for establishing IPsec connections. If you cannot establish then you may have a problem with it. If you can establish, move on to another idea since GRE is not the problem. If you can get to the other end of the tunnel successfully, but you are stuck at the windows auth prompt, it is an issue with your windows credentials and permissions. If you are getting stuck at the VPN auth prompt then it is an issue with your credentials against the VPN termination device, whatever you are using for this (i.e. PIX, Linksys, Checkpoint, Win2K, XP box, etc) IP protocol 47 is not in any way, shape, or form related to TCP/UDP ports, so enabling port 47 will not help. And if you can connect to the other end of the tunnel, but cannot get to the LAN from that end, check with your config on the VPN termination equipment to see if you can access the LAN, if you can then you may have the issue previously mentioned about the NICs not creating a bridge between them to properly route traffic accross them. This is a known issue with win 2K and XP pro, you can do the batch file thing, or the disable and reenable thing to fix it. Unplugging and replugging it in will work, but you need to be physically present, and that defeats the point of making remote connections. I hope that helps some of you to get this working. I was in the same boat some time ago, and if I had just known what I just said I could have saved alot of time.

 

[csutton]

I've been dealing with Netgear's HR314 wireless router, that also supports "VPN" passthru. I've used pptpping to test the connection and GRE 47 and port 1723 are successfully passing it states. But I cannot get it to work.

I'm also getting the 721 error. It states connecting for a few moments, then "verifying username and password" and then bombs out with 721.

I'm just fed up with this stuff. I know my client-side works fine as I can connect to other VPN servers w/o issue.

Any ideas?
Chris

 

[MaddSkillz]

Not to total beet a dead horse but...

i am also getting a 721 error. One thing i dont get is why are people using 2 NIC cards? should i look into using 2 NIC cards what does this do for you? it seems we are all bombing at the same point after ver username and password. And yes my VPN works on the lan side so i know its "set up right". one of the things i am going to try is pluging the server into the cable modem and try it that way.

please let me know about the 2 NIC cards and or a webpage that tells me about them. i am not seeing the point of having them yet. they both have to go to the router..dont they?
thanks

 

[jimrogers1212]

I too was having this 721 error, below is a list of my hardware and what I did to correct the problem:

Windows 2000 Server acting as a domain controler w/ 2 NIC's.
Linksys 8 port router. BEFSR81

I ended up disabling one NIC which left me with the IP of 192.168.1.10 for my server.

The only configuration to my router was to put the above 192.168.1.10 as the DMZ address and then forward port 1723 for TCP to 192.168.1.10. PPTP Pass Through is by default enabled on my router.

On the Server side, I set up the VPN with a manual config. The one thing that made the difference was putting my server IP --192.168.1.10-- as the DMZ. Once I did that, it went right in.

Hope this helps . . .

 

[Dmasch]

Putting you computer in the DMZ kind of defeats the purpose of the router Firewall though, doesn't it? I may be wrong but you might want to make sure you have some security on your server.
You should just have to foward the ports you want open to the server like you mentioned and keep it behind your router. The DMZ should be used for Webserver,FTP server type of stuff. Just some thoughts.

 

[Zyxoo]

New DG814 firmware 4.4

Try with reduced MTU said Netgear (in some contries)

 

[Skadaddle]

Hello All,

I am having the same Error 721 issue waiting for the remote computer to respond. I have tried all your suggestions as far as unplugging the net cable or disabling it. i have even manually rebuilt the RRAS. I am able to connect across the LAN but from the outside through the router i get the Error 721 Timeout. I have been going through all kinds of message boards looking for more info. Nothing...

I have W2K Clients & Servers. I am using the Actiontec DSL (VPN) router. It has VPN Passthrough. I see that the initiall VPN request is making it to the server but the servers response is not making it back out. Someone mentiond a route problem. If this is it should I take out the second NIC and try that?

Thanks for any help you can offer.

 

[EddieVenus]

have you opened up port 1723?
Are you a user on the VPN server? and is that user allowed to connect over VPN?
is your router firmware more than 6 months old? is there an update for the firmware?
is the port forwarding on 1723 going to the right machine?
why are you using 2 nics? is this machine a proxy, that it needs 2 nics? if you disable the other nic before attempting the connection to the VPN does it work?
have you torn the VPN down and started from scratch?

something has to be wrong with your configs, either the client, the remote or the firewall, check and recheck. Start from scratch if you have to, there seems to be no other explanation here.

EV

 

[Skadaddle]

EddieV Thanks for responding so quickly.
To answer your questions yes, I have opened up port 1723?
Yes, I am a user on the VPN server? and yes the user is allowed to connect over VPN?
Yes, I have updated the firmware?
Yes, the port forwarding on 1723 is going to the right machine?
In the MS instructions it said it need two NICs
I have tried disabling either NIC and also just unplugged one and still same error.
Yes, I have torn the VPN down and started from scratch.

I have checked, rechecked, uninstalled settings and re-set them up. Yes, it seems as I have everything correct but no success. I have even called the company that makes the DSL modem and they setup a test lab to make sure the modem could do what it says it does and they claim to have made it work.

Would you suggest tearing down the VPN again, disabling one of the NICs and rebuilding the VPN?

Thanks again for your help.

 

[bwilliam13]

First off...

EddieVenus, please have your data/info correct before making a statement like that.

PPTP RIDES on/in protocol 47 (GRE). Generally, you can't have PPTP without GRE incoming AND outgoing.

Secondly, IPSec uses protocols 50 and 51 (AH and ESP)...not 47.

If you're getting error 721's on the client-side, it's because your client is not passing protocol 47 correctly. Period. PPTP is just tcp packets on port 1723, but it requires the GRE protocol which is a subset protocol of IP. Just because a system supports TCP/IP, doesn't mean it will support IP as a whole. IPX falls under IP too...and most off-the-shelf internet routers will not route IPX natively...so off-the-shelf dsl/cable routers don't support the whole IP protocol and all of it's subsets.

Problems outside of the original post in this thread may be due to the fact that tcp 1723 is being NAT'ed out correctly along with GRE, but GRE isn't being let back in. It's bidirectional folks. It has to be open on both ends...otherwise you're screwed.

Also, to the person setting up the conduit thing and cannot get it to work with GRE protocol, do you have the latest IOS software for the Cisco firewall? If so, use access lists instead of conduits, and when using either, your protocol should be GRE...in which case, you don't need to specify a port. Simple syntax:

conduit permit gre ipaddress subnetmask 0 0

Access list syntax would look like:

access_list acl_whatever permit gre ipaddress subnetmask any

Hope this helps.

And that's a myth about needing two NICS. I have a 2000 VPN server on my home network...1 NIC. Works faster than a system with 2.

 

[csutton]

BWilliam,

On my side, using the pptpping utilities, 47 is being passed thru successfully. However, i'm still receiving the 721 error. Using the SAME client, I can connect to other PPTP servers w/o a problem.

 

[bwilliam13]

csutton,

What's the OS in question? What are your firewalls on each end (specific models and configs)? And what is the VPN server (specific model or OS, service pack, etc)?

I've got a user with the same issue. 20-30 other folks can connect to our VPN server fine. With the same settings on his client, he can't. I'm thoroughly convinced that something is going on with either something running on his client, or more likely there's something up with his firewall/router.

I've been through a lot of problems with MS VPN clients, and to this point, it's always been due to something going on the client side. In XP, simply having the QoS packet scheduler running sometimes will cause the connection to totally jack.

 

[Skadaddle]

CSutton & BWilliams,

Thanks for your feed back. I can connect to a different VPN (w2k) and I don't have Protocal 47 enable on the client. So, It seems likly that it is not the protocal 47 issue.
But, I will try anything. If I do need to enable it can you give instructions on how to do it?

Any other ideas here is what I have.

VPN running on W2K server.
Using ActionTech DSL Modem with VPN Passthrough turned on with IPSEC also.
W2K client (Is able to connect to other VPN running on w2k servers.)
Ports 1723 are open on the DSL modem
When attempting to connect I get as far as "Verifying username and password. Then I get the error 721 no response from server.

Because it gets to verifying does this mean it got through the DSL modem but the response is not get back out?

 

[bwilliam13]

It means GRE is not working correctly coming back into your modem/router. It's bidirectional. You cannot just NAT it outgoing...it has to be open coming back in also.

 

[Skadaddle]

Thanks Bwilliam13.

So can you explain how to do this? How do you enable protocol 47? Do I do this on the Client or the VPN server (Both use Win2K)

 

[bsdboy]

Allllllrighty then. I have had the same troubles as all of you and experience the wonderously annoying 721 error also.

I use an OpenBSD 3.0 box as my firewall connecting to an internal win2k server.
The BSD box provides NAT and proxying for internal clients.
rdr smtp traffic works fine to win2k. so i know redirects are working correctly. rdr 1723 and gre well...who the hell knows!
i have read all of your posts and from many many different forums they all say the same thing.
What the hell is going on with this protocol 47?
Question.
Does ah & esp have to be enabled on the bsd box to allow the redirect of gre?
I didnt think it would have to be as i am simply redirecting all 1723 and gre traffic to an internal box.
net.inet.gre.allow=0 by default and if you turn that on the kernel tries to process the packets. it seems to eat them
that is not desired funnily enough.
so i am going to give enabling ah & esp a go but i dont expect any great achievments.
by the way adsl routers users....grab an old box..wak bsd on it and there is much better solution for router/firewall/ids/proxy...support open source.

 

[bwilliam13]

AH and ESP have nothing to do with GRE.

Folks, there is a difference between transmission controls, and actual protocols those transmission controls use. This is TCP/IP 101.

TCP 1723 is the transmission control protocol that GRE information travels through. In other words, in an IP header, when you are using the Microsoft VPN stuff, you send out a packet with a destination IP addres of whatever, traveling over TCP port 1723 going out, utilizing the GRE protocol (IP protocol 47). For this to happen, GRE has to be enabled bidirectionally on BOTH sides. If it is not enabled on both sides, then your connection WILL fail...consistently.

By default, the Microsoft VPN clients and servers do not block any packets. However, any perimeter network device between the VPN client and the VPN server could be blocking GRE packets or even TCP port 1723, making establishing a PPTP VPN connection impossible. This can occur on a router with restrictive access lists in place, or firewalls on each/both ends.

If you are getting 721 errors, likely culprit is either the next hop router past your VPN server (YOUR ROUTER HOOKED TO YOUR INTERNET CONNECTION), or your firewall. Period. So, you have potentially 4 network devices to check outside of the VPN client and the VPN server = the firewalls and routers on each end of the connection.

Linux IPTables firewalls will automatically NAT correctly any outgoing packets (TCP port 1723) and will automatically accept GRE back in if there was a request originating from inside the network, but that is the only firewall that I know will NAT TCP port 1723 and GRE correctly without having to have explicit rules to allow both incoming and outgoing.

If all of you can give me specific OS'es, service packs, names/model #'s of your router and firewall devices on each end of your connections, then I can help...because I know about a LOT of network devices. But you need to know the hardware you're dealing with...because I think that is most of your problems in this thread. You're trying to pass packets through a device that is set up to block them by default...otherwise your connection attempts wouldn't be failing consistently.