Regarding wrong policy applied during testing, which caused network to go off..

[Anil Kumar H]

Hi,

I was doing some policy settings, one policy was with bypass & same one without bypass, after reset on both ends, machine was not reachable. Even locally over network it was not available, but machine was alive physically at both ends. Strange thing observed after reset.

same rule with bypass & without bypass.
On A:
10.9.64.0/24 10.9.17.0/24 without bypass
10.9.64.0/24 10.9.17.0/24 with bypass

On B:
10.9.17.0/24 10.9.64.0/24 without bypass
10.9.17.0/24 10.9.64.0/24 with bypass

When I logged into machine physically, I was not able to see the ip address on the machine, even Tun0 was not visible,  I restarted the machine, but still network was not available, then I had to /etc/wanos/clean.sh then reassign the ip address again. Same was done on other end to bring back network alive.

[ahenning]

It does not make sense that there was an issue on the one side and then the same steps had to be repeated on the remote end to resolve the issue. Something else is at play here.

With all the user errors, you remind me of this guy 
http://honestnetworker.wordpress.com/2014/02/22/independent-testing-commissioned-by-the-competitor/

[ahenning]

Do you have any steps to reproduce the error? Perhaps something else was configured before applying the policies. The policies alone work fine.

[Anil Kumar H]

Before those two rules, I had wanos default rules and one more
 A
10.9.64.0/24 192.168.178.0/24 without bypass

B
192.168.178.0/24 10.9.64.0/24 without bypass

I sit on A end and do changes for B end over portal, in my scenario I applied those 2rules on B end and reset B, parallel I did changes for A end and did reset..after this both ends wanos not reachable from its actual location itself.

Tomorrow will do similar things and see if I get similar issues.

[Anil Kumar H]

I tried to reproduce error, but couldnt' do it.

will keep trying..

[ahenning]

Creating a policy rule is very unlikely to have caused that. It must have been a some combination of configurations or more likely some command line editing.

If you ever manage to reproduce a similar situation please try to make a backup of the log before running clean. The log is in/wanos/wanos.log or can be viewed with 'wanos-log'. The info there would be useful to fix it to ensure no one else runs into it.

[Anil Kumar H]

there was no command line editing happened, I remember it happened during policy settings only, if I face similar issue will share the log file.

[ahenning]

Wow thanks Anil, you are really good at the Quality Assurance testing I managed to catch this one which I think was the cause.

It happens when configuring the destination subnet without a mask. The source subnet has a validation check and says the mask is invalid, which should be applied to the destination subnet as well.

Here are the steps to reproduce:
Step:


Result:

[Anil Kumar H]

that's wonderful, should I do that testing here & make network go down  & later share you the wanos.log file ?

[ahenning]

Thanks, but I already figured it out and patched in 1.4.2 to check the destination mask as like the source mask to ensure the subnet is in a valid format.