616
Deployment / Re: WanOS complex setup
« on: April 10, 2014, 11:21:14 PM »
Anyone else interested in setting up ESX/ESXi on a single NIC as well can have a look at: Configure Single Physical NIC for VMware vSphere (ESXi)
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.
617
Installation / Re: Installation Process
« on: April 08, 2014, 04:47:06 PM »
Hi Mak,
A Sticky has been created for this question. Of course the steps depend on the platform that will be used and network etc.
http://wanos.org/forum/index.php?topic=60.0
If you have any trouble with any of the steps, please post here and together we will figure it out.
A Sticky has been created for this question. Of course the steps depend on the platform that will be used and network etc.
http://wanos.org/forum/index.php?topic=60.0
If you have any trouble with any of the steps, please post here and together we will figure it out.
618
Installation / Vmware ESX single physical NIC
« on: April 07, 2014, 07:32:51 PM »
Although it is recommended to dedicate separate physical NIC's for lan0 and wan0, in certain cases only a single NIC might be available for Wanos and worth the compromise.
Things to consider when only one physical NIC is available:
1) Performance compromise, traffic will traverse the same interface at least twice
2) The bridge appliance will bridge traffic from the lan0 to the wan0 and vice versa. Bridge loops can still occur.
3) To split the single NIC traffic into two virtual interfaces, two VLAN's are required, the inside lan0 VLAN and the outside wan0 VLAN.
4) Promiscuous mode needs to be enabled on portgroup level and not vswitch level. In other words promiscuous is disabled (reject) for the vswitch and enabled for the outside and inside VLAN's.
5) Vmware is not native VLAN aware. Use normal VLAN's to ensure the traffic flow is predictable.
Caveats:
1) On a Cisco switch and possibly other spanning-tree enabled switches, 'spanning-tree bpdufilter enable' is required on the trunk interface between the host NIC and the switch.
2) The switch can't also be the gateway for the inside lan0 VLAN if it's a Layer3 switch. On the switches tested, frames were implicitly dropped on the trunk if the destination MAC was also the one of the switch local MAC addresses. This is either a feature or a bug, either way take note that the gateway needs to be another L3 switch, router or firewall.
Example:
Switch config:
interface FastEthernet0/5
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 30,101
switchport mode trunk
spanning-tree portfast trunk
spanning-tree bpdufilter enable
Credit goes to spoonzw
Things to consider when only one physical NIC is available:
1) Performance compromise, traffic will traverse the same interface at least twice
2) The bridge appliance will bridge traffic from the lan0 to the wan0 and vice versa. Bridge loops can still occur.
3) To split the single NIC traffic into two virtual interfaces, two VLAN's are required, the inside lan0 VLAN and the outside wan0 VLAN.
4) Promiscuous mode needs to be enabled on portgroup level and not vswitch level. In other words promiscuous is disabled (reject) for the vswitch and enabled for the outside and inside VLAN's.
5) Vmware is not native VLAN aware. Use normal VLAN's to ensure the traffic flow is predictable.
Caveats:
1) On a Cisco switch and possibly other spanning-tree enabled switches, 'spanning-tree bpdufilter enable' is required on the trunk interface between the host NIC and the switch.
2) The switch can't also be the gateway for the inside lan0 VLAN if it's a Layer3 switch. On the switches tested, frames were implicitly dropped on the trunk if the destination MAC was also the one of the switch local MAC addresses. This is either a feature or a bug, either way take note that the gateway needs to be another L3 switch, router or firewall.
Example:
Switch config:
interface FastEthernet0/5
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 30,101
switchport mode trunk
spanning-tree portfast trunk
spanning-tree bpdufilter enable
Credit goes to spoonzw
619
FAQ / Minimum Requirements
« on: April 05, 2014, 12:42:40 PM »
Minimum Hardware Requirements:
Point to Point:
2 GB memory
13 GB Storage (HDD, USB or Compact Flash)
1-2 Ethernet Interfaces
Multisite:
4Gb memory
64 GB Storage (HDD, USB or Compact Flash)
1-2 Ethernet Interfaces
A minimum of 2x CPU cores is recommended, unless the link size is less than 1 Mbps.
It is recommended to use two physical interfaces in a production network. This provides the best performance and simplifies the network config and cabling. It is possible to use a single physical interface in the virtual networks. In this case two VLANs are required and promiscuous mode enabled on the portgroup level via vSphere.
Point to Point:
2 GB memory
13 GB Storage (HDD, USB or Compact Flash)
1-2 Ethernet Interfaces
Multisite:
4Gb memory
64 GB Storage (HDD, USB or Compact Flash)
1-2 Ethernet Interfaces
A minimum of 2x CPU cores is recommended, unless the link size is less than 1 Mbps.
It is recommended to use two physical interfaces in a production network. This provides the best performance and simplifies the network config and cabling. It is possible to use a single physical interface in the virtual networks. In this case two VLANs are required and promiscuous mode enabled on the portgroup level via vSphere.
620
Configuration / By-pass rules required on which end?
« on: April 04, 2014, 10:11:35 AM »
Traffic policy rules apply to traffic going out on wan0.
To bypass traffic from a Server going towards a remote site, the rule would normally be applied on the server side device.
To bypass upstream traffic from the remote site going towards the server, the rule would be applied on the user side device.
To bypass traffic from a Server going towards a remote site, the rule would normally be applied on the server side device.
To bypass upstream traffic from the remote site going towards the server, the rule would be applied on the user side device.
621
Configuration / Re: Traffic Policies
« on: April 03, 2014, 03:28:31 PM »
Hi,
Ok, the traffic policy should work as intended if one more line is added:
Rule #99 as in this image:
Basically the only thing needed is to replace 172.16.100.0/24 with 192.168.100.0/24
Ok, the traffic policy should work as intended if one more line is added:
Rule #99 as in this image:
Basically the only thing needed is to replace 172.16.100.0/24 with 192.168.100.0/24
622
Troubleshooting / Re: No traffic optimization
« on: March 31, 2014, 06:49:33 PM »
Hi Sasha,
Ok, great to hear that. Yes, optimization is enabled in both directions on both Edges and Cores by default. The configuration of the resources is optimized to provide the best Core -> Edge optimization, but it is still possible to do 10X between fully meshed Edges.
The reason behind this is since the majority of network users receive more traffic from a central point than they normally send between each other. This allows for a very small Edge device but also ensures the majority of the resources are applied to the source of the network problem.
Ok, great to hear that. Yes, optimization is enabled in both directions on both Edges and Cores by default. The configuration of the resources is optimized to provide the best Core -> Edge optimization, but it is still possible to do 10X between fully meshed Edges.
The reason behind this is since the majority of network users receive more traffic from a central point than they normally send between each other. This allows for a very small Edge device but also ensures the majority of the resources are applied to the source of the network problem.
623
General Discussion / Re: Its Alive!
« on: March 15, 2014, 07:26:16 PM »
Hi, yes, for it to work both devices are needed, since deduplication works on a database of bit patterns. Essentially only the database references are sent over the WAN, and the receiving end knows how to recreate the original data. Having both at the same site is ok as a lab to test, but for a production network all traffic is still going to be sent over the WAN/VPN/Internet, so a device on the remote site is needed.
624
FAQ / High Availability - Bypass
« on: March 10, 2014, 01:46:41 PM »
How can high availability be achieved to avoid total loss of network traffic flow?
1) Bypass NIC's. Wanos Appliance 200 has a built-in bypass NIC.
2) Since Wanos is a bridge, another easiest method to create high availability is to run a second backup network cable along side the Wanos bridge appliance. Convergence happens within a few milliseconds and the switch-over is unlikely to be detected by a continuous ping. Unlike leading vendor fail-over scenarios, traffic sessions are not reset during the switch-over and users are unaware of the network change.
3) With out of path deployment, IP SLA can be used to track the status of the optimization device and remove the PBR rule when required.
4) External bypass switches. This is an option if they are gathering dust.
1) Bypass NIC's. Wanos Appliance 200 has a built-in bypass NIC.
2) Since Wanos is a bridge, another easiest method to create high availability is to run a second backup network cable along side the Wanos bridge appliance. Convergence happens within a few milliseconds and the switch-over is unlikely to be detected by a continuous ping. Unlike leading vendor fail-over scenarios, traffic sessions are not reset during the switch-over and users are unaware of the network change.
3) With out of path deployment, IP SLA can be used to track the status of the optimization device and remove the PBR rule when required.
4) External bypass switches. This is an option if they are gathering dust.
625
Installation / Re: Installing.
« on: March 09, 2014, 04:58:48 PM »
Good point about the installation. I agree, it is a bit tricky to get going. Many of these network appliances don't have CD-Rom's, but perhaps an external CD-Rom is still a better option to get the install on disk than using dd/win32disk imager.
I could be wrong but I think the 1020's are dell 850 machines, so the network interface could possibly be something like a Dell CH833 (Silicom MPB-PXG2BPI). This card model would be the first step to see if it would be possible.
I could be wrong but I think the 1020's are dell 850 machines, so the network interface could possibly be something like a Dell CH833 (Silicom MPB-PXG2BPI). This card model would be the first step to see if it would be possible.
626
Installation / Re: Installing.
« on: March 09, 2014, 04:05:35 PM »
Ok, yes, unexpected errors there. I'll take a look into it to see if it is possible to provide a better description. Any feedback from testing would also go a long way in improving the solution. What would you consider key features/functionality?
A note on the Riverbed (and similar) appliances, there have been a number of requests to enable the bypass NIC. Depending on the model this may be possible.
A note on the Riverbed (and similar) appliances, there have been a number of requests to enable the bypass NIC. Depending on the model this may be possible.
627
Installation / Re: Installing.
« on: March 09, 2014, 02:36:50 PM »
Alternatively adding a third network interface or a USB ethernet adapter could also work. It is also a good idea to reset to defaults with '/etc/wanos/clean.sh' when changing network interfaces.
628
Deployment / Re: Working with VPN
« on: March 06, 2014, 10:07:29 AM »
Ok, got it, so the FW's are establishing the VPN tunnels between the sites. In this case, since the traffic will be encrypted, the Wanos device needs to be between the users and the FW.
Regarding inline deployment: The IP addresses on the machines are for management of the devices and communication between them. The rest of the network is not aware of these IP addresses (e.g. no need for configuring additional gateways). In other words, if the FW is handing out DHCP at the moment to the users, this stays the same when the appliance is placed inline. One physical interface (wan0) connects to the FW and the second to the switch (lan0).
Edit:
For the archive: In this topology, the FW might need configuration to allow IPComp (IP Proto 108) and the auto detection TCP Option 76.
This is the recommended action. Alternatively UDP Encapsulation can be used.
Regarding inline deployment: The IP addresses on the machines are for management of the devices and communication between them. The rest of the network is not aware of these IP addresses (e.g. no need for configuring additional gateways). In other words, if the FW is handing out DHCP at the moment to the users, this stays the same when the appliance is placed inline. One physical interface (wan0) connects to the FW and the second to the switch (lan0).
Edit:
For the archive: In this topology, the FW might need configuration to allow IPComp (IP Proto 108) and the auto detection TCP Option 76.
This is the recommended action. Alternatively UDP Encapsulation can be used.
629
Deployment / Re: Working with VPN
« on: March 05, 2014, 05:47:28 PM »
Hi there,
Ok, first thing to note is that for Wanos to work a device is needed on each side of the VPN. If the ISP-Router is establishing the VPN tunnel, a network topology more or less as the following would work:
Data Center / Server Network > FW > Wanos-Core > ISP-Router > VPN > Remote-Site-Router > Wanos-Edge > Remote-Users
Which Hypervisor will be used and will virtual machines be required on both sides? The best is to dedicate two network interfaces for the VM, then it behaves as a standalone appliance.
Did I understand the requirement right?
Ok, first thing to note is that for Wanos to work a device is needed on each side of the VPN. If the ISP-Router is establishing the VPN tunnel, a network topology more or less as the following would work:
Data Center / Server Network > FW > Wanos-Core > ISP-Router > VPN > Remote-Site-Router > Wanos-Edge > Remote-Users
Which Hypervisor will be used and will virtual machines be required on both sides? The best is to dedicate two network interfaces for the VM, then it behaves as a standalone appliance.
Did I understand the requirement right?