Tunnel Netmask must be /31?
-
I had trouble getting a site-to-site PKI connection working. I used a tunnel network of 10.0.0.0/24 (a slight variation of the recommended numbering 10.0.8.0/24).
In this configuration only the client pfsense itself was able to ping hosts on the remote (server) network. Clients were not. I noted that the routing table of the client pfsense mentioned three ip addresses 10.0.0.1 and 10.0.0.5 and 10.0.0.6.
Changing the netmask to /31 caused the numbering to become more reasonable: 10.0.0.1 and 10.0.0.2, and the tunnel to start working properly.
I don't understand what is going on here. Is the tunnel network address of 10.0.8.0 special in some way? Is this a bug?
Here is the routing table of the client pfsense when things were broken. Note the upstream link of this machine is a 192 network.
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.7.1 UGS 0 4666 vr1
10.0.0.1/32 10.0.0.5 UGS 0 0 ovpnc2
10.0.0.5 link#9 UH 0 0 ovpnc2
10.0.0.6 link#9 UHS 0 0 lo0
domain.redacted.com 00:00:24:cb:18:cd UHS 0 31 vr1
101.0.0.0 10.0.0.5 UGS 0 0 ovpnc2
localhost link#5 UH 0 186 lo0
192.168.1.0 10.0.0.5 UGS 0 26 ovpnc2
192.168.7.0 link#2 U 0 627 vr1
192.168.7.101 link#2 UHS 0 0 lo0
192.168.150.0 link#1 U 0 3588 vr0
pfSense link#1 UHS 0 0 lo0And when working
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.7.1 UGS 0 9053 vr1
10.0.0.1 link#9 UH 0 0 ovpnc2
10.0.0.2 link#9 UHS 0 0 lo0
domain.redacted.com 00:00:24:cb:18:cd UHS 0 50 vr1
101.0.0.0 10.0.0.1 UGS 0 0 ovpnc2
localhost link#5 UH 0 217 lo0
192.168.1.0 10.0.0.1 UGS 0 192 ovpnc2
192.168.7.0 link#2 U 0 1352 vr1
192.168.7.101 link#2 UHS 0 0 lo0
192.168.150.0 link#1 U 0 6447 vr0
pfSense link#1 UHS 0 0 lo0 -
There's nothing special in the numbering or subnetting or mask. Something else going on there aside from just changing the mask, no telling what from that. Check the client log.
-
Actually on site-to-site PKI the subnet mask is important:
For /30 and "smaller" networks it does NOT use "server" mode in OpenVPN - meaning, it works like Static Key - you don't need to use iroutes and you can't push routes, but it you can only have one client.
For larger subnets, it uses server mode so you need routes and iroutes to connect to the potential multiple clients.
http://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_PKI_%28SSL%29 -
Actually on site-to-site PKI the subnet mask is important:
For /30 and "smaller" networks it does NOT use "server" mode in OpenVPN - meaning, it works like Static Key - you don't need to use iroutes and you can't push routes, but it you can only have one client.
For larger subnets, it uses server mode so you need routes and iroutes to connect to the potential multiple clients.
http://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_PKI_%28SSL%29Thanks for this. I just spent all day building this is a virtual environment. I can confirm that 10.0.8.0/24 does not work when 10.0.8.0/31 does.
I think as a general rule these hints on the setup pages should be removed if they do not apply in all cases. Otherwise people like me waste a lot of time. I filed a feature request to this effect for another OpenVPN "gotcha", but it was rejected.
-
/24 does work, you just didn't have the rest of the setup in place to handle doing /24.
/30 is simpler, it doesn't require the extra work that /24 does. See the link I posted for the rest of how to make it work with /24, you need to add client-specific override entries with iroute statements, etc.
-
If we removed every hint that didn't apply in every possible case, there would be no hints left anywhere. If we added explanation of every possibility, every page of the web interface would be 100 pages long and completely impossible to work with. What we have is a good balance, the hints that are there apply to the vast majority, and the documentation fills in the explanation.
-
@cmb:
If we removed every hint that didn't apply in every possible case, there would be no hints left anywhere. If we added explanation of every possibility, every page of the web interface would be 100 pages long and completely impossible to work with. What we have is a good balance, the hints that are there apply to the vast majority, and the documentation fills in the explanation.
These hints don't apply in the default case though.
-
yes they do.