Simple MS VPN (PPTP) help needed

Help for v3
#1

I am new to understanding the workings of firewalls and just got rid of ZA in favor of CFP (several benefits already). I am trying to get the VPN working in v3.0.25.378. I have been through the forums for awhile now and am even more clueless than when I started. I am trying to run the basic MS (XP sp3) VPN – WAN miniport (PPTP). I start it up, it connects fine, and it then shuts down all my internet traffic (yes, I understand that MS routes all traffic through a connected VPN by default – I’ll deal with that later when I get the basic VPN working). There are no pop-ups from CFP asking me what to do, the traffic just stops. Without the firewall the VPN works. With the firewall nothing works and there is no logging information that I can find so that I can start to configure CFP for the VPN. I’m very frustrated!

How in the heck do I set this up? There are enough posts about VPNs that I was hoping someone would have written a basic step-by-step how-to-setup this for the manual, but I cannot find any. So, I’m requesting some help or a set of instructions on how to get this up-and-running. I’m not completely computer illiterate and I find it hard to believe that I’m the only one having this kind of difficulty. Thanks in advance.

#2

Welcome to the forums, makevpnwork!

From my own experience, I’ve found that having a network monitor like Wireshark (www.wireshark.org) is invaluable at finding out what’s going on.

Since I’ve worked with PPTP VPN’s and CFP, I’ve got some clue as to what’s involved. I think. Maybe. ;D

First question: Are you connecting to a remote machine, or is a remote machine trying to connect to you? Direction can make difference in what CFP rules are needed.

Second question: A PPTP server will provide a dynamic address to the connecting remote machine. Do you have any idea what that address range might be? The ones I’ve worked with have been in the 172.16.x.x space, but just a local site preference.

For CFP rules, lacking the details to those two questions, follow a basic outline like this:

allow IP In&Out from zone[VPN] to zone[VPN] where protocol is any
allow IP In&Out from zone[VPN] to zone[Multicast] where protocol is any
block&log IP In&Out from zone[VPN] to any
block&log IP In&Out from any to zone[VPN]

Note those two block&log rules isolate VPN traffic to only VPN addresses. No Internet browsing thru the VPN. I’m not clear if that is something you’ll need or not. If you do, that’s what you’ll need. If not, ignore the two block&log rules.

Also note, these VPN rules don’t address the connection to the VPN server, using port 1723/tcp. That rule depends on the direction, whether you machine is the remote client to someone-elses server, or if your machine is the server.

#3

Thanks for the quick reply grue155.

This is a remote machine (notebook) connecting to a server behind a hardware firewall (NetGear FVS318). The addresses allocated, I believe, are 10.10.11.xxx (10.10.10.xxx is used on another system).

Are [VPN] and [Multicast] address ranges?

I had no idea that this would be such a pain … thanks again.

#4

Believe it or not, PPTP is the simplier VPN setup. You really don’t want to go near an L2TP/IPSec VPN unless you have to. (But then, if you have to, you really really need that kind of VPN security)

Yes, [VPN] and [Multicast] are address ranges. We’ll need to set these up as CFP network zones.
To do that in CFP, click Firewall → Common Tasks, My Network Zones. The Add → A New Network Zone. All you do here is give the new zone a name. There are two zones, so two names.

The for each new zone, there will be a line under each that says “add addresses here”. Right-click that line, and select Add.

For the VPN zone, we’ll take the wide view, and use an IP address mask of 10.10.11.0/255.255.255.0. That will cover all addresses from 10.10.11.0 thru 10.10.11.255

For the Multicast zone, we’ll use IP address mask again, with 224.0.0.0/240.0.0.0. That will cover all addresses from 224.0.0.0 thru 239.255.255.255. Multicasting is a weird beast. It’s like a write-only address, needed to make some things work. Best to define it, and not need it, than to leave it out, and wonder what is is that is keeping things from working, sometimes.

Since your machine is a remote client to the VPN server, you’ll get assigned an address by that server when you get a connection. That uses the standard DHCP protocol, thru the initial stages of the tunnel setup. So, we will need to allow traffic to the DHCP broadcast address of 255.255.255.255.

So, in your Global Rules, you’ll have these rules at the very top, and in this order (CFP processes rules from the top down, first math wins. So order matters, a lot)

allow IP In&Out from any to singleIP[255.255.255.255] where protocol is any
allow IP In&Out from zone[VPN] to zone[VPN] where protocol is any
allow IP In&Out from zone[VPN] to zone[Multicast] where protocol is any
block&log IP In&Out from zone[VPN] to any
block&log IP In&Out from any to zone[VPN]

That should be enough to get you connected to the VPN server.

Note these rules don’t do any firewalling within the VPN. If you trust the LAN the VPN server is on, and what the LAN is that the server is making available to you, then these rules are likely enough. If you have the possibility of an attack/probe from another VPN client, then some more rules will be needed.

