dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
2584
share rss forum feed

stevemayman

join:2012-12-31
San Diego, CA

Strange VPN Access Problem

Had a simple Win 7 VPN running fine for years with an equally simple Win 7 client. Both server and client using whatever defaults you get when clicking the Windows "New ..." wizards and walking through.

Suddenly, a few months ago I could no longer log in from home. Odd thing is I can still log in fine from the same laptop if I use my neighbor's WIFI instead of my own.

Must be something on my home router/gateway right? But what? We got IPTV (U-verse) this fall as we do every fall, but that has never been a problem in past seasons. I changed from WEP to WPA2 but then attempted to connect with an Ethernet connection and it still didn't work so I temporarily ruled that out as the problem.

Anything obvious that could be causing this? If not, how can I go about troubleshooting? (reading logs, etc?)

Thanks, and Happy New Year!

Steve


HELLFIRE
Premium
join:2009-11-25
kudos:12

Is your VPN server and client on the same LAN connection, because that's the way you make things
out to be, unless I'm wrong.

Are you connection to a domain name or IP address for the VPN? Any possiblity the IP address changed
unexpectedly or is not resolving correctly?

Any sort of error message(s) popping up during a connect attempt?

I'd DEFINATELY look into whatever logs are available on the VPN server itself (if they are logging)
and if it's even seeing the connect attempts.

Regards


stevemayman

join:2012-12-31
San Diego, CA

No, client and server are on different LANs. I am connecting through a DYNDNS domain name but that doesn't seem to be the problem because it resolves fine if I connect to my neighbor's WIFI network instead of my own.

Just to be clear, my server is at the office. I try to log in through my home wifi connection. Get 800 error. Connect to my neighbor's wifi. Can connect to VPN. Reconnect to my home wifi, Get 800 error again. And it used to work from home with the same hardware.

I'll try to check the office server logs next time I am back in there. I'm a novice so I may ask for help in locating them if I can't find them.

Thanks for the quick reply!

Steve


HELLFIRE
Premium
join:2009-11-25
kudos:12
reply to stevemayman

a) check the name resolution of the dyndns name via the connection it's working, and the one it's not

b) do a ping test to said name from both connections, also run a traceroute. Make sure your traffic
is able to make it to it, or however far it goes.

c) do a telnet to said dyndns name on port 1723 from both connections... does it show OPEN, or open a blank
black screen from window's cmd prompt?

d) grab the full 800-error and post it up here. Also try running it thru your search engine of choice. Never
heard this one off the top of my head, but ANY sort of specific error message is ALWAYS helpful for troubleshooting.

Can't tell you where'd Windows would keep the VPN logs, you may again have to do some knocking around on
the internet for this information.

My 00000010bits

Regards


stevemayman

join:2012-12-31
San Diego, CA

Great! Exactly what I needed.

I can't ping the DYNDNS server on the failing connection. A traceroute produces the following:

Tracing route to *******.kicks-ass.org [174.65.14*.***]
over a maximum of 30 hops:

1 2 ms 1 ms 1 ms 192.168.1.254
2 22 ms 23 ms 21 ms 99-71-140-3 .lightspeed.sndgca.sbcglobal.net [99.71.140.3]
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 20 ms 23 ms 23 ms 12.83.70.141
...
13 41 ms 41 ms 41 ms 68.6.11.186
14 42 ms 40 ms 43 ms dt1xcmtk03-gex030000.sd.sd.cox.net [68.6.11.185]
15 * * * Request timed out.
(time out repeated another 10 or so times...)

Telnet connection failed on 1723.

Error 800: The remote connection was not made because the attempted VPN tunnels failed. The VPN server might be unreachable. If this connection is attempting to use an L2TP/IPsec tunnel, the security parmaeters required for IPsec negotiation might not be configured properly.

I had done quit a bit of research on Error 800 and tried a dozen different solutions to no avail. Hence the "start at the beginning" approach I am trying now. One intriguing solution was that the ISP suddenly started blocking GRE for one user, but isn't that a server side issue? Should I check with my ISP (AT&T) to see if they are doing this at my home?

I can't test the working connection right now because the one I was using is no longer up. I can try from my neighbor at work when I get back there later in the day.

Thanks for the great help!

Steve


stevemayman

join:2012-12-31
San Diego, CA
reply to HELLFIRE

Ok, from the working WIFI connection:

Tracing route to *****.kicks-ass.org [174.**.***.***]
over a maximum of 30 hops:

