Peer to Peer without Tunnel Network?
-
Hi,
we're currently migrating our UBNT Edgeroute on the head quarter to pfSense. We currently have 21 peer to peer VPNs to offsite locations which are still running UBNT Edgerouters.
A typical openvpn-config would look like this:
remote hostname-of-the-headquarter port 6018 proto tcp-client dev tun secret /config/kg2.key ifconfig 172.17.16.1 192.168.1.99 keepalive 10 120 persist-key persist-tun no-replay
As you can see, we don't use a tunnel network between the HQ-network (192.168.0.0/22) and the offsite-network (172.17.16.0/24). Instead OpenVPN is running a Point-to-Point-Connection between the generic IP addresses of the two routers (172.17.16.1/32 for the offsite router and 192.168.1.99/32 for the HQ router).
vtun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:172.17.16.1 P-t-P:192.168.1.99 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:53496 errors:0 dropped:0 overruns:0 frame:0 TX packets:34647 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:59266852 (56.5 MiB) TX bytes:2778576 (2.6 MiB)
I understand that pfSense wants me to create a so called "Tunnel Network" for the two OpenVPN interfaces.
My Question: is there any way to "convince" pfSense that this "Tunnel Network" is not necessary for a point-to-point link between the two networks?
The alternative would be creating 21 new tunnel networks and replacing all configs on all 21 offsite routers, which would be a real hassle, since it's technically not necessary. Ideally we would find a solution just to replace the OpenVPN endpoint in the head quarter without touching the configs at the offsite locations. Would that be possible with the above config? Are there any workarounds using the custom options in the pfSense GUI?
Thanks in advance!
Jörn -
Depending on the OpenVPN mode you can push the tunnel network to the Client.
I have 50 remote sites without any tunnel network manually configured there, that all happens at my HQ site.-Rico
-
@Rico said in Peer to Peer without Tunnel Network?:
Depending on the OpenVPN mode you can push the tunnel network to the Client.
I have 50 remote sites without any tunnel network manually configured there, that all happens at my HQ site.-Rico
well, the ifconfig statements have to match. And we're currently not using any tunnel networks at all, but simple point-to-point-connections, which is compeltely sufficient for site-to-site-VPNs. Tunnel-Networks are only necessary for road-warrior-setups, where several vpn-users share one tunnel network.
So the question remains: How can I setup a site-to-site VPN in pfsense that uses point-to-point-connections?
I tried overriding the "ifconfig"-statement in the custom options, but that didn't work.
-
AFAIK OpenVPN always use a tunnel network.
Maybe the UBNT OpenVPN is a special implementation and works without?-Rico
-
@Rico said in Peer to Peer without Tunnel Network?:
AFAIK OpenVPN always use a tunnel network.
Maybe the UBNT OpenVPN is a special implementation and works without?No, that's not UBNT specific. I've been building OpenVPN networks for the past 15 years (mostly on Debian Linux boxes) and always used point-to-point-connections without tunnel networks when building site-to-site VPNs.
All that pfSense does, when creating the config for a peer-to-peer VPN, is putting the following line in the server config:
ifconfig 192.168.1.1 192.168.1.2
(assuming that 192.168.1.0/24 ist the tunnel network)
You could as well just put the generic LAN IP address and the generic LAN IP of the offsite router in that ifconfig line and you're good to go for a point-to-point-link. A so called "tunnel network" is only necessary für point-to-multipoint connections, where several vpn endpoints get a dynamic address assigned (pushed) in a shared common transfer network.
I can't believe, that pfSense is not capable of creating point-to-point connections without a "tunnel network". That's why I'm hoping that someone can tell me how to do it, using the pfSense GUI.
Of course I could simply change the configs manually, but I'm pretty sure those manual configs will get overwritten by the GUI at some point...?
-
Been here a really long time, and have never seen this come up before.. Would be my guess why the option is not there..
I would suggest you just put in a feature request. I don't see why it couldn't just be a change in the what entries get presented to fill out when you select your vpn type.
Problem is, I don't think such a feature would be available to solve your immediate need.. Yeah since all stuff is stored in the xml, and then the confs get recreated on services starting and the like.. More than likely your config would get overwritten..
My only suggestion would to just use tunnel networks as the solution with the least amount of pain currently, even though would still be a bit of PITA ;) other options would be to edit the code yourself and patch it, or put in a bounty for someone to do it and then apply the patch, etc. etc.
-
@jbredereck said in Peer to Peer without Tunnel Network?:
My Question: is there any way to "convince" pfSense that this "Tunnel Network" is not necessary for a point-to-point link between the two networks?
What would you use for the point to point link, if not a tunnel? In the past, things like serial connections, frame relay, fractional T1, etc. were used for point to point links. The tunnel provides the connection between the 2 sites, just as those older methods would.
-
It sounds like they are using what would amount to an unnumbered interface and interface routes.
pfSense does not play nicely with that. It wants an address to route to.
-
@Derelict said in Peer to Peer without Tunnel Network?:
It sounds like they are using what would amount to an unnumbered interface and interface routes.
pfSense does not play nicely with that. It wants an address to route to.
They would still need some way to get from point A to point B. Unless they have a dedicated link, they need something beyond an interface. For example, they could set up PPP over some serial link and then they'd only need the interface to route through.
-
The link would be interface ovpn[cs]X
-
@JKnott said in Peer to Peer without Tunnel Network?:
@jbredereck said in Peer to Peer without Tunnel Network?:
My Question: is there any way to "convince" pfSense that this "Tunnel Network" is not necessary for a point-to-point link between the two networks?
What would you use for the point to point link, if not a tunnel? In the past, things like serial connections, frame relay, fractional T1, etc. were used for point to point links. The tunnel provides the connection between the 2 sites, just as those older methods would.
I appologize if I used to wrong terminology. Let me clarify: In TCP/IP there are IP subnets like 192.168.1.0/24 with up to (in this /24-example) 254 hosts that can communicate with other hosts which are part of the same subnet.
That's your typical ifconfig output of an interface of that kind:
[2.4.4-RELEASE][root@sinzheim.bw-networx.net]/root: ifconfig re1 re1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE> ether 00:01:2e:91:b3:e7 hwaddr 00:01:2e:91:b3:e7 inet 192.168.200.1 netmask 0xffffff00 broadcast 192.168.200.255 inet6 2a02:8071:31bb:68fc:201:2eff:xxxx:b3e7 prefixlen 62 inet6 fe80::1:1%re1 prefixlen 64 scopeid 0x2 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex>) status: active
You could actually set up an ethernet interface in that manner by using OpenVPN with so called "TAP"-interfaces that could be used to achieve a Layer2-Ethernet-Tunnel between two or more OpenVPN endpoints.
If you don't want to tunnel the entire layer2-broadcast domain you usually user layer3-TUN-interfaces. Those interfaces are by definition pointopoint interfaces. A typical ifconfig-output would look like this:
[2.4.4-RELEASE][root@sinzheim.bw-networx.net]/root: ifconfig ovpnc1 ovpnc1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> inet6 fe80::201:2eff:fe91:b3e6%ovpnc1 prefixlen 64 scopeid 0x9 inet 172.16.31.2 --> 172.16.31.1 netmask 0xffffffff nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> groups: tun openvpn Opened by PID 73575
Notice the word "POINTOPOINT" and the /32-Netmask (0xffffff).
Since this is already a pointopoint connection, it would absolutely sufficiant to use IP addresses of the local and remote network in a site-to-site setup. But what pfSense actually does, is creating a completely unnecessary transfer network called "tunnel network", by using the first and second IP of that "tunnel network" to make the ovpnc-interfaces talk to each other. In the above example it uses the "Tunnel Network" 172.16.31.0/24 to create the pointopoint-interface 172.16.31.1 on the local side of the tunnel and another pointopoint-interface 172.16.31.2 on the remote side of the tunnel. Additionally the remote subnet (in my example 172.16.30.0/24) is being routed over the remote point-to-point-address 172.16.31.2:
[2.4.4-RELEASE][root@sinzheim.bw-networx.net]/root: netstat -rn |grep ovpnc1 172.16.30.0/24 172.16.31.1 UGS ovpnc1 172.16.31.1 link#9 UH ovpnc1
Of course that works, and it's the right thing to do if you want to have a common subnet for a point-to-multipoint setup in which your have 3 or more openvpn endpoints talkt to each other, for example a number of road warriors "dialing in" to your pfSense via OpenVPN. But it doesn't make sense for a simple site-to-site-connection between two endpoints.
The way I have been setting up site-to-site tunnels for the last 15 years is like that:
Instead of using a "tunnel network" of 172.16.31.1 I would assign the local ovpnc-interface the same address as the lan interface. In my example: 192.168.200.1/24
The ovpnc-interface of the remote site would get the same ip address as the remote LAN interface. In my example 172.16.30.1/24.
And last but not least my local pfsense would route the remote LAN via the remote poin-to-point adress:[2.4.4-RELEASE][root@sinzheim.bw-networx.net]/root: netstat -rn |grep 172.16.30.0/24 172.16.30.0/24 172.16.30.1 UGS ovpnc1
The beauty of point-to-point-interfaces is actually that the two point-to-point partners don't HAVE to share a common ip subnet. So why create one in the first place?
And to show you the differences in the configuration files:
What pfsense does is creating the following file from my above example:
ifconfig 172.16.31.1 172.16.31.2 route 192.168.200.0 255.255.255.0
The way I would have created the file is like this:
ifconfig 172.16.30.1 192.168.200.1 route 192.168.200.0 255.255.255.0
This way the remote subnet 192.168.200.0/24 is being routed directly via the remote point-to-point address 192.168.200.1 (which makes much more sense since this is the actual LAN IP of the pfsense on the other side) instead of a dummy "tunnel network" address of 172.16.31.2. The entire "tunnel network" 172.16.31.0/24 is completely obsolete and makes site-to-site-VPNs on pfsense so much more complex since you need an additional network for each remote site. In our case that's 21 obsolete "tunnel networks", that make the troubleshooting and management of the routing table a lot more complicated.
Sorry, for long post, but from your replies it seemed like you misunderstood my initial post. And don't get me wrong: I'm not here to critize pfSense or the netgate developers. I was simply hoping, that there would be a workaround to omit the unnecessary "tunnel network" and route directly to the remote network via a corresponding point-to-point-address on the remote site. As you can see the only difference would be a different "ifconfig"-line in the config. That's it.
So, if someone knows how to replace that ifconfig-line in the config, please let me know. Thanks!
-
@Derelict said in Peer to Peer without Tunnel Network?:
It sounds like they are using what would amount to an unnumbered interface and interface routes.
pfSense does not play nicely with that. It wants an address to route to.
Nope, no unnumbered interface. Just point-to-point-interfaces using the actual LAN-IPs of the two sites instead of using addresses of an additional "tunnel network", which in fact isn't even a real /24-network but just a simple point-to-point link:
vtun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:172.17.16.1 P-t-P:192.168.1.99 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:53496 errors:0 dropped:0 overruns:0 frame:0 TX packets:34647 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:59266852 (56.5 MiB) TX bytes:2778576 (2.6 MiB)
-
I don't think you understand what I am saying there.
-
@JKnott said in Peer to Peer without Tunnel Network?:
@Derelict said in Peer to Peer without Tunnel Network?:
It sounds like they are using what would amount to an unnumbered interface and interface routes.
pfSense does not play nicely with that. It wants an address to route to.
They would still need some way to get from point A to point B. Unless they have a dedicated link, they need something beyond an interface. For example, they could set up PPP over some serial link and then they'd only need the interface to route through.
OpenVPN-tun-interfaces are basically PPP over encrypted UDP packets... At least the resulting point-to-point-interfaces are no different from a ppp-interface. So yes, your comparison is actually correct.
And since we figured out, that we're just using point-to-point here: why not use it as a point-to-point link? Since when do ppp-connections require a common "tunnel network"? Have you ever seen an ISP pushing your IP packets through a PPP /24 transfer network? While that would be perfectly possible (just the way pfsense does it) it wouldn't make sense. No, they give you /32-IP address on your PPP-interface while their own PPP-interface can be in a completely different subnet... no common /24 "tunnel network" required to exchange IP packets between the two endpoints:
pppoe0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1492 inet 92.74.251.133 --> 92.74.224.1 netmask 0xffffffff
Do you see a common /24 network here? No, 92.74.251.133 talks directly to 92.74.224.1 over a point-to-point link.
ovpnc1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 inet 172.16.31.2 --> 172.16.31.1 netmask 0xffffffff
Basically the same but pfsense insists, that 172.16.31.2 and 172.16.31.1 must be part of a common "tunnel network".
Instead I could just have:
ovpnc1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 inet 192.168.200.1 --> 172.16.30.1 netmask 0xffffffff
So why have a "tunnel network" in the first place, if we could just do point-to-point?
-
@Derelict said in Peer to Peer without Tunnel Network?:
I don't think you understand what I am saying there.
I know what unnumbered interfaces and interface routes are. But that's not what I'm talking about. I'm talking about good old point-to-point networking... just like in the old days with modems calling each other using PPP. OpenVPN isn't much different then that. A ovpnc-interface has the same characteristics as a ppp-interface. Therefore the same rules apply: You can just exchange IP packets without the need for a common transfer net. But pfsense insists to create such a common transfer net, and I just want to understand why or how to work around this.
-
@jbredereck said in Peer to Peer without Tunnel Network?:
Since this is already a pointopoint connection, it would absolutely sufficiant to use IP addresses of the local and remote network in a site-to-site setup. But what pfSense actually does, is creating a completely unnecessary transfer network called "tunnel network", by using the first and second IP of that "tunnel network" to make the ovpnc-interfaces talk to each other.
Nope, no unnumbered interface. Just point-to-point-interfaces using the actual LAN-IPs of the two sites instead of using addresses of an additional "tunnel network", which in fact isn't even a real /24-network but just a simple point-to-point link
Which LAN addresses are you talking about? If the RFC1918 addresses behind NAT are used, there is no way it's going to work.
And since we figured out, that we're just using point-to-point here: why not use it as a point-to-point link? Since when do ppp-connections require a common "tunnel network"? Have you ever seen an ISP pushing your IP packets through a PPP /24 transfer network?
Who says you have to use a /24? Point to point links need only a /31 or /30, depending on the OS. A point to point link should be able to be specified by the interface, as there is only one possible destination. I don't know if pfSense supports specifying the interface, but the underlying FreeBSD should be able to handle it.
I just tried an experiment. I created a gateway specifying my OpenVPN interface only, without any gateway IP address and it accepted it. I don't know if it will work though. Why not try doing that and see if it works.
However, no matter how you set up the link, you still have to specify the routes etc.
-
@JKnott said in Peer to Peer without Tunnel Network?:
Nope, no unnumbered interface. Just point-to-point-interfaces using the actual LAN-IPs of the two sites instead of using addresses of an additional "tunnel network", which in fact isn't even a real /24-network but just a simple point-to-point link
Which LAN addresses are you talking about? If the RFC1918 addresses behind NAT are used, there is no way it's going to work.
The tunnel network has nothing to do with the transport of the OpenVPN-UDP-Packets over the public internet. What pfsense calls "tunnel network" is just a pseudo-network to assign IP adresses for the ovpnc-interfaces from. All those IP addresses are RfC1918.
What I meant by "LAN adresses" are the IP addresses of the local LAN interfaces.
In my example:
192.168.200.1/24 (site "Sinzheim")
re1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE> ether 00:01:2e:91:b3:e7 hwaddr 00:01:2e:91:b3:e7 inet 192.168.200.1 netmask 0xffffff00 broadcast 192.168.200.255 inet6 2a02:8071:31bb:68fc:201:2eff:fe91:b3e7 prefixlen 62 inet6 fe80::1:1%re1 prefixlen 64 scopeid 0x2 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex>) status: active
172.16.30.1/24 (site "Nuernberg")
xn1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 8e:39:13:3b:fa:02 hwaddr 8e:39:13:3b:fa:02 inet6 fe80::8c39:13ff:fe3b:fa02%xn1 prefixlen 64 scopeid 0x6 inet 172.16.30.1 netmask 0xffffff00 broadcast 172.16.30.255 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet manual status: active
In order to connect those two sites, pfsense forces me to create a dummy "tunnel network". I chose 172.16.31.0/24 in this example.
As result in "Nuernberg" it created the ovpns1-interface 172.16.31.1.
And in "Sinzheim" it created the ovpnc1-interface 172.16.31.2ovpns1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> inet6 fe80::250:56ff:fe00:8bc3%ovpns1 prefixlen 64 scopeid 0xa inet 172.16.31.1 --> 172.16.31.2 netmask 0xffffffff nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> groups: tun openvpn Opened by PID 27615
ovpnc1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> inet6 fe80::201:2eff:fe91:b3e6%ovpnc1 prefixlen 64 scopeid 0x9 inet 172.16.31.2 --> 172.16.31.1 netmask 0xffffffff nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> groups: tun openvpn Opened by PID 73575
What I would like to see are pointo-point-interface with the actuall IP adresses of the LAN interfaces. For example in "Nuernberg":
ovpns1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> inet6 fe80::250:56ff:fe00:8bc3%ovpns1 prefixlen 64 scopeid 0xa inet 172.16.30.1 --> 192.168.200.1 netmask 0xffffffff nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> groups: tun openvpn Opened by PID 27615
And in "Sinzheim":
ovpnc1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> inet6 fe80::201:2eff:fe91:b3e6%ovpnc1 prefixlen 64 scopeid 0x9 inet 192.168.200.1 --> 172.16.30.1 netmask 0xffffffff nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> groups: tun openvpn Opened by PID 73575
As you can see: no need for a 172.16.31.0/24 "tunnel network". 192.168.200.0/24 can talk directly to 172.16.30.0/24 if you set the corresponding /24-routes via the corresponding remote-point-to-point next-hop.
And since we figured out, that we're just using point-to-point here: why not use it as a point-to-point link? Since when do ppp-connections require a common "tunnel network"? Have you ever seen an ISP pushing your IP packets through a PPP /24 transfer network?
Who says you have to use a /24? Point to point links need only a /31 or /30, depending on the OS.
It doesn't actually matter what netmask you're using since pfsense doesn't even create such a transfer net. As with all point-to-point interfaces the netmask is ALWAYS /32. The fact that the netmask you're using in the pfsense gui for the tunnel network is absolutely irrelevant should actually be a good indicator that the entire "tunnel network" is irrelevant in site-to-site-networks since we're always using /32-point-to-point connections.
Just check the netmask of any ovpn(s|c)-site-to-site-interface on your pfsense box und you will never find anything other than /32 (0xffffff). So why ask for a netmask in the GUI in the first place?
I just tried an experiment. I created a gateway specifying my OpenVPN interface only, without any gateway IP address and it accepted it. I don't know if it will work though. Why not try doing that and see if it works.
You're talking about an interface route. While that might work, it doesn't solve the problem, since in order to create the openvpn endpoint in the first place I have to create a "tunnel network" anyway and OpenVPN will use the first and second IP adress of that tunnel network.
Just look at your openvpn-config in the /var/etc/openvpn directory. No matter which netmask you supply in the GUI it always creates an "ifconfig"-entry with the first and second IP of that "tunnel network". For example if you use 192.168.5.0/30 as your "tunnel network" it will put the following line in your config on the server side:
ifconfig 192.168.5.1 192.168.5.2
and
ifconfig 192.168.2 192.168.5.1
on the client side.
And this will create a /32-point-to-point-Interface on both ends of the tunnel. Afterwards the remote network is being routed via the remote point-to-point address.
And as I said before: There's nothing wrong with it, and it works of course. But it just doesn't make sense, since you could just put the following line in your config:
ifconfig 192.168.200.1 172.16.30.1
This would create a point-to-point-link DIRECTLY between your two LAN networks without having to use IP space from a third (unrelated) "tunnel network".
-
@jbredereck said in Peer to Peer without Tunnel Network?:
192.168.200.1/24 (site "Sinzheim")
172.16.30.1/24 (site "Nuernberg")How do you proposed reaching those addresses over the Internet?
In order to connect those two sites, pfsense forces me to create a dummy "tunnel network".
That tunnel network is how the packets get from A to B. You at least have to create an interface that you can point to, to get to the other end.
What I would like to see are pointo-point-interface with the actuall IP adresses of the LAN interfaces. For example in "Nuernberg":
Those RFC1918 addresses are not allowed on the Internet. There is no way to do what you want without a tunnel or point to point link of some sort.
-
@JKnott said in Peer to Peer without Tunnel Network?:
@jbredereck said in Peer to Peer without Tunnel Network?:
192.168.200.1/24 (site "Sinzheim")
172.16.30.1/24 (site "Nuernberg")How do you proposed reaching those addresses over the Internet?
Those are the addresses INSIDE the tunnel. Not the public addresses for the OpenVPN-UDP-Traffic.
In order to connect those two sites, pfsense forces me to create a dummy "tunnel network".
That tunnel network is how the packets get from A to B. You at least have to create an interface that you can point to, to get to the other end.
That tunnel network is nothing more than an random ip range from which pfsense takes the first 2 addresses to create a point-to-point ovpnc or ovpns interface. Instead of using IP addresses from a random IP range you could as well just use the ACTUAL internal IP addresses for the tunnel network.
What I would like to see are pointo-point-interface with the actuall IP adresses of the LAN interfaces. For example in "Nuernberg":
Those RFC1918 addresses are not allowed on the Internet. There is no way to do what you want without a tunnel or point to point link of some sort.
I'm afraid you misunderstood: I'm talking about the pointopoint network between A and B. This pointopoint-network is INSIDE the tunnel and therefore doesn't have to get routed over the public internet. The so called "tunnel network" always uses private RfC1918 addresses. What IP subnet are you using for your tunnel network in your setup? Are those public IPs?
And as I mentioned before: I'm building OpenVPN-networks for more than 15 years now for hundreds of customers, and I've never used a "tunnel network" in my entire life before I came across pfSense. I have always used the generic LAN IPs for the point-to-point-interfaces to have them talk to each other directly without the need of an additional transfer net.
A transfer net is something you would use to connect two routers via an ethernet segment. But point-to-point isn't ethernet. And while it's possible to create a pseudo transfer net for a point-to-point-link it's completely unnecessary and complicates things.
-
By the way: I just checked the official openvpn documention:
https://community.openvpn.net/openvpn/wiki/Topology
The documentation perfectly describes that the IP addresses of what pfSense calls "tunnel network" are completely arbitrary. Quoting from the documentation:
...thanks to the nature of Point-to-Point networking, the IPs are arbitrary and serve only to mean "this end" or "that end." It is not necessary these IPs be adjacent, and generally won't be for a client.
And since those Point-to-Point-IP-addresses are arbitrary you could as well just use the actual IP addresses of the corresponding LAN interfaces that you're trying to connect instead of using some random and completely unnecessary additional "tunnel network" IP addresses.