The blocking rules, as I mentioned earlier, keep the VPN traffic to the VPN only. Your LAN can’t talk to the VPN, and the VPN can’t talk to your LAN. And you can’t go thru the VPN to reach the Internet. To do any of that, the blocking rules need to be changed.

Does this make any kind of sense?

#5

Yes, this is becoming more clear - thank you for your patience.

For the Multicast zones, is 224. … 240. … is that an example range or an actual range? If it is an example range then how can I determine the needed Multicast range on my computer?

#6

For multicast, those are the actual real live numbers.

The actual real live range for multicast is 224.0.0.0 thru 239.255.255.255.

Expressed as a network mask notation, the base address is 224.0.0.0 mask 240.0.0.0 (the 240 just happens to be a coincidence. Of the 8 bits in a byte, we’re keeping only the top 4. The bit pattern is 0xf0, or 11110000, which is the decimal number 240 for us poor humans)

If you’re into confusing reading, I’ll refer you to http://en.wikipedia.org/wiki/Multicast and to http://en.wikipedia.org/wiki/IP_multicast

#7

Thanks grue155 - last time I dealt with hex was on an HC-11 awhile ago.

I am making some progress. With the 10.10.11.xxx addresses in for the VPN the mail service (pop3) is working, but the browser is not. I am going to go offsite in a few minutes to test the VPN access itself again. The 10.10.11.xxx addresses are the addresses of the network on which the server I’m connecting to resides. The actual address I am VPNing to is a static address. Does that address need to be in the mix somehow also?

#8

The static VPN server address is outside the VPN. Otherwise you couldn’t get to it over the Internet. So normal Internet access rules used by CFP would apply.

If pop3 is working over the VPN, the basic VPN itself is working. That the browser is not, would imply that the browser is trying to access something outside the VPN address space. That’s very likely being caused by the two blocking rules that I gave.

Easy way to check, is the CFP firewall log. Click Firewall, Common tasks, View Firewall Events. See what’s blocked. That means probably adding a rule (or more), or relaxing the blocking rules.

#9

Now I think I’m going backwards. I looked at the VPN connection window and it indicated that ~30 Kb had been sent, but less than 2 Kb had been received. During that time I sent out an email with an attachment that was ~200 Kb that was returned to me (I sent it to an address that had this address as a forward). So I am not quite sure if the VPN is working for the email any longer. What made me look there was that neither browser that I tried (Opera or IE, latest versions of both) worked (check connection error messages) and neither use logged anything in the Firewall Events. Actually, there is nothing in the Firewall Events (neither disable logging box is chosen in Settings > Logging and the size is 5 Mb).

So now I’m curious. The email and browsers didn’t work before I added the rules you suggested, now the email works (but doesn’t seem to affect the VPN send/receive statistics), but the browser doesn’t work.

Thank you again grue155 for sticking with this. Very helpful and reassuring.

#10

Alrighty, a quick reality check. With the rules that I’ve outlined, only addresses in the 10.10.11.x address space are reachable thru the VPN.

So, that means that DNS lookups may be going over the Internet, and trying to look up private host names that aren’t accessible to the Internet DNS servers (I’m a LAN admin on the dayjob. One security tactic often used is to have a public facing Internet DNS server, and an in-house private DNS server. Folks on the Internet have a tough time trying to reach something that they don’t know about. I use that tactic, and it works very well.) You may have to specify the DNS servers your VPN client connection is supposed to use, if the VPN server doesn’t provide the proper addresses.

Also, testing mail may or not work, if the address isn’t correct. That DNS thing again. Easy check for that, is to use telnet to get to the pop3 server. Can’t do much, but you will verify the connection, thru the VPN.

From a command prompt, “telnet pop3.ip.address 110” where the pop3.ip.address is in the 10.10.11.x range. If you get a connection banner, you’re in. If you get that banner, then type “quit” and the connection will close.

You can do the telnet bit also with port 80, just the stuff you have to enter is very different. Raw HTTP, messy, but it works, and would confirm the VPN connection.

#11

Well, telnet got me the “OK Comodo …” pop3 proxy connection with the VPN connected. It didn’t get any further.

I didn’t seen any options for setting up the VPN to direct any DNS lookups.

#12

You’re running Comodo Anti-Virus (CAV) on your machine? If so, you connected to the email proxy running on yourmachine, and not to the pop3 server on the other side of the VPN. Email proxys are supposed to intercept traffic transparently, but the difference shows up in the banner. The only Comodo pop3 I know of is a virus scanner proxy. You could turn off the anti-virus, and see what happens then with a telnet. I suspect the banner will be different.

There is a way to check the DNS stuff. With the VPN connected (or presumed connected), from an command prompt, enter “ipconfig /all” and see what the DNS server addresses are. The VPN may be providing one. If it is, the DNS server also needs to be in the 10.10.11.x range. If it’s provided, but not in range, then a CFP rule change is needed. If not provided, then some connection properties may need to be set (a longish chain of menus to go thru).

#13

Yes, I was. I disabled the CAV and I got the header from the email server; however I was not able to get the file off of the server through the VPN still, nor is the browser working when the VPN is on. Something is really weird. Thank you again for your assistance.