1 2 ms 1 ms 1 ms 192.168.1.254
2 19 ms 11 ms 10 ms 108-248-100-3.lightspeed.sndgca.sbcglobal.net [1
08.248.100.3]
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 12 ms 11 ms 10 ms 12.83.70.141
7 13 ms 14 ms 25 ms la2ca02jt.ip.att.net [12.123.30.189]
8 64 ms 13 ms 13 ms xe-9-2-0.lax30.ip4.tinet.net [77.67.79.173]
9 13 ms 14 ms 13 ms xe-5-0-0.lax20.ip4.tinet.net [89.149.182.194]
10 13 ms 13 ms 14 ms cox-gw.ip4.tinet.net [216.221.157.54]
11 29 ms 29 ms 28 ms fed1dsrj01-ae1.0.rd.sd.cox.net [68.1.0.205]
12 29 ms 29 ms 28 ms fed1sysc01-tec300.rd.sd.cox.net [68.6.8.1]
13 30 ms 30 ms 30 ms 68.6.11.186
14 29 ms 28 ms 29 ms dt1xcmtk03-gex030000.sd.sd.cox.net [68.6.11.185]
15 104 ms 96 ms 82 ms ip174-***-***-***.sd.sd.cox.net [174.***.***.***]

Trace complete.

Telnet port 1723 opens a blank black screen.

Where do I go from here?

Thanks!


HELLFIRE
Premium
join:2009-11-25
kudos:12
reply to stevemayman

said by stevemayman:

Telnet connection failed on 1723.

versus

said by stevemayman:

Telnet port 1723 opens a blank black screen.

plus the error tells me potentially at a layer 3 or layer 4 level, traffic is not making it to
said VPN server from the nonworking connection. I also kind of find it interesting comparing
the traceroutes that on the nonworking one it stops at 68.6.11.185, while on the working one
it goes one further to your 174.x.x.x IP address.

Just to ask, is the ***.kick-ass.org / 174.x.x.x address resolving to the IDENTICAL IP address
on the nonworking and the working connections?

Thoughts on how to go at this point :

a) get sniffer software setup on a PC that can move between the nonworking and working connections.
Run it when trying to connect and save both files for review. Wireshark is a good option here.

b) get said sniffer set up on the Win7 end, or someone watching traffic incoming from the internet
while you connect. Does it even make it to the demark point where the Win7 VPN server sits?

Regards
Expand your moderator at work

stevemayman

join:2012-12-31
San Diego, CA
reply to HELLFIRE

Re: Strange VPN Access Problem

Yes, the URLs are resolving to identical IP addresses. The long delay was because I was discussing the situation with my ISP. (AT&T U-verse) and they said that they don't block 1723 or 47. They sent me a new gateway and told me to try it with default settings right out of the box. Still no joy...

Anyhow, I'm afraid that the last part of the post went over my head. I downloaded Wireshark but wasn't sure how to configure it to get meaningful results.

Do I capture only the IP address of the PC that I am moving between connections?

Do I change any of the other Option defaults?

Do I start the capture, try to connect to the VPN then stop after failure?

I ran a capture and it spit out lots of color-coded lines that were meaningless to me, even before I tried to connect...

Do I filter the results before posting them?

Thanks, and sorry for the newbie questions!


HELLFIRE
Premium
join:2009-11-25
kudos:12
reply to stevemayman

- do a capture of a working VPN connection, and a nonworking VPN connection. You will want to compare the two.

- the general options I configure are "capture in promiscious mode," Display options -- all checked, and Name
Resolution - 1st and 3rd options checked.

- start the capture BEFORE connecting to the VPN, but AFTER a failure. Again, you want to see AT THE PACKET LEVEL
what is going on.

- if you can, run a few test captures before doing an actual one. It'll help with understanding how the program works.

My 00000010bits.

Regards


stevemayman

join:2012-12-31
San Diego, CA

downloadVPN Connecti···apng.zip 57,588 bytes
Failed
downloadVPN Connecti···apng.zip 96,933 bytes
Connected
Ok, attached are the two Wireshark files. I started the captures just before attempting the connection and stopped just after the connection or failure notice. I perused them, but there are so many entries and I don't really know what I am looking for so it was a bit of a needle in a haystack.

I tried a traceroute again with very similar results. It seems very odd that it makes it 14 hops before the connection fails. I would think it would fail before it even left the gateway on the client end, or as the communication from the VPN server was blocked by the gateway as the reply was blocked when it arrived back here.

It just drives me crazy when things work for years then suddenly stop for no apparent reason. I am completely out of ideas on this one!

stevemayman

join:2012-12-31
San Diego, CA
reply to HELLFIRE

