Project

General

Profile

Bug #8859

VTI: Some third-party vendors require rightsubnet to have a mask for VTI, rather than address

Added by Jim Pingle almost 3 years ago. Updated over 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
IPsec
Target version:
Start date:
08/31/2018
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
2.4.4
Affected Architecture:
All

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.

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

Associated revisions

Revision da54e84a (diff)
Added by Jim Pingle almost 3 years ago

Default VTI remote to Address but allow it to change. Fixes #8859

Revision 59c2e21d (diff)
Added by Jim Pingle almost 3 years ago

Revert "Default VTI remote to Address but allow it to change. Fixes #8859"

This reverts commit da54e84ae79328a87b4a319239bb1b14d7ed2ce6.

Revision 6ae28bc3 (diff)
Added by Jim Pingle almost 3 years ago

Revert "Default VTI remote to Address but allow it to change. Fixes #8859"

This reverts commit da54e84ae79328a87b4a319239bb1b14d7ed2ce6.

Revision 5c4aa94a (diff)
Added by Jim Pingle over 2 years ago

Add 0.0.0.0/0 to VTI left/rightsubnets. Fixes #8859

No negative feedback from testing, time for a wider push.

This helps with third party devices that require 0.0.0.0/0 to route
traffic on a VTI P2.

Revision 17dfb092 (diff)
Added by Jim Pingle over 2 years ago

Add 0.0.0.0/0 to VTI left/rightsubnets. Fixes #8859

No negative feedback from testing, time for a wider push.

This helps with third party devices that require 0.0.0.0/0 to route
traffic on a VTI P2.

(cherry picked from commit 5c4aa94a90256b13b19209f11e4c75b2d0e85ece)

History

#1 Updated by Jim Pingle almost 3 years ago

  • Status changed from New to In Progress

#2 Updated by Jim Pingle almost 3 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100

#3 Updated by Vladimir Lind almost 3 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.

#4 Updated by Jim Pingle almost 3 years ago

  • Status changed from Feedback to Resolved

#5 Updated by Jim Pingle almost 3 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.

#6 Updated by Jim Pingle almost 3 years ago

  • Status changed from In Progress to Feedback

#7 Updated by Jim Pingle almost 3 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.

#8 Updated by Steve Beaver over 2 years ago

  • Target version changed from 2.4.4-GS to 2.4.4-p1

#9 Updated by Jim Pingle over 2 years ago

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

#10 Updated by Jim Pingle over 2 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.

#11 Updated by Braden McGrath over 2 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...)

#12 Updated by Jim Pingle over 2 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.

#13 Updated by Jim Pingle over 2 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#14 Updated by Jim Pingle over 2 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.

Also available in: Atom PDF