1 of 1 people found this helpful
If you want to be able to pass all protocols, the easiest option is to set the zone/burb value on each side to "internal".
Next the "Remote IP" field on each Firewall GUI needs to contain the public/external IP address of the Firewall at the other end of the link.
Then select the "Remote Authentication" tab on each Firewall GUI, set the Remote Authentication method to "Password" and enter the same password on each side.
As both sides are using the same Firewall product (though slightly different versions) the remaining settings can be left as default. However, if you wish you can go to the "Crypto" tab and select a specific encryption/authentication pair (e.g. 3des/md5).
One other thing you must do is create an access control rule on each Firewall for the "isakmp" server process. Source burb/zone=external. Destination burb/zone=external. If you do not create this access control rule the isakmp service will not start and the firewalls will ignore any inbound attempts to establish a VPN connection.
With this all in place you shouldn't need to do anything more than to send some traffic (e.g. a ping request) between the two sites.
Personally, I always ensure that the Local & Remote network values always include the internal IP address of each Firewall and my first test is to try and ping the internal IP address of one Firewall from the other. If this works then your VPN is up and running. You will also be able to click on the "VPN Status" button in the VPN Definitions screen and see the status change from "idle" to "active".
I hope this helps you.
Have you tried changing the order of the VPN definitions on your two appliances? - moving the "Testing_gateway" entries above the Dynamic IP Restricted entries.
In version 6 and earlier, VPNs were processed based on the best match (it didn't necessarily matter the order the VPNs appeared in the list) . However, since v7, that list is processed from the top downwards. It could be that there's enough matching criteria, for the Firewall to try using the Dynamic IP Restricted definition, but it then realises that the packets do not match and this is one reason for the audit error you are seeing.
If the two definitions are swapped over it may be enough for this traffic to match the correct VPN definition.
Is the definition on the v8 appliance still terminating in the "external" zone, because I would still recommend that you change this to the internal zone - at least until you have proof that the tunnel is working. Once it is, if you wish to be more restrictive, create a new virtual zone, terminate the VPN in this zone and then create rules to allow traffic from this zone to your internal zone.