VPN between Netscreen ScreenOS and Checkpoint-1.
We have all been in the situation when a project, a Solution architect, a partner or customer wont listen to our recommendation to NOT mix products when setting up VPN.
In this situation it was a customer to my enterprise company that refused to accept us sending active equipment to be placed on their premises, and the customer of course did not want to put active equipment on our side. We strongly recommend to do either or, to have a clear, and more manageable demarcation point. And when i say demarcation point, i mean, sharing responsibility in the easiest way without any doubts of where the fault might be. Port-Cable-Port, within the same Rack if possible.
That left us with setting up an IPSEC tunnel over Internet between 2 different products, Checkpoint and Netscreen.
Checkpoint uses policy vpn, and Netscreen is more prune to Route based.
Im not debating on which Firewall/VPN Concentrator is the best etc, ill let others do that. But in general, most network companies dont follow the various RFC down to the spot. They all make some small adjustment as they find fitting for their need.
The problem we faced was that traffic initiated from the Checkpoint side when the VPN was down, didnt seem to bite, with that I mean it seems that the Phase1 from checkponit was not compatible what the Netscreen expected.
VPN would always go up if traffic was initiated from Netscreen to Checkpoint.
But since traffic was not always initiated from our side, we had a problem
Solution:
The solution was to enable monitor and rekey on the netscreen, ensuring VPN was re-negotiated without the need of traffic. We can still monitor the VPN by doing a simple IP-monitor on the other side.
In netscreen we have to use proxy-ids to match the Policy vpn configuration in Checkpoint, and ontop of that, have "monitor rekey" enabled.
set vpn "<vpn name>" monitor rekey
set vpn "<vpn name>" proxy-id local-ip 192.168.1.1&32 remote-ip 172.16.1.1&32 "ANY"
If you have any questions of the actual config, let me know.
We have all been in the situation when a project, a Solution architect, a partner or customer wont listen to our recommendation to NOT mix products when setting up VPN.
In this situation it was a customer to my enterprise company that refused to accept us sending active equipment to be placed on their premises, and the customer of course did not want to put active equipment on our side. We strongly recommend to do either or, to have a clear, and more manageable demarcation point. And when i say demarcation point, i mean, sharing responsibility in the easiest way without any doubts of where the fault might be. Port-Cable-Port, within the same Rack if possible.
That left us with setting up an IPSEC tunnel over Internet between 2 different products, Checkpoint and Netscreen.
Checkpoint uses policy vpn, and Netscreen is more prune to Route based.
Im not debating on which Firewall/VPN Concentrator is the best etc, ill let others do that. But in general, most network companies dont follow the various RFC down to the spot. They all make some small adjustment as they find fitting for their need.
The problem we faced was that traffic initiated from the Checkpoint side when the VPN was down, didnt seem to bite, with that I mean it seems that the Phase1 from checkponit was not compatible what the Netscreen expected.
VPN would always go up if traffic was initiated from Netscreen to Checkpoint.
But since traffic was not always initiated from our side, we had a problem
Solution:
The solution was to enable monitor and rekey on the netscreen, ensuring VPN was re-negotiated without the need of traffic. We can still monitor the VPN by doing a simple IP-monitor on the other side.
In netscreen we have to use proxy-ids to match the Policy vpn configuration in Checkpoint, and ontop of that, have "monitor rekey" enabled.
set vpn "<vpn name>" monitor rekey
set vpn "<vpn name>" proxy-id local-ip 192.168.1.1&32 remote-ip 172.16.1.1&32 "ANY"
If you have any questions of the actual config, let me know.
No comments:
Post a Comment