Hi Guys, long time user here, had to re-register as my old email is no longer accessible. Yay
I have Comodo FW running (latest .7036 update on Win7 x64) on a sever I have that is used primarily as a Softether VPN server. I recently made some config changes to allow me to hit network shares, as well as RDP, on the same server running the VPN services.
While the VPN works as expected, and passes through say for internet browsing, RDP/shares to other devices, I cannot RDP (Or VNC for that matter) to the same box while the FW is enabled. Tried every rule/setting I could think of, including adding the vNIC MAC and IP allowed everywhere, but to no avail. At one point, I created a rule to allow everything everywhere, essentially rendering the FW useless, yet cannot connect to local resources.
While I can hit shares and RDP to other devices on my network through VPN, I cannot hit the box where VPN lives itself while Comodo FW is enabled on it. Having almost given up, I set the FW to disabled, everything works.
It seems something in the FW is preventing the Softether vNIC from passing network to the local interface/resources.
Maybe I am missing something, Iâm stumped at this point. Any ideas or suggestions? Is this type of thing a known issue? Or?
Thanks, this was an interesting line to follow. I did this, and it worked fine. I then re-imported my old rules set, left my normal global rules intact. I nuked just the app rules, and put into place the âAll Appsâ rules you mentioned, and it worked still.
So far, the global rules I had/have are functional, it is clearly something in the app rules. Now to figure out which old rule was the problem. Nothing jumped at me, but one of them must be the culprit. Any suggestions on what to look for?
Much appreciate the suggestion, very useful to narrow it down
Add the Application Rule for âAll Applicationsâ â âAllow IP In/Out From MAC Any To MAC Any Where Protocol Is Anyâ at the top of the Application Rule list.
Check if this works (it should, as you already tried, with the difference no deleted application rules this time).
If it works than do the following:
Now to find the (or a) culprit rule move (click and drag) the above added rule one row/line down in the Application Rule list and press OK and try again if it still works.
Keep moving the added rule further down a row/line at a time and than try again. When at a certain moment it doesnât work anymore than the rule on the row/line straight ABOVE the moved added rule is the (or one of) the culprit(s). Fix the culprit rule and remove the added rule and than try again if it continues to work. If not then repeat the whole exercise again (add the rule at the top, try it, move the rule down one row/line at a time, try again, etc.) to find another culprit rule and than fix it, remove the added rule and try again if it continues to work (etc. etc.).
You should be able to find all culprit rules in this way.
A bit tedious work, but it works. (I hope )
Create an application rule for windows operating system and set it to outgoing only ruleset and make sure it is the top most rule. If it still does not work then set it to the allowed application ruleset. Use browse > running process to select WOS from the list.
Thanks guys, really good advice. Luckily this server doesnt have a lot of app rules, so I re-ordered them in such a way that the most likely culprits are at the top now. I will create the aforementioned rules, check the result, and walkâem down as needed.
This did the trick. I had been using just âSystemâ previously, which is apparently not adequate in this case. Using the WOS process with its default assigned âout/blockâ rules, its accessible with all other Global and App rules in place.
I assume the default out/block rules for WOS are secure enough for general use?
EDIT: There used to be a guide around here somewhere that had suggested rules for SVCHOST, but Iâll be buggered it I can find it now. Is such a thing still around?
Thanks CISfan and Futuretech, all the assist is greatly appreciated