Any plans to support Virtual Tunnel Interfaces (VTI) for IPSEC VPNs?

[awebster]

For the sake of simplicity and compatibility with other major player's VPNs, are there any plans to support Virtual Tunnel Interfaces (VTI) for IPSEC VPNs?

Virtual Tunnel Interfaces allow the use of dynamic routing protocols (OSPF, BGP, RIP) thus removing the need to define an IPSEC Phase 2 entry for each subnet pair that need to communicate with each other.
Major vendors such as Cisco, Paloalto Networks, Fortinet, Juniper all support this concept of dynamic routing over VPNs which greatly simplifies the setup particularly if the firewall is participating in a full-mesh VPN scenario.  Furthermore VTI is compatible between major vendors and not so major including vyatta, ubnt, and others.

GRE/GIF tunneling is for the most part not supported on the major vendor's platforms, making VTI the common denominator.

Any thoughts appreciated..

[jimp]

Routed IPsec is on our radar, no specific time frame or implementation details though.

[awebster]

Cool, thanks.

I actually got it so tantalizingly close, but got stuck…

I setup an IPSEC-SA with 0.0.0.0/32 <=> 0.0.0.0/32 which triggers "routed vpn" mode on my Paloalto firewall, so from its perspective everything is cool; VPN was up in routed mode.

Next, I ran tcpdump on enc0, and could see the traffic arriving, including OSPF packets from Paloalto firewall, but they just weren't going anywhere else.

Setting a tunnel endpoint IP on lo0 or lo1 didn't help
Setting the tunnel endpoint IP on gif0 did allow the packets to be picked off enc0 and enter the kernel, and actually get replied to! 
Quagga ospfd was seeing the Paloalto as a neighbor in INIT state.
But...and there is always a but...the response packets were going back out over an IPIP tunnel and not IPSEC so it didn't work :(

I think the path to this solution lies along the design of the gif0 driver, because it was able to pickup the packets from enc0 and actually process them.  It just needs to be able to put the packets back into the IPSEC tunnel in the end.

If any of this helped to lay the groundwork toward a solution, then it was time well spent.

[fredlubrano]

Hello,

Is the feature VTI Routed IPsec will be include in a future release ? or is this ever in your roadmap ? and when this feature will be available ?

Thanks

fred

[jimp]

@jimp:

Routed IPsec is on our radar, no specific time frame or implementation details though.

[fredlubrano]

Hello Jimp

I understand your answer, but this post date December 2015 when I thought meantime you had more news.
This function is essential for choosing our future equipment.
It is boring to choose a fortigate because pfsense Not VTI Routed IPsec . :'(

Thanks for the reply

Best regards,

fred

[dimostin]

Hello guys,

We have any news regarding Virtual Tunnel Interfaces (VTI) for IPSEC VPNs on PfSense equipments ?

Regards,
dimostin

[jimp]

Not possible currently, but the code for VTI was recently imported to FreeBSD, so it is going to show up in a future version eventually.

[Brailyn]

+1 for this:)

[kholmqvist]

+1 :)

[jimp]

It will be in pfSense 2.5, which will be based on FreeBSD 12, which has the IPsec VTI code. No ETA on that though, probably at least a year out, likely more.

[tweek]

Jim, what flavor of BGP will the new VTI code utilize, and would you be willing to add a module for the BIRD internet routing daemon?

[jimp]

It's too early to say for any of that. We are looking at FRR for all routing functionality though, no current plans for bird

[tweek]

If you could please consider BIRD for inclusion.  My router expert friend assures me BIRD is much more powerful and better architected than FRR.

[jimp]

@tweek:

If you could please consider BIRD for inclusion.  My router expert friend assures me BIRD is much more powerful and better architected than FRR.

Our router expert employees prefer FRR/Quagga and assure us it's better than BIRD in various ways.