Bug #9592
closed
VTI interface down because interface number created is greater than ipsec32768
Added by Steven Perreau over 5 years ago.
Updated almost 4 years ago.
Affected Version:
2.4.4-p3
Description
In some conditions, when creating a VTI interface for routed IP, the interface number allocated is very high.
<opt9>
<descr><![CDATA[HO_SY1_WAN]]></descr>
<if>ipsec52000</if>
<enable></enable>
<spoofmac></spoofmac>
<mtu>1440</mtu>
<mss>1440</mss>
</opt9>
This seems to be happening with firewalls that already have a large number of traditional ipsec p1/p2 tunnels. The first VTI p2 I made started with ipsec52000 and the interface is permanently offline / down. Any additional VTI interfaces I create get an even higher interface number such as ipsec53000.
Obviously this breaks the VTI and you cannot get routed IP to work.
- Status changed from New to Pull Request Review
- Target version set to 2.5.0
- Status changed from Pull Request Review to Feedback
- Assignee set to Renato Botelho
- % Done changed from 0 to 100
PR has been merged. Thanks!
- Status changed from Feedback to Pull Request Review
- Status changed from Pull Request Review to Feedback
PR has been merged. Thanks!
- Assignee changed from Renato Botelho to Chris Linstruth
I created enough tunnels to get over what used to be 32768. Along the way I created two VTI tunnels. They were given interfaces ipsec3000 and ipsec6000. After there were enough tunnels to push the interface number past 32768, the VTI was given ipsec1.
If that is how it should work, it looks good. If the VTIs are supposed to start at con1 regardless of how many tunnels are already created, it doesn't seem to do that.
- Assignee changed from Chris Linstruth to Renato Botelho
Chris Linstruth wrote:
I created enough tunnels to get over what used to be 32768. Along the way I created two VTI tunnels. They were given interfaces ipsec3000 and ipsec6000. After there were enough tunnels to push the interface number past 32768, the VTI was given ipsec1.
If that is how it should work, it looks good. If the VTIs are supposed to start at con1 regardless of how many tunnels are already created, it doesn't seem to do that.
This is correct, and used for backward compatibility with pre-2.5 vti interface naming
see https://github.com/pfsense/pfsense/blob/3b88d9712b187602e946faeecc5f4902904b6d4c/src/etc/inc/interfaces.inc#L1379
- Status changed from Feedback to Resolved
- Status changed from Resolved to New
- Status changed from New to Pull Request Review
- Status changed from Pull Request Review to Feedback
PR has been merged. Thanks!
VTI map is created
<vtimaps>
<item>
<reqid>1</reqid>
<index>0</index>
<ifnum>1000</ifnum>
</item>
<item>
<reqid>2</reqid>
<index>0</index>
<ifnum>2000</ifnum>
</item>
</vtimaps>
IPsec IKEv2 VTI. 2.5.0.a.20201217.0648
- Status changed from Feedback to Resolved
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by Viktor Gurov 
Updated by 
Updated by