Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - ahenning

Pages: 1 ... 3 4 [5] 6 7 ... 42
61
General Discussion / Re: Wanos hosting companies/partners?
« on: July 08, 2017, 10:24:50 AM »
Hi Faisal,

1) At this point unfortunately we cannot assist further on the Home project, since it is taking valuable time answering the same questions multiple times. Tunnel mode and the Amazon AWS is documented in the Admin Guide.
Tunnel Mode
Amazon Guide

2) VMware Player or VMware Workstation is not supported for production. Please reread 2)

3) I sent a quote for Ad Hoc support to assist with the AWS setup.

4) As mentioned in the email you can't connect your side to the AWS demo yet, because it is not configured and AWS VPC settings are not configured. See 3) again.

62
General Discussion / Re: Wanos hosting companies/partners?
« on: July 07, 2017, 11:08:01 PM »
Emailed a link to a demo AWS instance, so theoretically you could point your home side there.

63
Thanks for beta testing  ;D

64
Configuration / Re: [v.4 MultiSite] Where to add peers?
« on: July 07, 2017, 09:26:32 PM »
q8reflex 8) v.3 is Prod and documented, Use Production if documentation is needed. v.4 beta is in the process of going to prod. v.4.1 is hours old and you'll notice that only v.4.0.3 is mentioned in the download section. Documentation is updated daily as we change and add info relevant to v.4

I don't agree that there is no configuration anywhere and suspect this stems from over-complicating things. You don't need to configure, it is much simpler than you think. That is the point.

Further it seems there is a miss-understanding that Wanos is a Home user Internet Accelerator. I'll agree that it can be applied in that way and perhaps we should focus more on it, but it is a business product first and we tailor it to that market.

I am puzzled that man in the middle attacks are of concern since the objective is to accelerate Internet traffic. How is the public Internet more secure than inside our protocols?

For secure internal communication over the public internet use Wanos IPsec encapsulation for tunnel mode.

Release Notes: Release Notes / Changelog

Hand-Shake:

Debug : rsp_peer1 state set to SYN_SENT
Debug : handler1 Peer Alive
Debug : rsp_peer1 state set to OPEN




65
General Discussion / Re: Wanos hosting companies/partners?
« on: July 07, 2017, 09:03:50 PM »
I think that going into an unknown hosting environment as a first hands-on was too ambitious. But knowing now that it is a hosted environment I'll add that there are a few gotchas:
Read the Amazon Guide twice, even if you host somewhere else, the technical details are going to be similar, especially around the tunnel policies that can be tricky if you are peering on public IP addresses. In this case the Tunnel Policy will have Private subnets, but public peering addresses.
Since Internet is the end goal, remember that the traffic needs to be NATted. You have to ask, will the hosting provider NAT your Home subnet? If not in the hosting virtual network you need a NAT gateway, which will be Wanos' gateway. There are other ways around this to do the NAT on Wanos, but I am not going to recommend it since it will lead to another long thread. Plain and simple, host another VM to do the NAT since this is a test. Once the NAT is in place, make the tunnel policy on the Home side to a default 0.0.0.0/0 Peer IP = Hosted Public IP.

What to configure:
If I understand correctly the Internet link is under performing. It has a lot more bandwidth and it is difficult to reach full speed. So configure tunnel mode, set PLR 3, enable TCP-X, enable FEC 5:1 or maybe 10:1, depending how bad things are.

I'll send you an email on a proposal where we will configure the Amazon AWS side and you just point your Home side to the AWS IP.

66
/tce/etc/wanos/wanos-fdisk list

Lists the mounted drives

67
Configuration / Re: [v.4 MultiSite] Where to add peers?
« on: July 06, 2017, 09:25:56 PM »
yes change to bridge and add tunnel config or update to 4.1.1 that avoids this (tunnel mode without tunnel config).

4.0.3 beta and v.3 keys don't with 4.1

68
Configuration / Re: [v.4 MultiSite] Where to add peers?
« on: July 06, 2017, 08:46:36 PM »
sudo sed -i 's/tunnel/bridge/' /etc/wanos/wanos.conf


Then configure the tunnel policy (subnet and peer ip) before enabling tunnel mode.

Taking a look at that error now.

Yes, v3 license is not compatible, click the get trial button after running the sed command

69
Do you mean vda4 is not in the dropdown under settings -> datastore?