#14

It looks like things are getting to the point where a network monitor is necessary. If we’re having to (effectively) guess about where a packet is going, then Lord Murphy will most assuredly point us in the wrong direction.

If you got the banner from the mail server, using telnet to connect to the VPN address of the mail server, then the VPN is working. So far, so good.

Now the question is, getting everything else to work.

With the browser, are you giving url’s by hostname (www.example.com), or by IP address (10.10.11.x)? Hostnames will probably be flakey, until the DNS stuff gets straightened out. Doing a url by IP will look odd, but for testing, it will confirm the browser working thru the VPN.

Probably for the time being, it’d be best to assume hostnames aren’t going to work, and that everything (for testing purposes, at least) will have to use IP addresses. That will confirm all the connectivity is in place.

And I’ll strongly suggest installing Wireshark, and watch the packets as they move around. That will tell you if what you think is happening, is really happening. Or if Murphy has gotten into the mix, and busily rewriting things.

I’m coming up on the end of my day here. I tend to get back on-line here about 1800 GMT. I’ll have to pick this up again tomorrow.

#15

'morning –
I have wireshark installed. Pretty neat to see all of the stuff going on in the background, most of which I don’t understand. However, I started up the VPN and this is what I’ve found so far: 1) VPN seems to connect using various protocols. 2) the protocol IP goes looking for an IANA site (224.1.0.38) and the info is Bogus IP header length (4, must be at least 20) with no response or ACK. 3) still, once vpn is connected the pop3 works, but the browser and the connecting to various files (i.e., going to server to retrieve file – the main purpose for the vpn) does not work.
I’m out until ~1400 pac. Any directions on what to capture and/or look for when I return? Thanks much again.

#16

Good with the Wireshark. You’re right in that there is a lot going on the background. VPN’s in general use a boatload of protocols, which is one of the things that makes setup a difficult thing.

The 224.1.0.38, is a multicast address. That’s probably the VPN server/client router details. Routing makes a lot of use of multicast stuff, which is why the CFP rule in place to allow it.

Good that pop3 works. Good old-fashioned simple protocol makes it easy to test, and actually see working.

Browsers on the other hand, can be different creatures. If that is what is having problems, then that what needs to be looked at. Wireshark can capture the traffic, which can be saved as a file. If you zip the file, you should be able to post it here. Then I can see the actual packet flow and what the browser is trying to do. And we go from there.

#17

I attached the file. It was saved in the wireshark format. It is (win-)zipped with a password. Is there anyway that you can contact me through COMODO and I can get you the password? I will be happy to continue to use this format for all other communication. I don’t know if there is much in there, but I am a bit nervous about posting to the internet these protocols, esp. when I am not sure what is going on inside them.

I forgot to add – I started up wireshark, then started the VPN, so wireshark should have captured everything. At about 194, after the protocols settled down, then I tried connecting to a folder on the server in hopes of transfering a file I need to this local computer. Didn’t work. I then tried the same thing using “Network Places” approach (with no hopes of improvement, but figured why not?). Finally at about 39x I started the browser (Opera) – it had a mess of windows open so there are lots of requests going out, but no windows refreshed to the current window (e.g., bbc news, google news, comodo forums, etc.).

[attachment deleted by admin]

#18

A forum personal message (PM) will do the job. Click on my userid, and you’ll get my profile. Along the left edge, there are Actions, one of which is “send personal message”. Standard web forum stuff.

#19

Got it. And a quick eyeball shows a huge amount of DNS queries, and no answers. That would make browsing a little difficult.

One thing I’m confused about, is what 192.168.1.1 is. I’m presuming it’s a router, but you’re showing Netbios queries inside the VPN (packets 95 and 101 thereabouts)

And packet 100 is a definite outbound HTTP close, from a VPN address to a non-VPN address. So those two trailing blocking rules I gave are doing their job. If those rules are set for logging, I’ll bet your CFP logs are really busy.

An example is packet 217. TCP SYN packet sent to destination port 80. Destination is 64.182.x.x, which is out on the Internet. The CFP outbound blocking rule is going to stop that. And no answer means it did get blocked.

I’m not seeing any HTTP traffic to an address within the VPN. That could be from the DNS confusion. If you’re trying to reach a machine thru the VPN, with the CFP blocking rules in place, then that destination machine has to have a VPN address. The Wireshark capture isn’t showing it. That’s a strong hint of where the problem is.

#20

Not quite stream of consciousness here, but posting as the thought occurs to me.

Your test machine is at VPN.22. DNS server is at VPN.4. I’m seeing a lot of queries from 22 to 4, but no answers back from 4 to 22.

Can you ping VPN.4? That would confirm that the server-side routing is all set up properly.

Assuming your CFP network zone is set as described, VPN.4 should be in the allowed range of VPN addresses. So packets should get there okay. But if VPN.4 doesn’t have it’s routing set properly, it’s answers back to you can’t get to you. And so all the DNS confusion.