One other thing I just noticed: I just ran a bunch of tracerts for kicks to both the URL and IP address and each time the request times out after 68.6.12.95 which ends with SD.SD.COX.NET.

Curious because my office has Cox as our ISP and it is of course in San Diego. My guess is that the request gets to the door but can't get into the building.

This makes it seem like the office gateway is blocking the request. But if it is blocking the request from home, why isn't it blocking the same request from the neighbor? Could it have anything to do with DHCP on the client side, or client side IP addresses?

I can't see how my neighbor is set up, but I could experiment with settings at home. (I already have, but it has been random to this point...)

Thanks!


HELLFIRE
Premium
join:2009-11-25
kudos:12
reply to stevemayman

Click for full size
Click for full size
Took a look at your captures here, so here's what I find.

For VPN Connection Failed.pcapng, if you open and set your filter to "ip.addr==174.65.109.156," you
can see the following. Your PC's making a connection to the VPN -- in INFO it says SYN, which means
your PC wants to make a connection and is asking to start the connection. Problem is NOTHING is seen
back from 174.x.x.x to complete that request to start the connect from 174.65.109.156, which also
correlates what you told me earlier, namely

said by stevemayman:

Telnet connection failed on 1723.

For VPN Connection Worked.pcapng, this is what a working connection is supposed to look like.
In the INFO column, you see a SYN/SYNACK/ACK for the first three packets, which indicates the
TCP 3way handshake completed successfully. After that, all the normal VPN negotiation stuff
happens and you're off to the races.

Going from here

a) this tells me your VPN is going to the same IP address from the working and nonworking connections,
so that rules out DynDNS as the culprit.

b) you're going to have to run a simultaneous capture from the Win7 PPTP box and do troubleshooting on
that end to see why it SEES AND PERMITS a connection from your neighbor's house but not the other location.
I don't know what could be blocking it, and truthfully without access to that part of the puzzle, we're in
speculation mode.

Regards

HELLFIRE
Premium
join:2009-11-25
kudos:12
reply to stevemayman

...BTW, my bill for this work on a Saturday will be coming to you via registered mail

Regards


stevemayman

join:2012-12-31
San Diego, CA
reply to HELLFIRE

Thanks! I'll take a look with the filter and see if I can make heads or tales of any of it. I'll also run the simultaneous capture from the office as you suggest, but the logistics of it mean that it won't be until next week. I will also make an effort to figure out the results and fix it myself before I post again, but as you can tell I am in over my head.

Thanks again for all your help!


stevemayman

join:2012-12-31
San Diego, CA
reply to HELLFIRE

No kidding! That's about $600 worth of tech support. One thing I have learned is that expert help is expensive, but expert help from someone that actually knows what they are doing is REALLY expensive!

said by HELLFIRE:

...BTW, my bill for this work on a Saturday will be coming to you via registered mail

Regards


HELLFIRE
Premium
join:2009-11-25
kudos:12
reply to stevemayman

If you want to learn more about wireshark, two books I'd recommend are Wireshark Network Analysis (Chappell and Combs),
or Practical Packet Analysis (Sanders) for a start. After that it's doing alot of captures and playing with the tools on your
own to learn the program.

Happy troubleshooting on the VPN!

Regards


stevemayman

join:2012-12-31
San Diego, CA

Solved!?

So, it took a while before I could go home during the day to try to log in from home while someone was here to do the Wireshark server capture. And...it connected! Of course it would not connect again that night, or the next night, or the next night.

This proved to be the pivotal clue. I started thinking it might have something to do with time or the fact that someone was here (at the office) rather than being a problem at my house.

Today my wife is home for MLK day, so I asked her to try to connect while I started the sniffer. Connected again. This time I actually shut down the office and walked out. Sure enough it would not connect.

I went back in, went through the morning routine. It connected again!

It turns out that a network switch between the gateway and the VPN server had accidentally been plugged into a switched outlet! When we turned the lights out at the end of the day, the network switch went off, and the signal could not get from the gateway to the server.

I have not yet confirmed this by successfully connecting at night, but I am 99% sure that was it.

Thanks so much for your help. It lead to the solution even though it was not a technical one in the end. It also provided me with some good knowledge and troubleshooting tools.

Steve


HELLFIRE
Premium
join:2009-11-25
kudos:12
reply to stevemayman

said by stevemayman:

It turns out that a network switch between the gateway and the VPN server had accidentally been plugged into a switched outlet! When we turned the lights out at the end of the day, the network switch went off, and the signal could not get from the gateway to the server.

Keep us posted if it was the problem or not. After finding that I'd probably have a few choice four-letter explitives
I'd want to use, but sometimes it's the dumb things....

Regards