well after initially working, v2 is back to v1 tricks.
outpost suddenly decided to start blocking vmware.
lol.
logs at least now give a clue: "block transit packets"
this is similar to old v1 behavior.
even wierder, following the old tricks to make v1 work in this circumstance, i added a new system rule to allow all outgoing connections from 192.168.0.5 (this is my local lan address for the vmware). this shouldnt be necesary because i have already told outpost to trust this local lan 192.168.*.*
after adding this new rule, the vmware can connect out.
but surprise, after this rule, outpost starts applying other application rules in a very wierd way, almost as if it has switched into "deny most" mode, where all applications are blocked from connecting out silently unless a specific rule exists for them (ie rules wizard doesnt seem to pop up for anyone anymore, just blocks all traffic without an allow rule).
some of the bloom is fading from the rose...
just to be clear - there is a workaround that works - i posted it above, it consists of adding a system rule to allow all INBOUND only packets to the vmware ip. for now this seems to work without bad sideeffects, but the nasty behavior that occurs when you allow inbound and outbound to this ip make me suspect that there could very well be some sideffects to adding this rule. for now it works.
This page (http://www.practicallynetworked.com/sharing/troubleshoot/netbt.htm) covers enabling NetBIOS over TCP/IP. For Windows XP, TCP/IP should be used by default for NetBIOS - NetBEUI is unsupported although offered. I do not think it likely that this is the cause of your problems - but it is simple to check.
With regard to a list of known bugs and issues, I would agree. I know about issues that I raise and there is a special forum for Beta discussions. However we are working on a V2 FAQ and are posting known issues there (after other testers get a chance to review the post).
I do not have any further ideas - but maybe someone who uses VMWare with Outpost v2 can offer some other workaround.
Jamie3,
Are you using DHCP at all? The conditions under which I encountered the "Block Transit Packets" rule was when a DHCP lease expired and a network interface was auto-assigned an IP address in the 169.254.x.x range - Outpost would (in earlier beta versions) detect this as a new network and block all traffic to that interface - even including DHCP requests in earlier versions. Even if the proper IP address was regained, Outpost would block all application traffic but allow low-level ICMPs (so ping would work).
Now the release version of Outpost did not show this in my testing, but if VMware is using "virtual" network interfaces then that might explain the problems you are seeing - especially if you can ping from VMware but do nothing else network-wise.
If you have not already done so, disabling the "Auto-detect" in the System/LAN Settings dialog and deleting the networks listed may help. Assigning a permanent IP address to your virtual and physical network interfaces rather than using DHCP is another possibility. I do not use VMware myself so am only guessing here - but if these do not help or change the situation, then it would be worth emailing Agnitum on this.
i do not use dhcp - my vmware machine has a fixed address of 192.168.0.5, which is just an address on my lan.
i have tried disabling the 'auto-detect' mode for networks, and tried deleting the other two (other than the main 192.168.0.*) networks found by auto detect, with no improvement. i have also tried adding a specific entry for 192.68.0.5 on the network panel with no effect.
as i said, a working kludge is to add a system rule to allow all INBOUND connectins to 192.168.0.5. adding a rule to allow inbound and outbound connections to 192.168.0.5 will also work, except it completely disables wizard mode for all other applications and blocks every other app on my computer, for some completely inexplicable reason.
as far as emailing agnitum - please for the love of all that is merciful don't tell me that agnitum does not bother to read these forums - i'm hard pressed to conceive of a more disturbing piece of news in terms of having bugs fixed.
Hey
Can you explain a little more about your VMWare/Outpost config? I've been running V2 now for over 1 month and I havn't once had problems with VMWare.
I have made a rule for VMNAT.EXE and don't have to make any global rules at all. I trusted my local LAN where the VMWare sessions are running.
Rule as follows for VMNAT.EXE:
TCP Out Allow and activate statefull inspection
UDP Out Allow and activate statefull inspection
With V1 I trusted VMNAT.EXE
Also tried with 3 VMWare sessions at the same time, also no problem. Works with both 3.2 and 4.0 (I also never had trouble with VMWare and Outpost V1)
Atomic
Dwk,
Are you now using VMWare on your system? You did not mention this in your previous thread (http://www.outpostfirewall.com/forum/showthread.php?s=&threadid=8817) so if you are, then supplying some details of your VMWare setup would be a good idea for others to be able to offer workarounds.
If not, then your post is offtopic for this thread - and offers little insight to the specific problems discussed here. If you have new issues, please either create a new thread for them or post a follow up in one of the others that you started.
Since Outpost does detect IP address changes on most systems, I would suggest that something in your system setup is the cause. You did mention having TDIMon and TCPView installed previously - I would suggest (given the report by Godzilla in your thread) trying to close any background tasks also. Or stay with ZA if that is what works for you...
i havent been able to find a way around this, even after creating a new empty configuration ... i've no idea why it worked when i first installed outpost v2, but at the moment this is really making life painful.
I'm bumping this one up as I was encountering similar problems last night with the latest versions of OutPost and VMWare. I'm curious Jamie whether you got it working a little better now. I have yet to try what you mentioned as a possible solution but will try it when I get home tonight.
for sure this issue of blocked transit is vmware related. vmware network communication is confusing outpost. atomic - you are using "virtual network address translation (NAT)" in your vmware machines to handle networking, while i am using a different network mode called bridged networking. bridged networking is the default setting for vmware, which assigns a unique ip to the vmware machiens (with nat, as i understand it, the vmware machines share the ip of the host computer). so vmnat.exe does not get used in my case. the thing is, outpost "almost" handles it properly - it seems like its detecting the packets as coming from another computer on the network, but its blocking them from passing through.
Yeah, it appears if I create that rule for VMWare, Outpost will then block other connections which its set to let through. Remote Assistance would not work at all.
maybe i will try nat - i've always used bridged networking, which seems to be the preferred method. does nat let each vmware have its own dedicated ip? the nice thing about that is you can use normal protocols for connecting to and from the vmware machine - for example if you want to test ftp/p2p/telnet, webserver. etc.., you can connect to the vmware machine as if it were just another machine on the lan. from what i read of NAT it seems that the virtual machine is assigned an identical ip to your main machine, which lets it use the internet, but might make the other stuff infeasible. or am i wrong about NAT? anyway, like i said before, i have a workaround for this in agnitum, providing there are no other sideeffects (which i am not sure about yet), so this is not a major concern of mine at the moment.
unfortunately i cannot even use the latest agnitum outpost because it bluescreens my windows xp (see separate thread).
has agnitum fixed the problem in more recent version - no way to know since they dont describe very well the changed they make and they havent shown much interest in fixing this bug.
however, i do have a workaround, which does work, though it is imperfect.
i have added a system rule called "Allow Vmware" which allos all INBOUND traffic to my vmware ip address (192.168.0.5).
this allows my vmware to send and receive internet traffic as normal.
unfortunately, it completely buggers the ability to receive independent incoming connections to my machine from (ie if i run an ftp server, people cannot connect in to it). no idea why.
so anyway, i basically have to turn this system rule on when i want to use vmware to access internet, and off when i dont.
Aside from checking that your 192.168.0.* is a Trusted network (presumably you have done this), another option would be to clear the 192.168.0.* entry leaving your LAN settings window blank. When you say that "every other app" is blocked, can you still run a ping or tracert (if tracert can run - but its DNS lookups get blocked - then you have the Transit Rule bug for sure).
These forums are run by volunteers - Agnitum do read them but obviously cannot follow every thread - especially when things get busy like now :) so important issues are best pointed out in an email.
im not sure about an option to choose netbui or netbios over tcp/ip (using winxp pro). the only thing i can see to choose in my network configuration is whether to enable netbios - if its disabled, the lan becomes inaccessible.
as far as 1000 bugs being fixed...
here's a suggestion (another poster asked for similar information): agnitum should post with new releases a list of 1) bugs fixes 2) outstanding issuse not yet resolved. at least then we will have some idea that agnitum has a todo list and it wont be so much of a mystery as it was with v1.
thanks for the advice david - after reading the other post i thought for sure that once i added the 192.168.0.5 address for the vmware bridged network it would work, but alas same problem.
however, i did find a temporary fix: if i add a system rule to allow INBOUND connections (only) to 192.168.0.5, then the vmware machine can get in and out, and i dont have the crazy effect of outpost blocking every other app that happens if i add the system rule to allow inbound and output to 192.168.0.5.
(note i keep saying 192.168.0.5 - this just happens to be the network addressi configured for my vmware virtual network).
Hm,
On the issue of support, I have had nil/nothing/totally-poor support from Agnitum. I have logged several bugs, sent log files etc and always zero response from them. Yes, I am a paying customer. If they don't even have the courtesy to respond to customers then I'm rather surprised to hear that they read this Forum. Forum people far exceed Agnitum's pathetic support efforts, and I suspect that if it wasn't for the Forum, they would lose even more customers.
Perhaps there is a clue in this information that they fixed 1,000 bugs before releasing OP 2. 1,000 is a HUGE number of bugs and therefore I am now less unsurprised that there seem to be plenty of bugs left over for users of OP2.
It is an excellent suggestion that there be a list of bugs things that Agnitum is working on. Would save everyone heaps of time. It could be limited to paying customers if they wanted to restrict access.
I have just extensively tested Zone Alarm on mys system and note the following:
a. ZA correctly and automatically detects a dynamic IP change on my ADSL. OP2 has to be exitted and restarted- there's nothing automatic about it despite their advertising blurb.
b. ZA NEVER died even once in three weeks on my WinMe system, whereas every day or so, OP2 dies with the wonderful message "Some problem happened...."
c. OP2 is easier to use than ZA and the logging and setup are better. However, these benefits soon disappear if your system becomes disabled in the middle of the night because the IP changes or "Some problem happened..."
Until they fix the occasional deaths of OP2, it swould surely be possible to introduce a watchdog process that restarted OP2 if "Some problem happens".
Dave
My apologies.
Wrong place (I am not using VMware).
the reference to Agnitum reading this forum and the 1,000 bugs before OP2 was released set me going.
Dave
well, unfortunately, it turns out that allowing inbound only has a bad effect.
if you add a system rule to allow outgoing connections to my bridged vmware, it will then allow these packets, BUT the side effect is, it blocks all other apps in rule wizard mode, silently.
i though i found a solution to allow all inbound traffic to this vmware ip, because the rules wizard now seems to work.
however, it turns out that allowing inbound traffic to the vmware ip will disable the rules wizard from coming up on new incoming connections (ie to a ftp server), and blocking such incoming connections.
SO, for agnitum developer's here is a summary of the problems:
1) traffic to and from a vmware bridged network virtual machine is blocked by outpost 2, with the reason "blocking transit"
2) you can get around this blocking by adding a system rule to allow all traffic inbound or outbound to the vmwares ip, BUT this has the effect of blocking the rules wizard from ever popping (inbound or outbound as you configure the system rule), and such connections that would normally bring up the wizard otherwise are simply blocked silently.
having to add a system rule to allow all traffic to the vmware ip seems to me a good solution to vmware, so i think the real bug for agnitum to fix as soon as possible, is this bug where the presence of the new system rule is preventing the rules wizard from coming up as it should. this doesnt seem like it should be so hard to fix,
AND most importantly:
im guessing that nearly everyone can test for this bug, simply by adding a new system rule that says to allow inbound/outbound traffic to some made up ip (try 192.168.0.x), and see if your rules wizard comes up when it should. i dont think you need vmware or a lan to test this bug (though i could be wrong). im guessing its a general purpose bug in the system rule application.
Hey Mark
I've been using Outpost for 1½ years now, and never had trouble with VMWare and I've been using that just as long.
jamie3 could have a specifik setup, but 2 of my friends are also using Outpost and VMWare and it's also working fine for them.
Atomic
Hi jamie3,
This probably will not help, but you might check this thread out:
OP v2+dialup+auto config network (http://www.outpostfirewall.com/forum/showthread.php?s=&threadid=7244)
root or Paranoid2000 may also be able to provide some input here. I know for sure that root has dealt with this issue. The only comment that I can provide at the moment is that the host machine, with Outpost, will get rules creation popups for PCs that are networked through it. These are the "transit packets". The best thing to do may be to setup any necessary rules manually and reboot.
I believe it may be possible to work through this particular issue. So, please be patient as it may take a little time. Also, later Agnitum may allow willing users to add bug reporting capability to Outpost V2 which may expedite a more permanent fix. It would be something similar to the debug utility. Anyway, that is as much information that I can offer to you at the moment.
Have a good day. :)
Hi Jamie
I tried just now using bridged networking in VMWare instead of NAT, and I get the same results as you, I'll try and find out if this is a bug or by design and get back to you.
But for now why don't you switch to NAT when that works? Is there something you in your config that specific rerquires bridged networking?
When I'm using Nat I can both connect to local LAN and internet from my VMWare sessions without any problems with both Outpost V1 & V2.
Atomic
Good luck with the network settings. Whoops...just caught your post saying they did not work - if you are using Windows Networking with NetBIOS, are you running NetBIOS over TCP/IP or are you using NetBEUI?
Although I don't work for Agnitum, I do feel that they have made a serious effort to address bugs that are found. Over 1,000 were fixed in the beta test program itself. However, Outpost is never going to be bug-free for everyone - and Agnitum made the decision that the current version was in a good enough state for release - especially considering that v1 had a number of problems for people (could not support ICS, failed an increasing number of leaktests, did not allow for Fast User Switching).
The development process is still continuing (I have received notification of a new beta version) so I am confident that the remaining known issues will be addressed. Agnitum are not resting on their laurels.
I do not know how many beta-testers were using VMware, but if you feel your configuration is unusual enough, you may be interested in joining the beta test program (I do not know if Agnitum are taking on more applicants though).
ill try clearing all entries from the lan settings window and report (yes i had my lan mask set to be trusted - it seems outpost is a bit confused when it comes to this and vmware though, since saying the network 192.168.0.* is trusted still blocks packets unless i add a system rule saying to allow inbound on 192.168.0.5). i recognize that vmware is an unusual application, so i'm not terribly surprised that outpost struggles with it, but this problem has been present and talked about here on this forum for a very long time.
im glad agnitum reads these forums, because the idea of having to forward them long threads through email, and then forward them followup posts, etc., seems incredibly wasteful of everyone's time - including agnitum developers. agnitum needs to take an active effort in addressing bugs that are found. i can't stress enough how important it is for them to take these bugs seriously.
jamie3
For what its worth, the common denominator in all your posts so far is VMWare. I don't think Outpost was ever designed to run with virtual networks.
removing all entries from lan list somewhat unsurprisingly blocks all access to other computers on the lan. i tried adding system rule on top to allow all traffic to the lan mask (192.168.0.*) but still could not connect to any other computers on the lan.
Jamie, this forum is a user operated forum. It is meant to give users support in trying to solve problems with rules and answer questions that would otherwise overwhelm Agnitum support.
There are still some issues with version 2 as reported by beta testers that are being worked on. The beta testing will continue as more problems are fixed and new features are implemented.
I am waiting for a reply from Mikhail as to what the users should do when they find a bug that needs to be addressed by the programmers and cannot be handled by this forum. As for retyping a lot of information, when you turn in a bug report, you can always provide a link to the approriate thread that they can then read.
For the time being, we need to find out if you are dealing with a bug or if the problem can be resolved by changing your configuration.
I do not use VMWare, but for a while I was having problems with my lan. What I eventually found out is that Outpost does seem to have some kind of problem with wildcards, IP ranges and subnet masks when setting up a lan.
One of the things I had been doing was using addresses for DNS settings on the client machine and for some reason this was causing a problem. When I set up the lan properties for tcp/ip on the client machine, I assigned an IP for the client as 192.168.0.77, put the IP of the gateway machine in as 192.168.0.1, and used the IP of 192.168.0.1 for the DNS server.
I then deleted the instance of SVCHOST.exe in the applications section and made a global rule for DNS resolving UDP, no IPs but with SPI enabled.
I manually entered the clients IP of 192.168.0.77 in the lan settings and checked trusted.
I then had to put the IP 192.168.0.77 in the ignore host section of the protect.lst file in the Outpost Firewall directory. The attack detection plugin acts independantly of the firewall rules.
If any of this makes sense to you, you might try it instead of allowing inbound traffic. You can save your current configuration as a backup in a remote folder before you start making changes, and in fact you should do that anyway, of course.
 Nortel Unveils Vision, Strategy for Israeli High-Performance Net
 Busy Friday Leads to Strong Close for Net Stocks
|
HOME