Everything else original (no translation) There is a source NAT rule for the encryption domain network of Gateway1 being hidden behind the HUB using the network / IP 192.168.2.1 when traffic is flowing on the tunnel with Gatewa圓 (192.168.3.0/24), where 192.168.2.0/24 is defined as the encryption domain for the Gateway2 (HUB) in the configurations made on Gatewa圓. Thank you for pointing out to this SK, but there is no encryption domain clash between the route based vpn and the domain based one. Our cluster is having a 2 x 5800 appliances on version R80.30 (managed by a SMS on version R80.30) which is defined in both of the communities and the other parties are having a Juniper SRX for Community1 and a Cisco ASA Firewall for the Community2.Ĭan someone help on this situation, maybe you have faced this behavior previously? It seems that this is not working and traffic is not matched by this access rule. Now in order to route the traffic from one community route based vpn ( Community1) to the other related to the domain based vpn ( Community2), we have applied a directional match condition ( Community1 => Community2). From the local VPN domains to the VPN community ( internal_clear => Community1).From the Community to the local VPN domains ( Community1 =>internal_clear).To and from the VPN Community via VPN routing ( Community1 => Community1).Route based VPN is established with numbered VTI interfaces and the only thing we are missing is that traffic should go correctly routed to the domain based VPN.įor all other communications that are working we are using directional match condition like the below:
We are trying to make possible communication from a Route Based VPN community to a domain based VPN community.
0 kommentar(er)
