Routing issues for Remote Access during cluster upgrade

[AkiYa]

Hi guys,

I'm upgrading a cluster of two 6700 appliances R81.20 - take 98 to a brand new cluster of 9200 appliances, same version.
I configured the first 9200 and successfully replaced the standby 6700, same IP, same name, everything.

From this new standby node I can already reach all the S2S branch offices, internal resources, etc. so I'm assuming that its configuration is ok.

Now the odd issue: I switched the traffic to this new node to test it and then replace the other node, everything looked good BUT the Remote Access routing: I was able to connect from a remote computer but could not reach, for example, the Domain Controllers or many other remote networks (S2S).
Actually one of them, which is even in a common Community with other three clusters, was reachable...

During the first test I could even reach some IP addresses in the same subnet of the Domain Controllers, so I can' t really understand what's wrong... now I can' t reach that subnet at all...

I've already opened a ticket but the solutions they gave to me till now are not convincing, what I see here is a route problem with the new node, but I checked multiple times the interfaces, their subnets, the sync of the cluster, KPPAK secureXL mode on both... everything looks ok to me.

The error I'm focusing on is this one taken from the remote client "trac.log" file: 

[ 2416 4512][28 May 23:08:51][TR_OFFICE_MODE] TrOfficeMode::OmSendIpFrameCB: Packet to destination 10.20.0.13 of protocol 17
[ 2416 4512][28 May 23:08:51][TR_OFFICE_MODE] TrOfficeMode::OmSendIpFrameCB: ======= TUNNEL ROUTING =======
[ 2416 4512][28 May 23:08:51][TR_OFFICE_MODE] TrOfficeMode::OmSendIpFrameCB: This packet should go to Encryption domain index: -1
[ 2416 4512][28 May 23:08:51][TR_OFFICE_MODE] TrOfficeMode::OmSendIpFrameCB: Encryption domain index is out of range: -1
[ 2416 4512][28 May 23:08:51][vna] vna_trap: received VNA_TRAP_FORWARD_PACKET
[ 2416 4512][28 May 23:08:51][vna] vna_traffic_fwd_do : forwarding packet with 99 bytes

which suggest to me that there is something wrong with routing.
By the way this traffic is not even passing the firewall ("i" and "I" only) since I can't see any logs in the console when pinging or RDPing to these servers.

By switching back the traffic to the 6700 node everything start working again, so it's not a policy or different configuration problem.
Clearly at the moment I have a temporary cluster with an active 6700 appliance and a standby 9200, the cluster is set to 9000.
What is giving the remote client bad routes from the 9200 node only?

Any suggestions?

Thanks

[Chris_Atkinson]

Besides reaching out to TAC some things to be aware of:

1. The 9000 and 6000 use a different SecureXL mode by default - so could test switching it to KPPAK to isolate.

2. JHF Take 99 fixes several remote access issues present in version prior to it.

[AkiYa]

Thank you Chris,

the original setting of the 9200 appliance was instead on UPPAK, then I switched to KPPAK in order to match the 6700; I also tried to disable SecureXL with fwaccel off, but nothing changed.
I'll take a look at the take 99, eventhough I would expect to have the same problem on the 6700 since it has the take 98 as well.

[AkiYa · Accepted solution]

Fot the sake of knowledge, I finally found what was the problem, MEP was configured differently on the new node.
See sk78180