Project

General

Profile

Actions
Copy link

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.

Status:
Resolved
Priority:
Normal
Assignee:
Jim Pingle
Category:
IPsec
Target version:
2.4.4-p1
Start date:
08/31/2018
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
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.

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
Actions
Copy link
 #1

Updated by Jim Pingle over 5 years ago

  • Status changed from New to In Progress
Actions
Copy link
 #2

Updated by Jim Pingle over 5 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #3

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.

Actions
Copy link
 #4

Updated by Jim Pingle over 5 years ago

  • Status changed from Feedback to Resolved
Actions
Copy link
 #5

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.

Actions
Copy link
 #6

Updated by Jim Pingle over 5 years ago

  • Status changed from In Progress to Feedback
Actions
Copy link
 #7

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.

Actions
Copy link
 #8

Updated by Anonymous over 5 years ago

  • Target version changed from 2.4.4-GS to 2.4.4-p1
Actions
Copy link
 #9

Updated by Jim Pingle over 5 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

Actions
Copy link
 #10

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.

Actions
Copy link
 #11

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...)

Actions
Copy link
 #12

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.

Actions
Copy link
 #13

Updated by Jim Pingle over 5 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #14

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.

Actions
Copy link

Also available in: Atom PDF