Checkpoint VPN Encryption/Decryption behavior
When the firewall receives a packet, one of the first things it does, before it even goes through the rulebase, is decide whether the packet should be encrypted or not. To do this, the firewall looks at its encryption domain and the encryption domains of all of its peers. It also checks to see if the packet arrived in encrypted form already (i.e., whether it came across a VPN). The decision-making in simplified mode is really straightforward.
If the packet was not encrypted, it makes these checks:
If the source is not in a peer's encryption domain or the destination is not in ours, let it through.(clear text)
If the source is in a peer's encryption domain and the destination is in my encryption domain, then why is it unencrypted? Drop the packet with the message "Received a cleartext packet within an encrypted connection".
If the source is not in my encryption domain or the destination is not in a peer's encryption domain, don't encrypt.
If the source is in my encryption domain and the destination is in a peer's encryption domain, flag the packet to be encrypted to that peer.
If the packet was encrypted, the checks are a bit easier:
If the source is in a peer's encryption domain, and the destination is in mine, decrypt it and let it go about its merry way.
If the source is not in a peer's encryption domain, or the destination is not in my encryption domain, why was it encrypted? Drop the packet with the message "According to the policy the packet should not have been decrypted".
VPN routing makes this a little weirder in that "my" encryption domain and the "peer's" encryption domain can contain the encryption domains of other gateways. Satellite gateways see the hub's encryption domain as containing all encryption domains other than their own.
Note that the decision on whether to encrypt or not happens before any address translation. If you are translating traffic that goes across a VPN, this is why you must have the untranslated address in the encryption domain. You must also have the translated address in the encryption domain because the actual encryption proposals are sent using ranges in the encryption domain.
If you are expecting traffic to go across a VPN, and it is hitting a different rule further down in the rulebase, check your encryption domains. Chances are that the source is missing from yours or the destination is missing from your peer's.
If the source is not in a peer's encryption domain, or the destination is not in my encryption domain, why was it encrypted? Drop the packet with the message "According to the policy the packet should not have been decrypted".
VPN routing makes this a little weirder in that "my" encryption domain and the "peer's" encryption domain can contain the encryption domains of other gateways. Satellite gateways see the hub's encryption domain as containing all encryption domains other than their own.
Note that the decision on whether to encrypt or not happens before any address translation. If you are translating traffic that goes across a VPN, this is why you must have the untranslated address in the encryption domain. You must also have the translated address in the encryption domain because the actual encryption proposals are sent using ranges in the encryption domain.
If you are expecting traffic to go across a VPN, and it is hitting a different rule further down in the rulebase, check your encryption domains. Chances are that the source is missing from yours or the destination is missing from your peer's.
No comments:
Post a Comment