Problems and problems and problems

Forum for all technical support and trouble shooting of the WinGate VPN.

Moderator: Qbik Staff

Problems and problems and problems

Postby ajdionne » Dec 17 03 11:04 am

I hate to be negative but that is it. I have somne questions tha require answer

a) Why can I access all my network except for the wingate server which always comes up with unavailable. I can remote desktop all worksation attach to that subnet the remote desktop to that server from that workstation. Bizarre. Routing??

b) On the VPN client with ens enabled I cannot get ip address from corporate DHCP server.

I had a working network before upgarding to 5.2 Your new release has solved some problems but I think your routing schemes still has bugs.

I need to get this thing going fast because my boss are breathing on my neck.

Regards
ajdionne
 
Posts: 35
Joined: Dec 11 03 7:18 pm

Postby Klaus » Dec 17 03 8:33 pm

Hi,

you have near the same problems like me before with the new version

http://forums.qbik.com/viewtopic.php?t=683

If you are logged in your VPN - how many Active Tunnels you see under GateKeeper ? If you only see 1 than this could be the problem as I had.

Greetings
Klaus
 
Posts: 5
Joined: Dec 16 03 6:30 am

Tunnels

Postby ajdionne » Dec 18 03 4:03 am

Thank you for your help.

There is actually 2 tunnels with the same number. Out from laptop to server and from server to laptop.

One thing that gets me and it is probably alright is that the channel 809 is use both way. Perhaps that is one of the problem?

I am thinking to downgrade the laptop to the 1.0 version and give it a try.

In regards to DHCP address assignment to laptop. We are using a puplic address 161.XXX. and I had to make the adapter trusted. It puzzled me because that as for effect to disable firewall.

I got to this point so far by enabling on the server the 3 box in regards to rip. On the laptop on the listen box is mark. I could finaly connect to network with this configuration. Except that I cannot remote desktop the server as it is mark as unaccesible.

We stop using wingate past version 4.2 when problems started. We are giving it a chance now. But it seems I am going back to same trend. One working version to an upgrade full of headache. This should be simple to setup.

I need some answer fast because we want to sell and use this VPN to access computer around the world

Regards
ajdionne
 
Posts: 35
Joined: Dec 11 03 7:18 pm

Postby Klaus » Dec 18 03 5:30 am

Hi,

I can reproduce my problems. If I install 1.2.2 VPN Client, than I have the problem which I wrote in my thread. If I uninstall the client and use the 1.0.6 ( Build 820 ) than I can access the Lan without any problems.

Bad that there is no official help in this forum, so I will check now other VPN Software.

Bye
Klaus
 
Posts: 5
Joined: Dec 16 03 6:30 am

Re: Tunnels

Postby Pascal » Dec 18 03 7:47 am

ajdionne wrote:One thing that gets me and it is probably alright is that the channel 809 is use both way. Perhaps that is one of the problem?

...

network with this configuration. Except that I cannot remote desktop the server as it is mark as unaccesible.



Using 809 both ways is not a problem, that's fine. Can you ping the server using it's internal IP Address ? That is the first indication that the tunnel is working, if you get a proper ping response. The VPN is a routing based solution. So you have to ensure that the routing is correct in both directions.

Secondly, the accessible state is determined by a NETBIOS query. You need to be sure that Windows networking is properly setup and running on the server. So - does the server have other computers connected to it ? Or is it a standalone machine ? (It sounds as if you are on a network)

You can check if this is all working by running the following command from the VPN client:

nbtstat -a <server internal ip>

where <server internal ip> is the internal address of your server.

Can you browse to machines behind the server ? Are they all marked as accessible ?
Pascal

Qbik New Zealand
pascalv@qbik.com
http://www.qbik.com
Pascal
Qbik Staff
 
Posts: 2623
Joined: Sep 08 03 8:19 pm
Location: Auckland, New Zealand

Reply to Pascal

Postby ajdionne » Dec 18 03 8:43 am

Thank you for your reply

