Because the directive is showing up on the gateway's tables, it sounds like you have it defined in the correct f* instance on the MDS/SMS/Domain. You'll probably need to work with TAC and figure out why your subnet-per-peer directive is not working properly as that should definitely work with IKEv2. I'll redirect the support to that, but if you could provide some insight as to why this is still happening, despite the fact that I've moved the definitions, I'd appreciate that. I believe that the issue causing this is related with the f files. As far as custom kernel definitions go, I checked and couldn't find any.
I've tried disabled fwaccel as well as vpn accel without success. I did run the fw tab -t s ubnet_for_range_and_peer which shows the correct entry for this VPN on the gateway after installing policy, however, I was still experiencing the same issues. I've also tried to add this entry under /var/opt/CPmds-R80.20/conf/1, also without success. I have since tried to remove this entry an add it to the correct location, under /opt/CPmds-R80.20/customers//CPsuite-R80.20/fw1/conf/1, installed policy but no success. The subnet_for_range_and_peer was defined under /var/opt/CPmds-R80.20/conf/77CMP. We have an MDS, but according to the SK the file shouldn't be defined here.
However, this was done in a different file location than the one mentioned on sk98239. When this tunnel was created, an entry was indeed added to the f file. So, you definitively have something there. I can also share the vpnd.elg files, as well as the ikev2.xmll files if you are interested in taking a look at that. I have a case opened with TAC, but so far no meaningful replies. So traffic generated on their side of the VPN always reaches us without issues.ģ)Child SAs are only being negotiated on re-keys, I'm assuming the first time they are created is under the AUTH packet, as per the RFC. The issue is weird and I've isolated the following things:ġ)If the negotiation is triggered on the ASA side, everything works as expected (so, as a workaround, they are bouncing the tunnel on their side, generating traffic to us (if we are the first to generate traffic it won't work) and that's allowing us to connect)Ģ)If we initiate the connection, we are unable to reach the other side of the VPN but, they are able to reach our network. This VPN is with a third party gateway, a Cisco ASA and we are using IKEv2.
After this upgrade, we lost connectivity with one of our VPNs. Last week we upgraded our security gateway from R77.30 to R80.20.
0 kommentar(er)
