Forwarding PPTP to SBS2003 drops connection after time.

[Infohead]

First time post, so go easy on me. I don't like wasting anyones time, so I will try to be as descriptive as possible. I have searched the Wiki, FAQ, and Forums, even waited a week or so before posting, just in case I saw a post with a similar issue.

I have been having an issue with port forwarding PPTP (TCP Port 1723) to a Windows Small Business Server 2003 box. (Standard, no ISA) This SBS server initially had two interfaces, one connected directly to the Internet, but was converted to only having one so that I could put the UT server in front in Router mode. (running UT 5.3)

All other forwarded ports work with without issue, only port 1723 has issues after about 4-5 minutes it drops connection. This only happens when I am trying to VPN in from behind some types of NAT routers, like an off-the-shelf very common LinkSys or D-Link. Although I have found and older one, that does not have an issue. Also, if I am connecting to the Internet, live on the wire (non-NAT), I do not have this problem.

I did change the UT Management port from 80 to 81, and bypass 443 as I do have an valid SSL cert installed on the SBS. All of that works with no issue getting to my SBS server inside behind UT. Even syncing my Treo on Verizon with Windows Mobile has been working without issue.

I have done TCPDUMPS and sent to UT Support, and they said it could be a bug. http://bugzilla.untangle.com/show_bug.cgi?id=4506
I worked with Richie, who was a very patient and willing to help me test with various changes, but we never solved it.

I know it seems redundant to post on the forums when I have already contacted support, but I just wanted to reach out to the community and see if anyone else may be having the issue and maybe could offer a work around. I can't be the only one with this issue right??!?

I have tried changing the MTU from 1500 to 1492 as this is DSL not Cable. I have used the following NAT Routers in testing:

Model: D-Link DIR-655
Firmware: v1.11 (2007/12/05)
MTU: 1492 or 1500
Result: PPTP connection drops after 3-4 minutes.

Model: D-Link DGL-4300
Firmware: v1.8 (2007/03/01)
MTU: 1492 or 1500
Result: PPTP connection drops after 3-4 minutes.

Model: Linksys WRT54G
Firmware: v8.00.5
MTU: 1492 or 1500
Result: PPTP connection drops after 3-4 minutes.

Model: Linksys WRT54G
Firmware: v4.21.1
MTU: 1492 or 1500
Result: None, PPTP connection ran with no drop for over 20+ minutes. (This device has never had an issue with the VPN dropping)

I can also stay connected without issue from the local LAN of one of my clients SBS2003 networks. (Which is essentially NAT as well)

Also, if I swap out the Untangle Server with a Netgear FVS318v3 router, this problem goes away and there are no issues. The Netgear router is configured with the identical Internal/External IP addresses and port forwarding rules as the Untangle Server. (Just unplug one, plug in the other)

Please let me know if I can be of further assistance in helping diagnose this issue. It is vital for me to get this resolved as I have a couple clients, also running SBS2003 that want to use Untangle for all its offerings. It is a money making opportunity for me and is the #1 reason I signed up to be a UT reseller. (I'd like to get a return on that investment too) Without this VPN dropping issue resolved I cannot install the product for them as they have the same wireless gear at their homes. They will not be happy customers with the VPN dropping when they try to work from home since it is currently working today without issue.

I'm sure someone will suggest, well just use OpenVPN, but that is not the point. I don't want to have to touch the clients home systems as this should just work 100%.

Now if this is truly just a bug and I have not overlooked something, I can live with it and hope that it will be addressed by development quickly.

I thank you for any assistance in this matter.

[mdh]

How much RAM does your Untangle box have in it?

[Infohead]

How much RAM does your Untangle box have in it?

UT Server Config:

Shuttle SB75G2 (Intel 875 Chipset)
P4 2.8GHz HT
1GB RAM
80GB
Onboard GB NIC (Broadcom Chipset) (Used for Internal)
Intel PRO100 MT PCI (Dual Port NIC) (Used for External/DMZ)

Thanks.

[mdh]

Are you allowing GRE protocol in your PPTP port forward? Have you poked around to see what kind of keep-alive times may be involved? Grasping for straws here, obviously.

[Infohead]

Are you allowing GRE protocol in your PPTP port forward? Have you poked around to see what kind of keep-alive times may be involved? Grasping for straws here, obviously.

Yes, the GRE box is check on the port forward rule. (See attached)

As far as keep-alive parameters, I have not seen this in any rules or VPN settings. It's just the standard MS VPN Connection, no deviation from the "default" when it was created. I have also testing this under Vista x86/x64 and XP Pro, all with the same results. Here are the steps.

1. Establish VPN connection from an external source. (Wired or Wireless)
2. Open Command Prompt, ping 192.168.13.11 -t (ip of SBS)
3. It will reply for like 4-5 min, then "Request timed out." until the VPN session is re-established.