Note: Wingate server is at address 192.168.1.1 (internal NIC) and 192.168.160.100 (external NIC

a) Can ping 192.168.1.2 but not 192.168.1.1
b) Can Remote desktop by loging in on 192.168.1.2 and remote desktop server at 192.168.1.1. Netbios name are seen and seem to be resolved. Server is senn as unaccessible by VPN. What is interresting is that address 192.168.1.2 is O.K. Why not the server?
c) Since upgrading to 1.2.2 it stop working from my old version 1.06.
d) Where can I download 1.06 version. I have only version 1.1 which I reinstalled but for now being at work have to get home to get encryption keys. The configuration was lost with reinstall.
e) Positive sugestion - When uninstalling why whipping of licence and VPN configuration. Does it also with ugrading?

Note 2: I got version 1.2 partialy working by checking Send local rip2 update, Enable Rip2 listener and pusblish route on the server.

On the client only listen to rip2 is check is this correct. I found that any other combination allows connection but prevent browsing.
ajdionne
 
Posts: 35
Joined: Dec 11 03 7:18 pm

Re: VPN Problems

Postby Pascal » Dec 18 03 8:50 am

ajdionne wrote:Thank you for your reply
Note: Wingate server is at address 192.168.1.1 (internal NIC) and 192.168.160.100 (external NIC


1. The external NIC is marked as "Public / Untrusted" in the WinGate configuration, correct ?

2. Can you resolve the NETBIOS names across the VPN link, or only from the local network ?

3. Uninstalling removes everything related to the application from your system. It cannot preserve things like license keys and so on. An upgrade should be fine though, that simply updates the changes.
Pascal

Qbik New Zealand
pascalv@qbik.com
http://www.qbik.com
Pascal
Qbik Staff
 
Posts: 2623
Joined: Sep 08 03 8:19 pm
Location: Auckland, New Zealand

Postby adrien » Dec 18 03 10:01 am

Hi

It sounds like there may be some route publishing issues left over from a previous install.

In earlier versions of the VPN, we would write all published routes to the registry.

In version 1.1. onwards we only write those routes that are not using the default behaviour -i.e. it is an override only.

It is possible that we see some earlier routes as an override on the previous default behaviour.

Also, we had some problems with ICMP created routes which we fixed in 1.2.2 which could cause route conflicts.

I would recommend you try that latest version on the server you are having issues with at least. It is compatible with versions 1.1 onwards, but we would recommend you eventually upgrade each end, since there are other fixes you would benefit from.

Adrien
adrien
Qbik Staff
 
Posts: 5441
Joined: Sep 03 03 2:54 pm
Location: Auckland

The saga continue...

Postby ajdionne » Dec 18 03 12:32 pm

O;K Guys

First I want to thank all your team to make an effort to resolve issues. I have staterd with version 3 and I know that qbik make gerat effort to come up with a good product. We are evaluating your product as that we are installing it on any window server and it is only, i was hopint, easier to configure and look after the VPN

Pascal
1. The external NIC is marked as "Public / Untrusted" in the WinGate configuration, correct ?

Yes for the server no for the client because it was preventing it to get a DHCP address

2. Can you resolve the NETBIOS names across the VPN link, or only from the local network ?

No for the wingate server yes for machine on the same subnet

3. Uninstalling removes everything related to the application from your system. It cannot preserve things like license keys and so on. An upgrade should be fine though, that simply updates the changes.

O.K but not in my case....

ADRIEN

"It sounds like there may be some route publishing issues left over from a previous install. "

When i tried to resolved issued this weekend I cleaned up all trace of Wingate in registry and reinstalled 5.2.2 on server 1.2.2 on client. Only Monday when I decided to lite up a cigarette and check and uncheck those setting did it work to the point that I am now

"I would recommend you try that latest version on the server you are having issues with at least. It is compatible with versions 1.1 onwards, but we would recommend you eventually upgrade each end, since there are other fixes you would benefit from. "


Problem started since I have upgraded...... 1.2.0 and 5.2.0 which you issued an other update 5.2.2 for the same issues we are dealing with...

Regards
ajdionne
 
Posts: 35
Joined: Dec 11 03 7:18 pm

Postby adrien » Dec 30 03 2:33 pm

Hi

Just checking back - wasn't clear from your last post whether you had resolved any issues or not.

One thing I thought I should clarify, is the meanings of the three RIP options.

1. Send Local RIP updates.

This setting means that VPN routes learned from other VPN nodes are published via RIP on the local network. This means that other machines running RIP listening software will learn the routes to the other nodes on the VPN, and therefore presumably be able to access them. The Qbik RIP client was written to enable normal windows workstations to benefit from this to automatically configure routing for the VPN, which can otherwise be problematic. We also recommend that if the WinGate VPN gateway is not the default gateway for the network, that if there is a RIP listener on the machine / router that IS the default gateway for the network, that this be turned on, thereby enabling the whole network to benefit from learning these routes.

2. Enable RIP listener

This setting was conceived to handle the case where there is another RIP sender on the network, and you want the WinGate machine itself to be able to learn and use these routes. In this case, the built-in RIP client will ignore broadcasts sent by itself as per 1. above.

3. Publish Learned routes on VPN.

If for instance you have another VPN gateway, or another router to other subnets that sends RIP broadcasts, then by enabling this setting, you can allow the rest of your VPN to learn of these other local subnets.

So for 99.99% of users, they will only need (and want) the first option to be selected.


Adrien
adrien
Qbik Staff
 
Posts: 5441
Joined: Sep 03 03 2:54 pm
Location: Auckland

Postby adrien » Dec 31 03 1:26 pm

Hi

One more thing regarding not being able to access the WinGate server itself.

This would indicate to me that WinGate ENS driver is not seeing outgoing packets properly from the local WinGate server machine.

This can happen if you are using 802.1p priority tagging on your network adapter on the WinGate machine, as then outbound frames from this machine would not be seen as IP frames, and then not hooked.

This setting is a property of many common ethernet adapters, and you can turn it off.

Adrien
adrien
Qbik Staff
 
Posts: 5441
Joined: Sep 03 03 2:54 pm
Location: Auckland

Follow up to Adrien last reply

Postby ajdionne » Dec 31 03 4:21 pm

Happy New Year!!

What a beautiful country you live in. The Lord of the Ring really does a great job in showing that.. I wish you all at QBIK a great prosperous 2004 year. I know that your team are working hard to deliver an excellent product. You also have a great tool with this forum to resolve software issue.

Your two last replies have clarify some of my questions. As a matter of fact your explanation on RIP is a must read.

I still have the same problem with the wingate server being unaccessible.

I was waiting for your reply to my last posts. Since then here is my take on the problem.

Of course I have been looking for the past week at the Wingate forum as well as the VPN.

I "think" I know were is the problem area. It is with the NAT portion of the program and the way it creates route. If you make any change to the Extended Network driver settings from any choice, you have to recreate the VPN hole every time. The warning does mean something!!

If the firewall setting are set to high it does cause problem with VPN access were you cannot access anythin anymore even with administrator right.

If you change say from medium (example) to no firewall some ports that are suppose to be open stays close . If you look at the wingate forum some of the posting are around that issue.

Honestly I stop playing with settings. I can access the server by remotly accessing one of the workstation on my test network and then remotly accessing the wingate server( slow.....). I am kind of hoping that someone with more advance knowledge of NAT and routing will point your team to the problem and you will issue a new release.

If I create route with route command they disapear on next boot up so I kind of find that useless.

I also discovered that the administrator may get lock out on wingate server (check mark on disable account) if a) the XP policy is set to lock out account after xx attemps b) your wingate access user name and password is not the same as the overall workgroup user name and password. You must use same user name and password.

There is something that has changed from 1.07. I know that this matching version of Wingate and VPN did work well until upgrading. There is something in the latest releases that does not give full administrative privilege if you are coming from a different network through the VPN.

So I am waiting for next release. The VPN portion is very inexpensive and would like to install it on our future release of our HMI. Perhaps you may look at just creating the VPN server and client without DHCP, ENS, DNS so it can be used with a third party application firewall.


Regards
ajdionne
 
Posts: 35
Joined: Dec 11 03 7:18 pm


Return to WinGate VPN

Who is online

Users browsing this forum: No registered users and 22 guests