Bug #10418
closed
IPsec VTI address/mask selection not functional
Added by Danilo Zrenjanin about 4 years ago.
Updated almost 4 years ago.
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.
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.
- Status changed from New to Pull Request Review
- 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!
- 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>
- 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.
- Status changed from New to Pull Request Review
- Status changed from Pull Request Review to Feedback
PR has been merged. Thanks!
- 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
- Target version changed from 2.5.0 to 2.4.5-p1
- Status changed from Resolved to Feedback
- 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.
Also available in: Atom
PDF
Updated by Viktor Gurov 
Updated by 
Updated by