It depends on your network requirements and expected growth.
The main differences between the two are interoperability with other manufacturers devices, and, as you pointed out, the use of routing policies instead of numbered VPN interfaces.
Both these KB's talk about the same scenario and the only difference is w.r.t the requirement. So, picking the configuration for tunnel interface VPN would be based on the need.
If you have a simple or small network where there is no dynamic routing involved, you can use below KB instructions.
When you say interoperability with other manufacturers devices, what would be some of the hurdles with non sonicwall devices? I realize there will be proprietary methods/protocols at times, but what are possible issues with either one the methods above?
In the first link is this notice: "Route-based VPN using a tunnel interface is not supported with 3rd party devices." This is where you create a numbered interface on the Sonicwall to control the routing. It is reasonable to expect a 3rd party device wouldn't support this as it is NOT a published standard.
From a technology standpoint, most firewalls should support the protocols, encryption, and authentication methods (they are standards for a reason). Whether or not the firewall in question has the latest patches/updates to provide the needed methods is one thing (for instance IKEv2 wasn't fully supported on Cisco ASAs until version 8.4(1), don't get me started on AES256...).
Mostly I've run into 3rd parties not knowing what they are doing when configuring their firewall for a VPN tunnel. This is why I create forms for them to fill out with the exact tunnel specifications indicated. If they can't read/comprehend the requirements I've specified, thats on them, and I'm not going to sit a phone call with these people for hours while they figure out how to configure their own device when I know my settings are correct.
We're using Sonicwalls end to end so we'll avoid the compatibility issues. I'm just curious what the technical difference was between using a "numbered" interface vs. one that isn't. I'm having a hard time wrapping my head around what is technically different using a numbered interface that would make it incompatible with some vendors routers. I'm sure it's a simple answer, I'm just having a hard time wrapping my head around that.
"Virtual links established by IPsec tunnel mode can conflict with routing and forwarding inside Virtual Networks because IP routing depends on references to interfaces and next-hop IP addresses. The IPsec tunnel mode specification is ambiguous on this issue, so even compliant implementations cannot be trusted to avoid conflicts."
Answers
It depends on your network requirements and expected growth.
The main differences between the two are interoperability with other manufacturers devices, and, as you pointed out, the use of routing policies instead of numbered VPN interfaces.
Hi @DJHURT1,
Thank you for visiting SonicWall Community.
Both these KB's talk about the same scenario and the only difference is w.r.t the requirement. So, picking the configuration for tunnel interface VPN would be based on the need.
If you have a simple or small network where there is no dynamic routing involved, you can use below KB instructions.
If there is a dynamic routing involved, its better to use below KB article.
Hope this is clear. Let me know for further questions.
Regards
Saravanan V
Technical Support Advisor - Premier Services
Professional Services
@TKWITS
When you say interoperability with other manufacturers devices, what would be some of the hurdles with non sonicwall devices? I realize there will be proprietary methods/protocols at times, but what are possible issues with either one the methods above?
In the first link is this notice: "Route-based VPN using a tunnel interface is not supported with 3rd party devices." This is where you create a numbered interface on the Sonicwall to control the routing. It is reasonable to expect a 3rd party device wouldn't support this as it is NOT a published standard.
From a technology standpoint, most firewalls should support the protocols, encryption, and authentication methods (they are standards for a reason). Whether or not the firewall in question has the latest patches/updates to provide the needed methods is one thing (for instance IKEv2 wasn't fully supported on Cisco ASAs until version 8.4(1), don't get me started on AES256...).
Mostly I've run into 3rd parties not knowing what they are doing when configuring their firewall for a VPN tunnel. This is why I create forms for them to fill out with the exact tunnel specifications indicated. If they can't read/comprehend the requirements I've specified, thats on them, and I'm not going to sit a phone call with these people for hours while they figure out how to configure their own device when I know my settings are correct.
Hope that helps.
@TKWITS
We're using Sonicwalls end to end so we'll avoid the compatibility issues. I'm just curious what the technical difference was between using a "numbered" interface vs. one that isn't. I'm having a hard time wrapping my head around what is technically different using a numbered interface that would make it incompatible with some vendors routers. I'm sure it's a simple answer, I'm just having a hard time wrapping my head around that.
Brief from above:
"Virtual links established by IPsec tunnel mode can conflict with routing and forwarding inside Virtual Networks because IP routing depends on references to interfaces and next-hop IP addresses. The IPsec tunnel mode specification is ambiguous on this issue, so even compliant implementations cannot be trusted to avoid conflicts."
Can you give an example of such a conflict?