Link to home
Start Free TrialLog in
Avatar of Codeonesysadmin
Codeonesysadmin

asked on

Cannot connect to SQL running on a VPN Client, watchguard 1250e and Watchguard VPN CLient

We have a client VPN server that simply runs Win XP pro, all updates.  On this server is a master SQL DB that our program accesses.  The program is installed on 15 to 20 computers in this customers office.  The reason we have a VPN client installed on this server is because we use SQL replication to update that DB with ours.  This all works fine, and the VPN seems to work perfectly.  The problem is when we turn on the VPN the customer's computer can no longer access the SQL DB on our Server.  Shut it off and everything works fine, but we lose our connection for replication.  I have verified the packets are simply being ignored when the VPN is turned on.  Packets leave the customers workstations and never get a reply.  On the server there is no incoming packets from that workstation.  I used WireShark to watch the packet traffic.  UDP Port 1434 is open on the server with and without the VPN being on.  I have been on the phone with Watcguard to their engineers and so far no-one has come up with a solution.  

Help?!
Avatar of dpk_wal
dpk_wal
Flag of India image

I think there is a zero route tunnel (0.0.0.0/0) [configured with option "Force all traffic through tunnel"] and not split tunneling implemented as a result the machine loses all local network connectivity.

Can you elaborate on the type of VPN configured (IPSec/PPTP).

Please provide details.

Thank you.
Avatar of Codeonesysadmin
Codeonesysadmin

ASKER

This is the first thing everyone suggests.  we do not force all traffic through tunnel.  IPSEC is the configuration we are trying to use.  there is no 0.0.0.0/24 in the routes.  Good first guess.
Also let me add that the server and workstation can still browse each other, shares and all.  We Remote desktop to each just fine with and without the VPN being turned on.  So far it seems only SQL Server is effected on port 1434.
Just to clarify as I understand:
WG X1250e is acting as VPN server [lets call it network A]; MUVPN client is installed on XP Pro machine which is hosting DB server [lets call it network B].
Before MUVPN is turned on, on network B other machines can access the DB server on XP machine, after VPN is enabled then the local machines on network B cannot access DB on XP machine.
At the same time with VPN enabled, can other machines on network B RDP to XP machine, or ping it or send any traffic.
Also, from network A after VPN is established, you can access XP machines from all the machines. Can ping/RDP or sync DB.

If such is the case, can you check the routing table before and after VPN establishment; do you see any changes in routing table, use command: route print [from command prompt].
Also, what is the IP subnet on network A and network B.

Please provide details.

Thank you.
Your understanding is correct, to clarify point sin question.  When VPN is enabled (Turned on and connected) Computers in Network B can access the DB server by means of pings, Remote desktop, browsing network neighborhood etc.  From Network A, when VPN is enabled we can ping, remote desktop, and browse the server.  Subnet A is 192.168.207.0  Subnet B is on the 192.0.0.0.  I've attached a Screen shot of the route prints.  The first or top run of the route print is with VPN On the bottom half is without the VPN connection.
Screen shot, sorry it didn't attach to previous comment
Route-Prints.bmp
Everything looks good; so when VPN is connected only DB does not work; can you run sniffer (like wireshark) and sniff for packets on the XP machine for DB port/protocol from one specific client with VPN connected and not connected.
This would give a clear picture as to the difference between the two cases.

I was earlier thinking this of as routing problem; but now it looks more of application/system issue.

Please mask two octets of all public IP address and MAC addresses, if you post anything on this thread.

Please check and update.

Thank you.
I've sniffed for packets on the DB server, the odd thing is nothing ever shows up when the VPN is on.  I have specified, IP, Ports, and protocols, and nothing ever appears to come through as expected.  By this I mean specifically from the workstation trying to access SQL.  Ports 1434 (UDP), 1028 (TCP), and 135(TCP) are usually used when a SQL call is made. Other traffic is clearly visible.  Turn off the VPN and these ports come alive and SQL works fine.  It's seems the traffic is being ignored, or being thrown into the tunnel with no place to go?  I've run the WireShark on both the virtual adapter and the hardware adapter and still never see the traffic.  I did get an update from Watchguard that they are handing the case off to NCP-Client for a possible Bug Fix.  They will need to replicate the issue.  I have replicated it twice now with different remote servers.
As I have been under extreme pressure to get a resolve to this issue, I tried a SSL VPN to this box.  Everything works perfectly all around.  The problem is now we will have to upgrade our Firebox to get more SSL Licenses unless I can figure out the IPSEC Mobile VPN problems.  an odd FYI to this story.
One last thing, can you check the IP address at which the XP machine listens for request before and after VPN connection; netstat -na; netstat -a; netstat -nb [from command prompt]
If the IP address at which the server listens changes, then this might explain as to why the packet is not seen by sniffer.

I am running out of ideas as to the root cause of problem! :(

Need not send the output; please update on the result.

Thank you.
Ports that disappear from No VPN to VPN being turned on are:

1807, 1824  sqlserv.exe
1810 TCP
4102 netbios-ssn
1825 TCP emap

I believe sql server and sql browser service broadcast their existence on port 1824.  This allows you to browse to the SQL database rather than have to know the connection string.  Our program is configured to know the connection string.
ASKER CERTIFIED SOLUTION
Avatar of dpk_wal
dpk_wal
Flag of India image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thanks for the effort.  Seems we are stuck and Watchguard is stuck as well.  We are probably going to use the SSL VPN until a bug fix is released.  Thanks again for the help!