Bug #8859
closed
VTI: Some third-party vendors require rightsubnet to have a mask for VTI, rather than address
Added by Jim Pingle over 5 years ago. Updated over 5 years ago.
100%
Description
Some equipment that supports VTI requires the remote address be set to a network and not the default address, or else it fails to build a tunnel.
Rather than locking the interface control to address only, default it to address when switching to VTI but allow the user to change it.
Files
| ipsec-vti-0.0.0.0.diff (2.42 KB) ipsec-vti-0.0.0.0.diff | Jim Pingle, 10/05/2018 08:37 AM |
Updated by Jim Pingle over 5 years ago
- Status changed from In Progress to Feedback
- % Done changed from 0 to 100
Applied in changeset da54e84ae79328a87b4a319239bb1b14d7ed2ce6.
Updated by Vladimir Lind over 5 years ago
On Fri Aug 31 20:10:51 EDT 2018:
Created P2 with VTI remote network, then changed it to remote address - changes applied successfully in either cases. Looks good.
Updated by Jim Pingle over 5 years ago
- Status changed from Resolved to In Progress
This apparently fails despite previous reports of manual edits working. See
https://forum.netgate.com/post/788458
Will revert and try an alternate tactic.
Updated by Jim Pingle over 5 years ago
- Status changed from In Progress to Feedback
Applied in changeset 59c2e21d4f903ebaed3af861aeecab9b7e94d037.
Updated by Jim Pingle over 5 years ago
- Subject changed from vpn_ipsec_phase2.php: Do not disable remote network type for VTI to VTI: Some third-party vendors require rightsubnet to have a mask for VTI, rather than address
- Status changed from Feedback to New
- Target version changed from 2.4.4 to 2.4.4-GS
- % Done changed from 100 to 0
Needs more thought/testing than we'll have time for to make 2.4.4. There are workarounds on the linked forum thread for the few people that need it.
Updated by Anonymous over 5 years ago
- Target version changed from 2.4.4-GS to 2.4.4-p1
Updated by Jim Pingle over 5 years ago
- File ipsec-vti-0.0.0.0.diff ipsec-vti-0.0.0.0.diff added
The attached patch adds 0.0.0.0/0 to rightsubnet and leftsubnet which may make some third party devices happy, but needs more testing to know if:
1. Does this negatively impact non-IPsec traffic?
2. Does this negatively impact non-VTI IPsec traffic?
3. Does this work with VTI from other vendors?
With the patch, VTI on pfSense still connects, passes traffic, exchanges BGP routes, etc.
Apply the patch with the system patches package, stop IPsec, then edit/save/apply the VTI P1 or P2 and test.
Relevant forum threads: https://forum.netgate.com/post/795071 https://forum.netgate.com/post/795070
Updated by Jim Pingle over 5 years ago
#1 Seems to be OK but could use more confirmation. Traffic from the firewall itself still leaves via WAN as expected.
#3 Initial user tests on Palo Alto and EdgeRouter devices show it working but needs more thorough testing yet.
Updated by Braden McGrath over 5 years ago
Jim Pingle wrote:
#1 Seems to be OK but could use more confirmation. Traffic from the firewall itself still leaves via WAN as expected.
#3 Initial user tests on Palo Alto and EdgeRouter devices show it working but needs more thorough testing yet.
On a Palo Alto running PanOS 8.0.12, I did not need this patch to get functional VTI.
I just configured the /30 at both ends, and added a firewall rule under IPsec to make sure the PAN side of the tunnel could speak to pfSense.
I'm running BGP across the VTI without issue. (I've found some BGP related bugs in FRR, but that's for another issue...)
Updated by Jim Pingle over 5 years ago
If you did not need the patch, does adding the patch affect it negatively in any way? That is also an important question we need to answer.
I'd prefer to make the change unconditional, otherwise I'll have to rig up another new GUI option that controls if the p2 gets 0.0.0.0/0 added.
Updated by Jim Pingle over 5 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset 5c4aa94a90256b13b19209f11e4c75b2d0e85ece.
Updated by Jim Pingle over 5 years ago
- Status changed from Feedback to Resolved
0.0.0.0/0 is in the left/rightsubnet list and based on forum feedback this appears to be working with multiple third-party VTI implementations now, and there haven't been any reports of negative side effects so far.
Closing this out, if anyone find a problem we can open new issues with specific details.