Because of this ping testing, I don't think keep-alive will come into play as it's alive bouncing ICMP packets. It shouldn't drop.

I know this is a tough one, maybe it's just a bug and I've have to wait until development fixes it. I've just been banging away at for over a week and found it hard to believe I'm the only one.

Thank you for spending the time to look into the issue, I appreciate it. Sometime "fresh eyes" can spot something.

[mdh]

If you're running Attack Blocker, try shutting it off and see if there's any difference. It may be labeling you and acting accordingly.

[Infohead]

If you're running Attack Blocker, try shutting it off and see if there's any difference. It may be labeling you and acting accordingly.

I just tested this, but it still dropped the connection. Correct me if I'm wrong but doesn't a System Bypass Rule make it so that the packets don't go through any of the apps in the rack? I have that rule enabled. (See attached)

I also have a bypass rule to allow all IP addresses in the PPTP Pool (DHCP reservations for RRAS) to see if that would help with the outbound traffic, but it did not. (See attached)

Thanks.

[sky-knight]

The Linksys WRT54G routers have defective PPTP streaming... no firmware will stabilize those units I have had to replace 6 of them in the last month due to this issue. In my case all I get is DUN errors on connect. I spent two days on the horn with Linksys before they finally coughed up the bug... The D-Link units you posted issues with are interesting, I don't know if any of the users I have run that equipment specifically but I know of several that have D-Link equipment and have reported no issues.

P.S. Bypassing the PPTP pool does you no good, the UT server will simply never see that addressing. You have to bypass based on the TCP traffic that encapsulates the PPTP session. I only have one customer running PPTP behind a UT server, and all I did was forward TCP 1729 to the server. My customer is running Windows 2003 Standard for their PPTP server. Perhaps removing the GRE will help?

[Infohead]

The Linksys WRT54G routers have defective PPTP streaming... no firmware will stabilize those units I have had to replace 6 of them in the last month due to this issue. In my case all I get is DUN errors on connect. I spent two days on the horn with Linksys before they finally coughed up the bug... The D-Link units you posted issues with are interesting, I don't know if any of the users I have run that equipment specifically but I know of several that have D-Link equipment and have reported no issues.

P.S. Bypassing the PPTP pool does you no good, the UT server will simply never see that addressing. You have to bypass based on the TCP traffic that encapsulates the PPTP session. I only have one customer running PPTP behind a UT server, and all I did was forward TCP 1729 to the server. My customer is running Windows 2003 Standard for their PPTP server. Perhaps removing the GRE will help?

Thank you for the feedback. I just have a hard time believing that all of these various routers I am testing have this same issue though. Everything worked just fine prior to putting UT in front of the SBS server. As a test I can swap out the UT Server with another router, say for example a NETGEAR FVS318v3 or a Xincom XC-DPG502, with the same external/internal IPs that were on UT, the same exact port forwarding rules, and it works 100%. I get no dropped connections on any of router devices I use to connect to the Internet with, then establish a VPN connection.

The other part is this, I really want to implement UT for my various clients, but they are all using at least one or more of the devices I have tested and they all are currently working without issue. It is hard to explain to a client/customer, "Well you just need to get a new router for your home and office if you want to use the Untangle product." It's just not going to go over well.

With respect to the PPTP Pool Bypass, it was just a "shot", as I've been trying everything. Also, GRE enable or disabled on the port forward rule has no effect on it dropping connections. I think you meant 1723 not 1729, it's late I know.

Earlier today or yesterday I guess it is now I also had a chance to swap out the production SBS server with a "test VM" one I built thinking maybe there were some lasting issues with removing the 2nd NIC on the SBS, removing it's role as the firewall, but it still drops after 4-5 minutes with the test SBS server. Also, I did run the appropriate Internet and E-mail connection wiz after disabling that 2nd NIC on the production SBS.

Well I guess my remaining options are, wait for a new build, see if this bug is fixed. http://bugzilla.untangle.com/show_bug.cgi?id=4506 or try out the OpenVPN solution and see if I can convince my clients that it's worth spending the extra money to have me reconfigure their home/laptop systems. I think I'll just wait for a new build and go from there.

Thank you for taking the time to look over this issue. If anyone else has any ideas for me to try, just let me know.

[Reeger]

I too recently setup an Untangle (VERY niiiice product). I ran into something similar to what you are explaining. I ended up creating a port forward for port 43 and port 1723. I have attached my port forward images. Everything seems to be working correctly. This only seems to be the case when a Windows server is behind the Untangle. (gotta love windoze - keeps us employed)

*just a note - We implemented the UT for the open vpn features. just haven't got around to setting them up. *

Hope this helps, and thanks to the Untangle team for making a wicked product.