Messages

481

Troubleshooting / Insufficient disk space

« on: October 17, 2014, 10:38:59 AM »

When alerts are logged and errors are displayed during multisite configuration if disk space is not sufficient.

To add an additional partition:
sudo su
/tce/etc/wanos/wanos-fdisk sda
reboot
mkfs.ext3 /dev/sda2
reboot
set the datastore to sda2 in the gui

This is based on the assumption that the only drive installed is sda and that is where the un-partitioned free space is located. If a second drive was added it would normally be sdb. Double check the output of the commands.

482

Features / Re: Datastore size

« on: October 16, 2014, 02:55:54 PM »

Max datastore in Express is 60Gb for one remote site. But before configuring the larger datastore consider that it will have a performance impact.

For more sites and larger datastores then Plus is the route to go.

This info is in the FAQ: Hardware limits (Wanos Express vs Wanos Plus)

483

Features / Re: Datastore size

« on: October 16, 2014, 12:29:16 PM »

That detail is in the reports?

484

Troubleshooting / Re: Peers down - IPSec VPN

« on: October 16, 2014, 12:18:57 PM »

Ok, thanks for the details. They are all correct, so then the expensive packet message must be due to the fragment reassembling. I take it the expensive packet message was not present previously and only started when UDPEncap was enabled?

Also are all the Wanos interfaces on the standard MTU 1500?

The proto 108 messages should only be visible between wanos devices e.g:
PC --- TCP --- Wanos --- Proto108 --- Wanos --- TCP --- Server

485

Deployment / Re: wanos + ESXi with pfSense Firewall VM

« on: October 16, 2014, 11:49:22 AM »

Great, thanks for the feedback.

486

Troubleshooting / Re: Peers down - IPSec VPN

« on: October 16, 2014, 11:30:36 AM »

Hi Misha,

The datastore sync happens if there was some packetloss on the network previously. It could have been due to the previous problems, so it would be a good idea to clear the datastore and start off fresh.

Clever design for branch type one. The VPN traffic should pass-through and should not affect anything. Are the problems affected by both designs or only this internet based branch type?

Since the UDPEncap works, it can mean a few things:
WAN is dropping proto 108 packets.
WAN can't NAT/PAT proto 108 packets.
WAN can't fragment proto 108 packets.

If the WAN is not configured to drop proto 108 and there is no NAT configured as in the lab configs, then the likely one is the fragment problem due to MTU.

The expensive packet warning is not normal, we should investigate why this is happening. Could you please run ethtool -k lan0 and ethtool -k wan0?
'ethtool -i' would also be useful.

487

Troubleshooting / Re: Peers down - IPSec VPN

« on: October 15, 2014, 06:51:14 PM »

Yes, I agree, the only difference is in the Internet for transport between sites. This suggests to me that maybe the problem is MTU related. Is it possible that the Internet connected routers have extra encapsulation like PPPoE or another VPN header?

One thing that I am not sure of is that in the diagram and router configs they establish the VPN over the 192.168.1.x private addresses. I understand this will work in the lab, but if this is the production config as well, then it seems this ipsec tunnel is running over a second tunnel (e.g. Another ipsec tunnel or gre/l2tp). In this scenario the extra encapsulation can definitely contribute to MTU problems. One ipsec encapsulation would be fine though.

The step 1 would be to bypass all traffic. Doing this will pass through all traffic untouched. All traffic should work across the VPN. If not, then there is still some configuration missing for the VPN. Once the two sites can communicate without any issues without Wanos, then we know it is ready to start with the wanop configs.

As a last resort you can try UDP Encapsulation, which is enabled in /tce/etc/wanos/wanos.conf UDPENCAP=Enable
This is required on both sides and Configure > Reset to apply the change. If there are MTU issues, the routers should fragment the packets and Wanos will try to reassemble them. This is not ideal and not recommended as the final solution, but can help in the troubleshooting process.

488

Features / Re: Policies rules modifcation

« on: October 15, 2014, 12:37:20 PM »

Agree, will keep it in mind.

489

Troubleshooting / Re: Regarding wrong policy applied during testing, which caused network to go off..

« on: October 15, 2014, 09:51:14 AM »

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.

490

Troubleshooting / Re: How to bypass the policies which is already added

« on: October 15, 2014, 09:46:18 AM »

The one with the lower number. Like a Cisco ACL i.e. Top down.

491

Deployment / Re: wanos + ESXi with pfSense Firewall VM

« on: October 15, 2014, 09:45:11 AM »

Hi Spiffster,

Quite a few people are using this exact same setup with a virtual pfSense.

If the pfSense Lan and Wan design was the standard before introducing wanos then all that needs to happen is to move the pfSense Lan and wanos Wan to another separate vSwitch or Vlan portgroup. Essentially this connects the wanos wan cable into the pfSense lan port. Because wanos will bridge the traffic from the Lan servers to the Wan side, this means the Lan servers are basically connected to the pfSense lan port. Then it follows the original design.

Remember to enable promiscuous mode on the wanos interfaces so that the bridging works. In this configuration where promiscuous mode is enabled on a vswitch or port-group that is shared with other servers there is an additional recommendation: Bypass all traffic (#99) and then create a specific traffic policy rule for the office subnets e.g:

source home office subnets -> destination office subnets

492

Troubleshooting / Re: Regarding wrong policy applied during testing, which caused network to go off..

« on: October 14, 2014, 03:00:07 PM »

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

493

Troubleshooting / Re: Regarding wrong policy applied during testing, which caused network to go off..

« on: October 14, 2014, 02:09:26 PM »

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/

494

Troubleshooting / Re: Peers down - IPSec VPN

« on: October 14, 2014, 12:47:16 PM »

Very strange problem. Is bypass traffic e.g. HTTPS affected in any way?

495

Troubleshooting / Re: Peers down - IPSec VPN

« on: October 14, 2014, 11:38:33 AM »

Hi Misha,

The rules look fine if the optimization is only supposed to work for the one 10.90.250/0 site. Are the peers up in the 'peer status' tab?