70
Configuration / Re: [v.4 MultiSite] Where to add peers?
« on: July 06, 2017, 11:37:38 AM »
The way to link via bridge mode:
1) Deploy appliance with default settings, set IP address
2) Connect Wanos-A wan0 to Wanos-B wan0
3) Send TCP traffic from LAN A to LAN B
4) Check peer status.

To force peers, configure tunnel mode.

Wanos should be compatible with your current man-in-the-middle defense. Normally IPSec on the router or firewall as long as wan0 connects to this device and not lan0 (bridge mode).

71
Configuration / Re: [v.4 MultiSite] Where to add peers?
« on: July 06, 2017, 11:01:23 AM »
Multisite is not an option in v.4, it is always on by default and auto detected and auto configured.

If both sides are in bridge mode, with default settings, lan0 and wan0 are mapped correctly so that the wan0 points to each other then once TCP traffic starts to flow in both ways the peers will detect each other automatically.

The minimum requirement for bridge mode peering:
Default settings (e.g. Bridge mode both sides)
lan0 and wan0 cabled correctly in-path
1x TCP session (not bypassed e.g. HTTPS)
Firewall should not strip TCP Option 76

Optional, but most highly recommended:
IP Address

72
Yes, should be just update. The free space will be on vda4 / sda4

v.4.1 update links sent via email

73
Yes, vdX drives enabled in v.4.1. Previously only drives starting with sd and xvd were considered automatically and vd required command line linking.

v.4.1 links coming online later.

74
General Discussion / Re: Academic Project : Request for information
« on: July 02, 2017, 01:13:22 PM »
Hi Mathias,

Ok, we can't assist much with this request, but what we can do:

1) Send sales brochures that covers some of the background questions.
2) Provide 10 Mbps trial keys, although the 1 Mbps express would probably work equally in a project scenario.

What we can't help with the project:
1) Text: Write some answer specifically for the project
2) Support: Help with configuration. All the configuration info is online and in bridge mode the minimal config is just IP address & gateway.

Tips:
1) Contact Richard Fradin, he did the same project a couple months ago and it might help to contact him
2) Use netem to simulate network conditions. Here is a simple router script than can be used on a minimal Ubuntu server or Centos install assuming the Virtual Router has 2 interfaces configured with IP addresses (These interfaces need to be connected to Wanos wan0 interfaces and are the gateway addresses addresses for the Wanos VM's):

echo "1" > /proc/sys/net/ipv4/ip_forward
tc qdisc add dev eth0 root netem rate 10000kbit delay 50ms loss 1%
tc qdisc add dev eth1 root netem rate 10000kbit delay 50ms loss 1%

This will give you a simulated WAN lab of 10Mbps, 100ms latency and 2% packet loss. Test with PLR, Fast Retransmit and Forward Error Correction, TCP Acceleration and of course Stream Compression and Deduplication.

75
Features / Re: Peer Detect
« on: May 10, 2017, 11:14:26 AM »
This is new in v4 since we now auto detect which sessions to optimize and which to leave alone. If the TCP session is seen on both appliances, then it is eligible to be optimized. If a session is only seen on one appliance but not the other, then it is bypassed. Hence, MultiSite has been removed and configuring Traffic Policies are now optional. This is a big step forward considering that these are often miss-configured in v3.

Wanos has the same TCP reset capability as Silver Peak and Riverbed Steelhead:

Configure -> Reset -> Reset TCP-X

If TCP-X is not enabled: Enable TCP-X, then disable TCP-X again


As like the other vendors, this is only expected to be used in a lab/test environment. Under normal production environments it would not be normal to reset TCP sessions in order to force a TCP reconnect to start optimization for a particular application like CIFS/SMB.

As for the ping idea, it is not really workable. The remote peer could be removed from the inline position but still respond to ICMP and even wanos control traffic like PLR and RTT measurements may still flow between the sites. This would cause the peers to remain "Active" causing the device that is inline to keep optimization alive. This would cause a blackout for optimized traffic. Better to be safe and only optimize while valid traffic is seen. When one of the peers are removed or moved where traffic flow is not correct, the peers should go into Idle state to avoid traffic blackout.

Test in a production network. If you still see peers Idle occasionally but want to force them to "Active" increase the peer timeout value under settings.

Pages: 1 ... 3 4 [5] 6 7 ... 42