Comodo and Relakks

Help for v3
#1

I cannot get Comodo to work correctly with Relakks (a VPN). I’ve read through the tutorials on rules and based on a posting I came across, I’ve tried to get the following to work, where “Relakks” is a zone I created

Allow IP In From IP Any To In [Relakks] Where Protocol Is Any
Allow IP Out From In [Relakks] To IP Any Where Protocol Is Any
Block IP In/Out From IP Any To IP Any Where Protocol Is Any

Unfortunately this didn’t work. The application I associate with the rule gets blocked and posts an error message that it’s being firewalled.

Any ideas what the problem is?

#2

Greetings!

I don’t know too much about VPN’s, but it seems like the destination and source have been mixed.
Your current rules should act as your computer is the Relakks-zone, but Relakks is the proxy you want to connect to.

I think the rules should be:
Allow IP In From [Relakks] To IP Any Where Protocol Is Any
Allow IP Out From IP Any To [Relakks] Where Protocol Is Any

Also, you’ll need to create both application rules and global rules.

Cheers,
Ragwing

#3

Thanks for responding. I tried your suggestion and it still didn’t work. A screenshot of the firewall log is attached. Any idea what the problem is? Thanks.

[attachment deleted by admin]

#4

I’ve just looked at your CFP log, and I really don’t understand what’s going on. Meaning, you’ve got traffic that doesn’t make any sense.

This entry shows up several times: source address 0.0.0.0 destination127.0.0.1. That’s pretty much an impossible combination. The address 0.0.0.0 is a predefined address, used during DHCP address assignment. And it’s asking localhost to assign an address?? But the ports aren’t 67 and 68, but 1125 and 1126?

From what I’ve observed, I think that CFP is set to expect 0.0.0.0 to be used only in DHCP assignments.

If something is trying to run as some kind of proxy operation, rather than a source address of 0.0.0.0, I would expect it to be using instead 127.0.0.1. That way 127.0.0.0 port 1126 is talking to 127.0.0.1 port 1125. CFP would ignore that, or should.

I need to do some research on Relakks to get some sense of what it’s trying to do, and where that 0.0.0.0 is coming from.

#5

Is this the Relakks VPN definition that you’re working with? https://www.relakks.com/faq/guides/connectionxp/

If so, then it should be a normal PPTP VPN. CFP has no problem with that kind of VPN. I use that kind of setup in my dayjob. If this is what you’re using, then we need to work thru your Network Configuration to get you a working VPN, and then get CFP set properly.

If you’re using something else, then I’ll need a pointer to some information about the product.

#6

That’s what I’m using. The VPN seems to be working fine. I run into problems when I try to set up firewall rules.

I don’t know if it matters, but I running a virtual Parallels machine, Windows XP home edition, and I’m behind a Linksys router.

Thanks for the help.

#7

Alrighty. First off, what’s the IP address assignment for your VPN connection? You should be able to get the information from a command prompt, with the “ipconfig /all” command. That will define your VPN network zone.

The rules that I have, go like this:

Action: Allow
Protocol: IP
Direction: In/Out
Source Address: Zone[VPN]
Destination Address: Zone[VPN]
IP Details: Any

Action: Allow
Protocol: IP
Direction: In/Out
Source Address: Zone[VPN]
Destination Address: Zone[Multicast] Where zone is address range 224.0.0.0 thru 239.255.255.255
IP Details: Any

Action: Block
Protocol: IP
Direction: In/Out
Source Address: Zone[VPN]
Destination Address: Any
IP Details: Any

Action: Block
Protocol: IP
Direction: In/Out
Source Address: Any
Destination Address: Zone[VPN]
IP Details: Any

Those last two rules are my dayjob limitations that keep all traffic within the dayjob VPN (no Internet surfing thru the link). If you change the Block to an Allow, you’ll be wide open to the Internet, inbound and outbound, which is probably not what you want to do right now to get CFP set up properly.

#8

Thanks for this information. Do you have these set up as global rules?

#9

Yes, global rules. Sorry for not mentioning that.

#10

One more rule, which should be up at the top of the global rules, is one to allow DHCP address assignment to complete.

Action: Allow
Protocol: UDP
Direction: In/Out
Source Address: Any
Destination Address: single IP 255.255.255.255
Source Port: a port range 67-68
Destination Port: a port range 67-68

The VPN will be trying to do DHCP address assignment. Without this rule, you’ll get a VPN connection, but nothing will work. I was reading back over my rule list, when I recognized this is outside the VPN address range, and so is not covered by the other rules I just posted.

#11

Still not working. My global rules and the event log are attached.

[attachment deleted by admin]

#12

Here’s the global rules

[attachment deleted by admin]

