@Topogigio the problem persists. After a few days pfSense stops binding the IP address on the established tunnel interface.
I've started to build a new opnSense gateway, but if there is some pfSense solution I'll be happy

@keyser Oof. Sounds like I'm in unsupported configuration territory here.

I'll see how it performs in a lab.

Thanks for the suggestion but unfortunately no PING.
Since I am able to ping 172.30.2.1 (but not 172.30.2.2), could it be something related to firewall or routing?

Update 2:
Added an alias for RFC1918 networks and configured an outbound NAT rule with RFC1918 as source and any destination on all pfSenses.
This solved what seemed like a routing problem but turned out to be a NATing problem.
However I'll probably have issues if/when I have multiple WAN connections.
Still would like to hear if there are any best practices.

@jimp said in IPv4 VTI tunnel - set network mask:

It is intended to assume /30 there since it's point-to-point. Though I could see how /31 might work for some.

We recently did fix a bug here, https://redmine.pfsense.org/issues/10418, but that was after 2.4.5 was created.
Ok, then I know why.

In 2.4.5 you could change the mode to tunnel, change the type to network, then fix the mask, then switch back to VTI and save.
We might have to revisit https://redmine.pfsense.org/issues/10418 before the next release yet.

The work-around works. I can live with that for now. Thanks for the hint.
Edit: the assigned interface does not seem to come up.

I changed this particular tunnel to be a /30 to check. The interface does not show up when calling "ifconfig" from the command line. It can be assingned under "Interfaces / Interface Assignments". The IPsec tunnel shows as up in the IPSec status tab. -> New thread for this issue as I see it with a separate tunnel as well: https://forum.netgate.com/topic/152246/interface-ipsec6000-not-being-added-for-vti-tunnel