Why is VPN so hard between Cisco and Juniper?
Many
times have I seen engineers frustrated with getting a VPN tunnel
between a Cisco and Juniper device. Often it is the Juniper side which
is left to resolve the problem because the Cisco guy has never had a
problem before, It should just work!!
All very nice however not all VPN devices are created equal. Know your device!
Let's take two security devices: Juniper SRX and a Cisco ASA
The ASA has one method for IPsec which is cryptomap. If we decode this into an easier to understand term it means Policy based VPN.
The Juniper SRX has two methods:
What is typically overlooked on the ASA side is how many networks are put into the ACL associated with the cryptomap. ACL lines equal proxy id pairs.
For this ACL:
access-list 123 permit ip 192.168.1.0 0.0.0.255 172.10.5.0 0.0.0.255
access-list 123 permit ip 192.168.2.0 0.0.0.255 172.10.5.0 0.0.0.255
access-list 123 permit ip 192.168.3.0 0.0.0.255 172.10.5.0 0.0.0.255
We end up with 3 IPsec security associations. On the Juniper side we should configure 3 policies (with vpn action) to match the network pairs. You can try to use a route based VPN but be careful if you don't control both ends of the VPN. An extra ACL will break your VPN.
The recommendation for SRX to ASA VPN's is Policy based VPN.
If we had a Cisco router with the IP Security IOS we could use a VTI or virtual tunnel interface with a Juniper route based VPN. They are essentially the same thing. This would do away the need for 3 IPsec SA's and reduce overhead. Sending traffic through the VPN is then just a matter of routing.
I guess the question is, Why doesn't the ASA have the VTI option? One would think on a device with relativley low throughput you would want to make the best of it. They are used frequently for site to site VPN's that carry multiple subnets. Cisco ASA users should be screaming for this feature.
All very nice however not all VPN devices are created equal. Know your device!
Let's take two security devices: Juniper SRX and a Cisco ASA
The ASA has one method for IPsec which is cryptomap. If we decode this into an easier to understand term it means Policy based VPN.
The Juniper SRX has two methods:
- Policy based VPN
- Route based VPN
What is typically overlooked on the ASA side is how many networks are put into the ACL associated with the cryptomap. ACL lines equal proxy id pairs.
For this ACL:
access-list 123 permit ip 192.168.1.0 0.0.0.255 172.10.5.0 0.0.0.255
access-list 123 permit ip 192.168.2.0 0.0.0.255 172.10.5.0 0.0.0.255
access-list 123 permit ip 192.168.3.0 0.0.0.255 172.10.5.0 0.0.0.255
We end up with 3 IPsec security associations. On the Juniper side we should configure 3 policies (with vpn action) to match the network pairs. You can try to use a route based VPN but be careful if you don't control both ends of the VPN. An extra ACL will break your VPN.
The recommendation for SRX to ASA VPN's is Policy based VPN.
If we had a Cisco router with the IP Security IOS we could use a VTI or virtual tunnel interface with a Juniper route based VPN. They are essentially the same thing. This would do away the need for 3 IPsec SA's and reduce overhead. Sending traffic through the VPN is then just a matter of routing.
I guess the question is, Why doesn't the ASA have the VTI option? One would think on a device with relativley low throughput you would want to make the best of it. They are used frequently for site to site VPN's that carry multiple subnets. Cisco ASA users should be screaming for this feature.
No comments:
Post a Comment