• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Weird TS Issue

K

klesik

Weaksauce
Joined
Nov 20, 2007
Messages
69
Hi everyone! I've been reading a lot of posts, but haven't actually written too many myself. I am looking for some help with an issue that has me scratching my head. I have a client which has a remote office connected via Untangle's Point to Point VPN to their main office which is also on Untangle. Their main office is on a static IP connection on Comcast, and the remote office is on a static IP but on FiOS. They are using an LOB application which is deployed via Terminal Services Web Apps. We were fine up until a few weeks ago when our issue started.

The problem is that we will be running at the remote office just fine until randomly everyone's remote session will freeze and lock up for about 3 minutes. Then it reconnects and continues working as normal for about half an hour or so. Then it repeats this timeout problem again. At first I thought it was something on the server - we're running an ML150 G6, Server 2008 Standard, 6GB of RAM, for about 6 users. But I have laptops connecting at the main office via TS and they don't experience this issue at all. Nor do any of the other users at the main office. So the issue is related to a WAN connection it seems.

Has anyone experienced something similar? I've already asked the ISPs to check our lines, and they are fine apparently. I've put the TS Server's IP onto as many bypass lists as I could in untangle so that nothing is checked and filtered by the Untangle apps. Any help would be greatly appreciated!!

Thanks!
 
I have seen this a while ago and it was a process eating up all the CPU
 
Had almost the exact same issues running packet filter (pf) on OpenBSD boxes in stateful mode for internal connections - changed it to no-state on all internal routing and problem went away.
 
Innocence said:
Had almost the exact same issues running packet filter (pf) on OpenBSD boxes in stateful mode for internal connections - changed it to no-state on all internal routing and problem went away.
Click to expand...
Sounds like cargo-cult IT.

Besides that you've massively increased CPU load and latency compared to stateful filtering, something else might've been seriously wrong and you merely eliminated the symptoms.

Topic: How about running ping at the remote office continuously for a day to verify latency and (lack of) packet loss? No use doctoring around on servers if the basics are already amiss.

Edit:
I've put the TS Server's IP onto as many bypass lists as I could in untangle so that nothing is checked and filtered by the Untangle apps.
Click to expand...
But you know what you're doing, right?
 
Last edited:
Thanks TCM. I do know somewhat what I'm doing in Untangle. I've run it in multiple locations already. To your suggestion of running a continuous ping at the remote office - I did do that for about two days actually and we did come back with fairly high pings every 15 minutes or so. But it would always be once during a ping test and then run fine for the next 15 minutes. Plus I had Verizon confirm that the line is good to go as well.

Good idea though!
 
I agree with the suggestion that you ping for a day and capture the results. And verify the time interval exactly. Also, pull the logs for the firewall and vpn.

My impression is that maybe the vpn devices are doing a key exchange, but something is going boom during the process which causes the delay while each side tries the various fail modes. I've seen similar symptoms with openvpn, and while it's almost always a key exchange issue the resolution each time was different.
 
TCM said:
Sounds like cargo-cult IT.

Besides that you've massively increased CPU load and latency compared to stateful filtering, something else might've been seriously wrong and you merely eliminated the symptoms.
Click to expand...
Yeah, that peak load of 2.7% CPU usage is really killing our systems. Not to mention the huge load of reviewing a whole 6 rules before doing a quick in/out. :rolleyes:

It's only stateless for INTERNAL routing, and the trouble was that the connections were getting state key linking mismatches due to a somewhat paranoid way that PF works with the reuse of mbufs and key timeouts with UDP. So we could either increase the global timeouts for all connections and open up to big old holes, or just make the internal routing stateless. Apparently this is fixed in CURRENT, but waiting for next major release to test.
 
You must log in or register to reply here.
Back
Top