Lab: R82.10 ElasticXL & VSNext problems in VMware

[bluecross]

Hello,

I'm trying to setup a R82 lab with ElasticXL and VSNext in VMware.
Having read these posts: https://community.checkpoint.com/t5/Firewall-and-Security-Management/R82-ElasticXL-amp-VSNext-Issues... and https://community.checkpoint.com/t5/Firewall-and-Security-Management/Building-VSNext-in-R82-walk-thr... I supposed that VSNext is possible in virtualization, but I'm still failing.
Setting up ElasticXL-Cluster didn't throw up any problems, but when setting it up as VSNext, there's no communication possible between SMS and gateway.
Can anybody confirm, that it is possible to run VSNext under virtualization? Both posts mention proxmox for the lab, also VMware (vSphere/ESXi) should be possible too.
When I configure the gateway for VSNext in the FTW, I can't connect to the management IP of the system after reboot. vNIC is in the same vlan (portgroup). I assume that the creation of the "wrp0" interface is the cause of the problem, as it uses a new virtual mac which is mapped to the (correct) mgmt/eth0 interface. Promiscuous mode is enabled for the portgroups of the dSwitch too...

Thanks for your help!

[Lesley]

Support has changed from R82 to R82.10 check it out here:

https://sc1.checkpoint.com/documents/R82.10/WebAdminGuides/EN/CP_R82.10_RN/Content/Topics-RN/Support...

[emmap]

It's supported and should work, I've done it in VMWare workstation without issue. Can you ping out from VS0?

[bluecross]

---

@emmap wrote:

Can you ping out from VS0?

---

No, seems like an isolated host. Can not ping second gateway in same network (and it's the same dSwitch on the same esxi host), nor the SMS or a client in this network.
Same is true for the sync-network, both VMs use 192.0.2.1, not resulting in conflict.

I can see the mac addresses for the SMS an client VM on both nodes via wrp0 but not the other gateway (incomplete).

Situation on the sync-network is a little bit different: Moving the client vm to the sync-network with an ip from this network I can reach 192.0.2.1 (tested with both gateways)

[emmap]

Both VMs use 192.0.2.1? Did you do the first time wizard on both of them? You only do the FTW on the first one, the second should be left raw. Suggest you turn off the second gateway VM for now and see about getting it going with only the one gateway to avoid any other IP/MAC conflicts.

[bluecross]

Both VMs use 192.0.2.1, first node was installed with FTW, second VM just the initial setup. The cluster setup is also a downstream problem, it would suffice to start with a single node.
Trying with one VM looses the connection to the mgmt client in the same network (used default 192.168.1.0/24) with the first reboot after the FTW. Installing only as ElasticXL node (VSnext not choosen) is working fine, so the problem seems to arise from the combination of VSNext virtualization and vSwitch setup.
I'm using a dedicated distributed vSwitch (no uplink to physical networks) on a single host with promiscuous mode allowed on the portgroups. VMs have 4 vNics configured, 1 mgmt portgroup, 1 sync portgroup, two other portgroups

[emmap]

When you say "Can not ping second gateway in same network" - is there two EXL clusters in this setup? 

[bluecross]

Hi emmap,

sorry, maybe wrong wording, there's only one EXL cluster planned. I tested with two nodes, which can't reach each other.
Currently only one SMS, one Windows client and one EXL node in the management network.

[emmap]

How are you testing to see if they can reach each other? The second node shouldn't have IP addresses manually configured. 

[bluecross]

When running the initial setup from the iso, I have to choose the mgmt interface and configure an IP address for it (screenshots attached).

[emmap]

When I have done this I just left this at default. Whatever you do, don't put the intended management IP on the second gateway, you'll have a conflict and then for sure it won't work. 

[CalvinPiggott]

How does the system choose the interface that should be assigned to sync?

[emmap]

In VMWare? It uses eth1 every time. eth0 becomes a member of the magg bond.