#13

There needs to be a change in your global rules.

The last two rules you have are both “block and log”. These are the two rules that are causing the problem. They should be replaced with the following:

Since it seems from the CFP log that you’re going thru the VPN to get out to the Internet, the rule needs to allow that traffic to go out. Responses will be let back in automatically, but unsolicited traffic, like malware probes, will be handled later.

Action: Allow
Protocol: IP
Direction: Out (and only Out, you don’t want to allow just anything In)
Source Address: Zone[Relakks]
Destination Address: Any
IP Details: Any

The last rule (block IP in/out from zone[relakks] to zone[relakks] where protocol is any) isn’t doing anything, as the existing global rule 3 which allows all such traffic, comes before this rule. This last rule should be something like this:

Action: Block
Protocol: IP
Direction: In (because you don’t want anything coming in that isn’t a reply)
Source Address: Any
Destination Address: Zone[Relakks]
IP Details: Any

The global rules are read in order from the top down. The first matching rule wins. If you read your CFP log, you can take the source and destination addresses to eyeball check against each rule. If the addresses match, then you can check the protocol. If everything matches up, then you get a rule hit, and the allow or block will determine what happens to your packet. Not too hard, once you get the sense of how it works.

#14

Things are now working. The applications are not blocked when I’m logged on to the VPN.

Unfortunately, they are also not blocked when the VPN is not running. I had hoped the rules would block access if the VPN was down. Needless to say, I’m confused. Here’s a screenshot of the log with the times of each event. I logged off the VPN at about 4:40. What is the significance of the 1st entry in the log? I think it’s the only one that came up after I disconnected from the VPN. Thanks.

[attachment deleted by admin]

#15

You evidently have a router, and so a regular LAN that is connected to the Internet. The rules we’ve been working with so far on address the ability to get traffic thru the VPN. LAN traffic isn’t changed by the VPN rules.

That first entry in the CFP log, is your machine getting a new IP address from your router. That’s normal, and in fact necessary for your machine to connect out to the Relakks service to use the VPN.

The overall networking sequence will go something like this.

You boot your machine. Your machine gets an IP address from your router. Your machine can now go outbound to the Internet to connect to the VPN server.

You connect to the VPN server. The VPN server gives you a VPN address, and you get a tunnel thru your router out to the Internet. Meaning you now have two addresses: your router address, and your VPN address.

Traffic flows, within the tunnel using your VPN address, to and from the VPN server. Traffic is carried by the router IP address.

You disconnect from the VPN server. You loose the VPN address. You still have your router address.

Either you reboot your machine, or the router IP address comes up for renewal. If renewal, then you’ll see the DHCP address assignment handshake on the 255.255.255.255 address.

From your log, it looks like your router assigned LAN address is 192.168.1.102. Normal private LAN address space, common with Linksys routers as I remember.

Your VPN address was 192.168.158.25. Private address space, assigned by the Relakks VPN server. A fairly typical address assignment.

Traffic flowing on a VPN is sometimes described as a packet within a packet, like these nesting dolls that can be found in a gift shop. Or a postal mail envelope within another postal mail envelope. The outer envelope is between you and the VPN server. The inner envelope is used by the VPN server, like a postal mail forwarding service.

Does that make any kind of sense, or have I confused things more?

#16

Your comments make sense and are enlightening. Thanks very much for the education.

Can I now build on the rules so the traffic is cutoff if I lose the VPN connection?

#17

Yes, sure can. If I’m understanding what you want to do is to limit all Internet access so that it all goes thru the VPN, then it should be fairly straightfoward. Not exactly the typical setup, but certainly do-able.

If my understanding of what you want is correct, the additional rules will be something like this.

There are two separate network conditions that have to handled. One is for your LAN, so your PC can talk to your router. The other is restricting what leaves your PC, so that only traffic goes over the VPN.

One potential problem here, is that there isn’t a switch to flip (VPN on, do this. VPN off, do that). To do that kind of switching is to set up different CFP configurations. Different rule sets, and you’d have to do the switch manually. The details are in CFP, Miscellaneous → Manage My Configurations. Online help can give more details.

For the LAN traffic to and from your router, you’ll need a network zone defintion for MyLAN. You probably already have one, that CFP detected when it was installed. With that zone defined, you get these two rules:

Action: Allow
Protocol: IP
Direction: In/Out
Source Address: Zone[MyLAN]
Destination Address: Zone[MyLAN]
IP Details: Any

Action: Allow
Protocol: IP
Direction: In/Out
Source Address: Zone[MyLAN]
Destination Address: Zone[Multicast] Where zone is address range 224.0.0.0 thru 239.255.255.255
IP Details: Any

