Peer to Peer without Tunnel Network?

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.