Project

General

Profile

Actions
Copy link

Bug #10418

closed

IPsec VTI address/mask selection not functional

Added by Danilo Zrenjanin over 4 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Renato Botelho
Category:
IPsec
Target version:
2.4.5-p1
Start date:
04/03/2020
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.4.5
Affected Architecture:

Description

There are couple of oddities in 2.4.5.
1. Once the IPsec interface is assigned, it gets /32 subnet instead of /30.

ipsec1000: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1400
    tunnel inet 77.243.27.229 --> 178.148.171.201
    inet6 fe80::290:bff:fe7a:861b%ipsec1000 prefixlen 64 scopeid 0xb
    inet 10.6.106.1 --> 10.6.106.2 netmask 0xffffffff
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    reqid: 1000
    groups: ipsec

2. After IPsec interface assignment it doesn't appear under Firewall/Rules

3. It still works and routes the traffic even though the interface has /32 subnet.

Actions
Copy link
 #1

Updated by Viktor Gurov over 4 years ago

1. Once the IPsec interface is assigned, it gets /32 subnet instead of /30.
simple fix in ipsec.inc
https://github.com/pfsense/pfsense/blob/2c9e1e43f3619af39dc12c67830cc63a08ac8829/src/etc/inc/ipsec.inc#L372:

if ($addrbits) {
                if ($mode == "tunnel6") {
                    return $idinfo['address']."/128";
                                } elseif (($mode == "vti") && is_ipaddrv4($idinfo['address'])) {
                    return $idinfo['address']."/30";
                } elseif (($mode == "vti") && is_ipaddrv6($idinfo['address'])) {
                    return $idinfo['address']."/64";
                } else {
                    return $idinfo['address']."/32";
                }

2. After IPsec interface assignment it doesn't appear under Firewall/Rules:
I found that ipsec* interfaces in blacklist
https://github.com/pfsense/pfsense/blob/2c9e1e43f3619af39dc12c67830cc63a08ac8829/src/etc/inc/filter.inc#L101
for the filter_get_interface_list():
https://github.com/pfsense/pfsense/blob/2c9e1e43f3619af39dc12c67830cc63a08ac8829/src/etc/inc/filter.inc#L4545
why is this needed?

after removing blacklist firewall rules tabs shows OK.

Actions
Copy link
 #2

Updated by Jim Pingle over 4 years ago

Viktor Gurov wrote:

2. After IPsec interface assignment it doesn't appear under Firewall/Rules:
I found that ipsec* interfaces in blacklist
why is this needed?

This is necessary because pf does not properly respect the rules directly placed on ipsecX interfaces. At least it did not last time I tested it. It had issues with traffic matching on both the ipsecX and encX interface, state tracking, and I believe only matching traffic in one direction which led to behavior that looked similar to asymmetric routing.

Actions
Copy link
 #3

Updated by Viktor Gurov over 4 years ago

Actions
Copy link
 #4

Updated by Jim Pingle over 4 years ago

  • Status changed from New to Pull Request Review
Actions
Copy link
 #5

Updated by Renato Botelho over 4 years ago

  • Status changed from Pull Request Review to Feedback
  • Assignee set to Renato Botelho
  • Target version set to 2.5.0
  • % Done changed from 0 to 100

PR has been merged. Thanks!

Actions
Copy link
 #6

Updated by Viktor Gurov over 4 years ago

  • Status changed from Feedback to Resolved

tested on 2.5.0.a.20200403.1936

OK now, I can see correct netmask:

ipsec1000: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1400
    tunnel inet 192.168.1.1 --> 192.168.1.2
    inet6 fe80::edd:aeff:fe07:2100%ipsec1000 prefixlen 64 scopeid 0xf 
    inet 10.45.45.5 --> 10.45.45.4 netmask 0xfffffffc 
    groups: ipsec 
    reqid: 1000
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

Actions
Copy link
 #7

Updated by Jim Pingle over 4 years ago

  • Subject changed from IPsec VTI Interface issues to IPsec VTI address/mask selection not functional
  • Category changed from VPN (Multiple Types) to IPsec
  • Status changed from Resolved to New

Reopening this since it's not quite so clear that we should lock this down after all. Maybe we should default it to allowing the user to set the mask and only assume /30 if it's set to Address.

Some people are already using it that way, like on https://forum.netgate.com/topic/152179, where they numbered their VTIs using /31 networks which should also work the same as /30.

And even though it doesn't make a lot of sense, other vendors might want the user to set a different mask which would affect the traffic selectors generated for the interface addresses.

Actions
Copy link
 #8

Updated by Viktor Gurov over 4 years ago

It seems reasonable to revert back PR #4140 changes
to allow VTI netmask select

PR:
https://github.com/pfsense/pfsense/pull/4280

Actions
Copy link
 #9

Updated by Jim Pingle over 4 years ago

  • Status changed from New to Pull Request Review
Actions
Copy link
 #10

Updated by Renato Botelho over 4 years ago

  • Status changed from Pull Request Review to Feedback

PR has been merged. Thanks!

Actions
Copy link
 #11

Updated by Viktor Gurov over 4 years ago

  • Status changed from Feedback to Resolved

tested on 2.5.0.a.20200426.2333
now it allows you to select a network mask for VTI interfaces, as before

Actions
Copy link
 #12

Updated by Jim Pingle over 4 years ago

  • Target version changed from 2.5.0 to 2.4.5-p1
Actions
Copy link
 #13

Updated by Jim Pingle over 4 years ago

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

Updated by Jim Pingle over 4 years ago

  • Status changed from Feedback to Resolved

Can now set the type to Network and select a specific mask if necessary. When loading the saved value, the type is set back to address but keeps the correct value for the mask. Not sure if we need to care about that last part, but it's consistent with previous behavior and users can set a custom mask if needed as requested.

Actions
Copy link

Also available in: Atom PDF