If you notice, these rules look exactly like the rules for the VPN. Just the network zone is different.

Now to restrict your PC to avoid talking to the Internet. There are some things needed from the Internet, so that at a minimum you can connect to the VPN server. So we need to punch some holes in the rules. To do that, we need to define a set of “Needed Ports”. Click Firewall → Common Tasks, My Ports, and Add a new set, called “Needed Ports”. Then add these ports

53 - needed for Internet name lookup
80 - web browser, so you can get to the outside world for help
443 - web browser secure connections
1723 - the VPN tunnel port, used by the PPTP protocol

You may need more, but we’ll find that out from the CFP logs. If the log says a needed port got blocked, just add that port number to the list of needed ports. But you need at least these to start with.

Action: Allow
Protocol: TCP/UDP (both TCP and UDP protocols need to be set, not just one or the other)
Direction: Out
Source Address: Zone[MyLAN]
Destination Address: Any
Source Port: Any
Destination Port: a set of ports: “Needed Ports”

Action: Block
Protocol: TCP/UDP (both TCP and UDP protocols need to be set, not just one or the other)
Direction: Out
Source Address: Zone[MyLAN]
Destination Address: Any
Source Port: Any
Destination Port: Any

Note the order of these two rules. Let out what we want, and block everything else. The direction is Out, because we’re catching traffic outbound from your PC. If things are being blocked and you get a problem, change the Block rule to an Allow rule, and that should get you reconnected. That’s a hazard with a block-all type rule.

Because things sometimes don’t work quite right, some server somewhere may need to tell your PC that “we’re down, try again later”. These are ICMP error messages. There are a lot of these, but only a few that we need to be concerned with. Since the rules for these are all the same, except for the detail, I’ll give a template:

Action: Allow
Protocol: ICMP
Direction: In - since it is from some server out somewhere
Source Address: Any
Destination Address: Any
ICMP Detail:

And the detail is “Port Unreachable”, “Host Unreachable”, “Time Exceeded”, “Fragmentation Needed”, and “Net Unreachable”. That’s 5 rules.

That’s 9 rules in all: 2 for the router, 2 to restrict your PC, and 5 for the error messages.

Does that do what you’re wanting to do?

#18

Thanks once again. I take it this last of rules are to be used instead of the earlier rules in this thread, ie the earlier rules are replaced entirely. Is that correct?

Let’s say that I want to restrict just one application to the VPN. Everything else could operate in an unrestricted fashion. Could I just link this latest set of rules to the app rather than making them global?

#19

No, these rules are in addition to, rather than replacing, the earlier global rules.

The global rules are working, after these 9 rules, in three sections: a VPN section, a LAN section, and a Internet section. The primary difference being the destination address, in what network zone traffic is being allowed out.
If you group all the rules together, and then sort out by destination zone, it may be a little more apparent what each rule set is trying to do.

It is possible to restrict one application (or a group of applications) to the VPN. It’s a little bit more complicated, given the way that CFP works with global rules and application rules. Both get applied, but which comes first depends on the direction of the packet flow. Global rules face the Internet, and so get used first for traffic coming into your machine, but are the last rules applied for traffic going out to the Internet. Application rules, working within your PC, get applied after the global rules for inbound traffic, but are applied first for outbound traffic. Borrowing the diagram from the on-line help:

  Internet ----- global rules -----  application rules ------ PC

Inbound from the Internet going to your PC: first global, then application rules.

Outbound from PC going to the Internet: first application, then global rules.

With that understanding, you can structure your application rules to allow only selected applications to use the VPN. Application rules, like Global Rules, are processed in order, from the top down. The application rules would be ordered something like this:

windows system (to allow the admin and networking connection to the VPN)
svchost (more VPN admin)
your application that needs the VPN
ping and any other network debug utilities than test the VPN working
a VPN blocking rule for all applications
the remainder of your applications that use the LAN and talk to the Internet.

As you can see, it’s more than just adding, or editing, an application rule. The order in which things happen matters a lot.

It may sound a bit awkward, but would go fairly quickly with some trial and error in moving things around in the application rules. I can also guarantee that you’d get very good at reading CFP logs :smiley:

#20

I’m making progress thanks to you.

I’m trying to optimize Azureus. It appears to have a NAT problem. When I run the NAT test, it says it can’t connect to 89:149:227.157:8118 (the IP of my VPN server and the Azureus listening port). But the rules are set up for the VPN IP assigned to me by the VPN server, ie 192.168.158.8. So I’m confused again. Do I need a set of rules to allow the server IP through as well?

My current rules are attached. What value should I have for [VPNGate]? Do I need another set of rules?

Thanks.

[attachment deleted by admin]