RAS client inside Sonicwall fails to connect to RAS server outside.

We have a customer who is letting us access thier network in order to support thier sites over their wan.  They have provided us with a user name and password for this.  When I set up the VPN Network connection from the wiindows control panel and make the connection through a Linksys "home" router it works perfectly.  If I change my connection to the Sonicwall TZ190 firmware version SonicOS Enhanced all I ever get is failed authentications.  

I have to admit that the Sonicwall setup is a bit beyond my comfort zone.  I have poked around policies and I beleive that what i need is there but I am not too sure...

I did do two wireshark captures, one with each router connection to try to compare the two.  There isn't much difference between them except for the failure response on the one vs the accepted responce to CHAP.  There is more in there that I am missing.

I have explored the MTU size solution I found on this site but I believe that our customer would have to adjust thier settings in order to make that a valid test.  Is that correct?

Anybody have any ideas as to what to try?    Capture files availble on request.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

When you're setting up the VPN, I presume you're using windows authentication and passing it through to their DC as you use an RDP session?

If that's the case, try manually setting the client use PPTP. I've had to do that for all connections to SonicWall clients.
Ross_at_CSLAuthor Commented:
It did not help.  Looking at the packet capture I see where the two sides negotiate and settle on a PTPP connection.  Then it tries the authentication and it fails.

Please note that I am NOT trying to connect INTO a sonicwall firewall, I am trying to connect out through one.
The TZ190 does have a wizard for creating VPN connections like you're seeking; have you tried using the wizard to set up the connection type?
Your Guide to Achieving IT Business Success

The IT Service Excellence Tool Kit has best practices to keep your clients happy and business booming. Inside, you’ll find everything you need to increase client satisfaction and retention, become more competitive, and increase your overall success.

Ross_at_CSLAuthor Commented:
This is starting to get clearer to me.  This is the reply from thier server to the authentication when connected through the firewall.

Message: E=691 R=1 C=63BFC7AAFEE440C25A6D20FDE1CF3BDC V=3

Bad unsername or password.  BUT the same username and password WORK out through the Linksys.  I just reverified that.
That is... odd. Perhaps you need to add the domain name to the logon?
Does the Linksys have a default domain applied as part of its DNS structure? I'm starting to wonder if it's appending that DNS information and letting the authentication occur where the SonicWall isn't...?

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Ross_at_CSLAuthor Commented:
We might be on to something here.
Chap Challenge with Linksys
PPP CHAP      Challenge (NAME='INFO-VP1', VALUE=0x2FB697830290AA98577FBA9A09D77366)
Chap Challenge with Sonicwall
PPP CHAP      Challenge (NAME='SOLUTIONS', VALUE=0xEEC777F785D7A939FBFD31D8D35447ED)

INFO-VP1 is our customer's Rem.Acc. Server.  SOLUTIONS is ours.  The packet is marked as coming FROM our customers IP, not ours.

Is the Sonicwall Reflecting the VPN connection BACK into our own server?
Ross_at_CSLAuthor Commented:
BTW, this was helpful because this is the packet right before the client transmits the user name and password WITH the domain.  You made me take a second look to discover that we might be hitting the wrong domain.
Ross_at_CSLAuthor Commented:
Found the problem.  Someone (I think it was our support contractor) had created a NAT loopback policy inside our Sonicwall that did point our connection back at our server.  Infact there were 4 of them, 3 enabled.  Once disabled the connection was made to our customer.
Thanks for making me look more closely at what I had.

Now to figure out why there were there and what we have that is no longer working because I turned them off.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.