Peer to Peer without Tunnel Network?

JKnott

@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.

Derelict

The link would be interface ovpn[cs]X

jbredereck

@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!

jbredereck

@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)

Derelict

I don't think you understand what I am saying there.

jbredereck

@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?

jbredereck

@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.

JKnott

@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.

jbredereck

@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.2

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.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".

JKnott

@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.

jbredereck

@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.

jbredereck

@JKnott
@Derelict

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.

Derelict

As I explained, pfSense does not play well with unnumbered, point-to-point interfaces.

What is it that you want to happen here?

jbredereck

@Derelict said in Peer to Peer without Tunnel Network?:

As I explained, pfSense does not play well with unnumbered, point-to-point interfaces.

What is it that you want to happen here?

I want to understand why and how things work. That's all I want to happen here.

And if it's really the case that pfSense has problems with unnumbered point-to-point interfaces, then this would explain it. But just out of curiosity: What's the problem exactly with unnumbered point-to-point interfaces? I've been using those my entire professional life and never ran into any problems on Linux as well as on FreeBSD. Especially with OpenVPN unnumbered Point-to-Point-Interfaces are common practice and should work on pfSense as well.

Derelict

Mostly because policy routing in pf route-to and reply-to are tied to both an interface and a destination address, not just an interface.

A quick look says that might be possible to look at (ianap) but the current state of the code is what it is.

From my seat, if you want to use pfSense, re-configuring 20 sites to use a tunnel network isn't that much work. I can easily think of more implementations that needed the tunnel network for things like NAT than I can this requirement of absolutely no tunnel network addressing. As has been said, I think this is a first.

jbredereck

@Derelict

Alright, fair enough. Thanks for looking into this.

In this case we will just keep the VPNs on the old Edgerouter for now and migrate them to pfSense whenever a remote office router needs to be replaced.

Migrating everything else to pfSense worked like a charm and even though I might not have sounded like it, I really like pfSense and the netgate products.