Zonealarm causes Wingate VPN headaches

[exile183]

I've been reading through this forum, looking for answers to my own problems in getting Wingate VPN to work, and I found more than a few people with similar problems: everything's set up right, tunnels are established, routes are published, but you can't ping from a machine on network1 to a machine on network2.

In my particular case, I finally figured it out. Zonealarm was the culprit. That sucker just will *NOT* get along with Wingate VPN (if running on the same machine as your Wingate VPN server). Even disabling it isn't enough, you have to completely uninstall it and flush it out of the system.

Once I did that (and changing nothing else), everything worked hunky dory.

Well, almost: can anyone riddle me this one?

My setup is something like this:

SERVER1 is at my home and hosts my VPN, called "The Interocitor". It has a LAN and I've installed the RIP client on all the machines behind it.

SERVER2 is at my office and it "joins" "The Interocitor" from there. Similarly, all the other client machines at the office have RIP clients installed.

All machines on either network can communicate with each other. PING, network shares, you name it.

But here's the fun part: I've also got a laptop, which I sometimes use in other locations. I've installed Wingate VPN on it and I can connect to "The Interocitor" on SERVER1 just fine. Once I do, I can talk to all the machines on network1.

But not network2.

In testing, I find that the client machines on network2 have received RIP updates, showing that to reach my laptop, they need to route via SERVER2. But SERVER2 (or SERVER1, whatever) isn't routing the traffic to me, nor is my laptop routing traffic back in response (to the clients on network2).

It's a bit of a pain. I can use some kludges to move data around, namely by logging into a machine on network1 and then FROM THERE initiating the things I want to do on network2, but it's painful.

Any suggestions?

[Pascal]

It's a bit of a pain. I can use some kludges to move data around, namely by logging into a machine on network1 and then FROM THERE initiating the things I want to do on network2, but it's painful.

The first thing to check is that the laptop and SERVER2 (The other joining machine) allows tunnels to be created to one-another. Secondly, check that they are on different private subnets (E.g. hoster on 192.168.0.x, SERVER2 on 192.168.1.x and Laptop on 192.168.2.x)

What would help in this case is if you could post (Or email directly) a screen-capture of the Network pane on the laptop with all the nodes and their routes expanded. That will give us an indication of why they cannot reach one-another.

[exile183]

Sorry for the delay in replying to your reply (and thank you for the quick initial reply). Been rather busy: it's tax season. :-)

OK, I've written up a detailed response, including screenshots and whatnot. Instead of cluttering up this BB with it, I've placed it here:

http://www.interocitor.net/pascal/

If you could be so kind as to have a look there, I'd appreciate it - as well as any ideas you might have in resolving this little problem.

[Pascal]

Sorry for the delay in replying to your reply (and thank you for the quick initial reply). Been rather busy: it's tax season. :-)

Wow. That is a very comprehensive report :-) I'm still working through all of that, but the first thing to just check is:

On the Joining VPNs (JOEYSLAPTOP and BOARDROOM) make sure that they have "Allow tunnels to/from all nodes" setup, and are not configured to "Only tunnel with Master Node".

=== Addendum ======

That actually looks right. There is one tunnel reported "In Stasis" though ...

[exile183]

Joining VPN's: are set up as you say, with "Allow tunnels to/from all nodes". All three machines (including the Master) have Local Participation set to "Local Network".

In Stasis: yeah, that seems to happen from time to time (not always, just sometimes), but even when it says that, the tunnel seems to be active anyways. I use "RAdmin" for remote desktop work, and even when a tunnel is in stasis, I can still connect across the VPN and administer a machine on the other network. Indeed, it's a nifty feature of RAdmin that's letting me work around this VPN problem (somewhat): I can set the RAdmin server on ZATHRAS to allow "connect-through", so while I'm using LAPTOP, I can "connect-through" ZATHRAS to reach machines on the BOARDROOM LAN (even while "in stasis" shows). But I can't do other stuff, like accessing network shares on the BOARDROOM LAN while road-warrioring on LAPTOP, and vice versa.

[Pascal]

Here's another idea ... I'm not sure what connecting devices you have on either end (JOEYSLAPTOP and BOARDROOM) but both seem to be NATting traffic to and from the VPN. Do you have the appropriate pinholes setup on those devices for 809 TCP and 809 UDP ?

[exile183]

Pinholes: at the ZATHRAS end, yes. I'm using IPCOP on another machine, which is a Linux firewall setup. Works like a hot-damn.

At the BOARDROOM end, I was *NOT* - I didn't think it was necessary, given that BOARDROOM initiates the contact with ZATHRAS (and BOARDROOM's public IP is dynamic). I had thought that traffic from LAPTOP would travel to ZATHRAS and then ZATHRAS would route it over the existing VPN connection to BOARDROOM, and vice versa.

