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 2 [3] 4 5 ... 42
31
General Discussion / Re: Testing WANOS - Single Appliance
« on: January 03, 2018, 08:53:26 PM »
Just to add:

1) In lab setup using v.3 in bridge mode then the only absolute requirement is IP address and wan0 cables connected to the wan network. No other config is absolutely required to get optimization to work.
2) v.3 yes. The default Express license does not expire.
3) If there is an IPsec tunnel between the server and workstation then no optimization would not work. Traffic between server and workstation should be plain TCP type of traffic. IPsec between router-A and router-B is ok

32
General Discussion / Re: Testing WANOS
« on: January 02, 2018, 08:36:41 PM »
Two means one wanos appliance on each side of the link e.g:

Server-A <---> Wanos-A <---> Wide Area Network Link <---> Wanos-B <---> Workstation-B

In the topology mentioned in the first post, the Wan Optimization part of Wanos can't function as they work in pairs. Think of it as one side compress the data and the second one decompress the data after it has been received over the WAN link.

33
General Discussion / Re: Testing WANOS
« on: January 01, 2018, 11:44:49 AM »
Hi,

Two appliances are required: One on each side of the WAN link. Considering this it will not be possible to test Wanos in the current topology connected to a general internet link as a sole appliance.

34
I think this has been answered accurately: Wanos would not by default in software limit the pass-through to 1 Mbps. There is either some configuration e.g. the WAN Tx rate set to 1000 Kbps or a setting on the router. If it is not set by software configuration, then the next step is to look at the hardware level, maybe some USB-Ethernet adapters are used, or half duplex settings, or some rate limit setting on ESXi vNIC, but surely there is a rate limit somewhere to cause the 1 Mbps throughput. Even with optimization enabled and throughput at 10 Mbps, that is the end to end throughput, the actual WAN bandwidth used after optimization is likely still 1 Mbps.

That said, in a lab setting, this is desirable, as in the lab it is essential to see the acceleration (10 Mbps) compared to pass-through (1 Mbps).

35
Yes, trial licenses for v.4 are available

36
Troubleshooting / Re: Support
« on: November 10, 2017, 12:20:29 PM »

37
Troubleshooting / Re: Support
« on: November 10, 2017, 12:17:09 PM »
More info on what Bypass (Fail-to-wire) is and how it works:
http://wanos.co/docs/docs/knowledgebase/bypass-fail-to-wire/

38
Troubleshooting / Re: Support
« on: November 10, 2017, 12:09:43 PM »
All support questions answered. Please provide the supporting info as soon as possible to ensure a quick resolution.

39
Troubleshooting / Re: Support
« on: November 10, 2017, 12:02:49 PM »
Hi Olivier,

Your support requests have been received, please kindly give us a few minutes to process them.

40
Troubleshooting / Re: Bridge Mode in Virtual Enviroment
« on: October 25, 2017, 12:47:33 PM »
http://wanos.co/docs/docs/wanos-admin-guide/installation/esxi/

Please see promiscuous mode and forged transmits. Enable on both port groups.

41
Troubleshooting / Re: Tunnel mode and HTTPS
« on: October 04, 2017, 10:03:30 AM »
Hi Kris,

Yes, no traffic policies are needed, since the default 0.0.0.0 would listen to all traffic over the tunnel and would optimize the TCP traffic that flows both ways over the tunnel.

On the 100 tunnel rules, yes, this limit can easily be increased.
One way is to edit the tunnel_policies rules directly:

1000=0.0.0.0/0,-,Default
111=11.0.0.0/8,1,Lab-3-24,10.10.3.24,
112=10.0.0.0/8,1,Lab-3-24,10.10.3.24,


That said, the result of this would be the same as setting a default rule to use Azure (Tunnel 0.0.0.0/0) and using the batch script to add the routes on the host or using Policy based routing to redirect only the interesting routes to the tunnel.

42
Troubleshooting / Re: Tunnel mode and HTTPS
« on: October 03, 2017, 10:11:48 AM »
Hi Kris,

Yes, this is a known and expected behavior:
The local subnets are tunneled to the AWS/Azure private network, so private communications works as expected.
When all traffic is sent out of the AWS/Azure side the security rules don't allow the EU private networks to use the gateway (or NAT at least).
It makes sense from the provider perspective that they don't want any remote IP to exit the VPC/Private subnets.

The quick and simple way around it is to enable TCP-X and set:
PEP_TCP_FULL_TRANSPARENT=false

Also the DNS servers needs to be reachable locally or on the Azure/AWS VPC.

The right way is probably to use a NAT Gateway and configure it to allow the EU private subnets to be NATted out the public IP.

43
Troubleshooting / Re: Tunnel mode and HTTPS
« on: September 28, 2017, 10:53:54 AM »
Hi Kris,

A couple things that stand out:
The Azure side needs a tunnel rule for the return traffic back to EU pointing to the EU local subnets.
Webcache only needs to be enabled on the EU side.
Disable Webcache completely until the whole setup works perfectly.
0.0.0.0/0 for SSL caching is definitely going to break some SSL sites.

44
Troubleshooting / Re: Tunnel mode and HTTPS
« on: September 27, 2017, 01:49:38 PM »
Hi Kris,

Some questions to help troubleshoot:

Are both sides running v.4? If on v3, then HTTPS is bypassed from the tunnel, only optimized traffic is tunneled.

Is standard HTTP working fine over the tunnel?

Does the issue exist only when the webcache is enabled and HTTPS server ip configured in the SSL servers list?


45
Hi Fernando,

Is the traffic you are expecting to see registering on the lan0/wan0 interface graphs?
This would indicate whether it is a case of  "nothing to see" rather than "not seeing" the traffic.

Pages: 1 2 [3] 4 5 ... 42