However, to be safe, I've just gone in and adjusted the settings at BOARDROOM - the NAT/firewall there is a D-Link wireless router. I've opened up the appropriate holes and directed everything to the correct IP. No dice - no change, although I just took a look at the Gatekeeper on all three machines and none of the tunnels are "in stasis" anymore, they're all "active". Still, no successful routing.

This really feels like something's set up badly (or malfunctioning) at ZATHRAS, which is at the heart of this whole thing.

[exile183]

PS - sometimes these consumer-grade NAT/firewalls don't handle port forwarding very well, so I've just double-checked.

From JOEYSLAPTOP, I can ping the BOARDROOM router at 142.173.182.131 just fine. I can also:

TELNET 142.173.182.131 809

When I do, the screen clears and the cursor blinks in the upper-left corner, indicating a successful connection to something on that port. Whacking the ENTER key a couple of times (which was, once upon a time, known as the "Lotek Wak") causes a disconnect. If I try this on any other port, it just says CONNECTING TO 142.173.182.131.... and sits there for a minute or so before timing out.

So the pinhole is open. But I think we must already know that, since the Gatekeepers at both ends acknowledge that the tunnel between them is "active".

[Pascal]

LAPTOP would travel to ZATHRAS and then ZATHRAS would route it over the existing VPN connection to BOARDROOM, and vice versa.

Not quite - ZATHRAS will control who gets to control tunnels. BUT the tunnels are created between the client nodes and they communicate directly once the tunnels are established. So you would need pinholes to allow anything on 809 to foward in, TCP and UDP.

(But you said that has happened, so all good) I know you said pings fail, do the workstations show up as 'inaccessible' ? And can you browse them by IP (E.g. \\<ip>) or get a response by running nbtstat -a on them ?

[exile183]

Workstations are inaccessible - cannot browse by IP or name (there's a WINS server on ZATHRAS which lets me resolve names to IP's), and NBTSTAT seems unable to connect to the remote machines.

Question: could this be related to the fact that both ends are running under NAT?

BOARDROOM joins "The Interocitor" by connecting to ZATHRAS via it's public IP of 208.38.10.147. BOARDROOM's public IP is 142.1.2.3 (dynamic) but BOARDROOM has no way of knowing what it's public IP is. Similarly, ZATHRAS has no idea what it's public IP is. ZATHRAS only knows that it's at 192.168.47.4, and BOARDROOM knows that it is at 192.168.27.201.

So my question is this: when JOEYSLAPTOP joins "The Interocitor" by connecting to Zathras, you say that ZATHRAS acts as the coordinator and will tell JOEYSLAPTOP how to establish a tunnel to BOARDROOM. But does ZATHRAS know BOARDROOM's public IP? Is it feeding BOARDROOM's public IP to JOEYSLAPTOP, or its private IP? If the latter, that would break everything - but you'd also think that, in the examples shown earlier on that web page I built for you, that this would prevent the "active" tunnels being established between JOEYSLAPTOP and BOARDROOM. If that tunnel is really active, everything *SHOULD* be working.

[Pascal]

Question: could this be related to the fact that both ends are running under NAT?

Only if you don't have the pinholes.

(dynamic) but BOARDROOM has no way of knowing what it's public IP is. Similarly, ZATHRAS has no idea what it's public IP is. ZATHRAS only knows that it's at 192.168.47.4, and BOARDROOM knows that it is at

Until the socket connection for the control channel is established. Then, when you retrieve the IP address of the other side, you see it's public IP. By comparing that to what it told you it thinks it's IP is, you can work out if it is behind a NAT, and then tell it that.

[exile183]

Then that leaves us at square one. Why isn't it working? :-)

[Pascal]

Then that leaves us at square one. Why isn't it working? :-)

The million dollar question, because according to my calculations - it SHOULD be working. We setup something relatively similar in the QA lab yesterday, and it was working like a charm.

It shouldn't be a problem - (Not as far as we've been able to tell code wise OR testing wise) - but can you try disabling one of the two IPs on the same subnet ?

[exile183]

Pardon my ignorance but I'm not sure exactly what you mean.

[Pascal]

Pardon my ignorance but I'm not sure exactly what you mean.

Sorry, JOEYSLAPTOP has 192.168.99.110 and 192.168.99.111. Try removing one of the two, if possible ...

[exile183]

Oh sorry. Actually that was a temporary thing yesterday, I was having a little trouble with the wireless card so I jacked into the wired-side and wound up with two IP's. All of this happens when I'm only connected one way or the other as well, though I'll certainly test this again (it'll have to be in a few hours though).

[exile183]

And I now confirm - it's still broken while only connected with a single IP.

[exile183]

Pascal: it looks like I've RESOLVED these problems. Well, sorta - there's still one scenario that doesn't work, but I've found a workaround.

Again, rather than try to explain it here, I've created another webpage with some visual aids. It's here:

http://www.interocitor.net/pascal/