site-to-site ssl/tls with ospf
-
Hi,
i wish to migrate all legacy shared-key site-to-site setups to a hub-spoke topology
i've tried setting up a tunnel between two pfsense devices using ssl/tls using https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-tls.html
frr-ospf is used to distribute the routes/subnets between all sites.i've found out that i can get it to work with a /30 tunnel subnet. (docs indicate this is deprecated + this prevents hub-spoke)
but with any tunnel-subnet larger then /30 communication fails.when using for example tunnel-subnet of /24:
- then ospf is able to update the routing tables on both ends of the tunnel
- traffic from LAN_A <- tunnel -> LAN_B does not work. pings from tunnel_IP_A <-> tunnel_IP_B work just fine
- packet capture shows that packets are entering the tunnel at "A" (ovpnsX) , but packetcapture on "B" (ovpncY) does not receive them.
Further investigation showed that manually specifying the "CSO" remote networks as specified in the docs solves the communication errors. ...
But manually entering remote subnets is not something i wish todo - that's why i'm using a routing-protocol (ospf).
manuals seem indicate that CSO uses "iroute" ????TLDR: is there any way to use a /24 tunnel subnet in combination with ospf - without having to deal with manual entering subnets into CSO ?
oh yeah: i wouldn't mind changing to something other then openvpn if this would help
thanks :)
-
@heper bump
-
@heper bump2
-
@heper bump3
-
@heper I'm doing something similar as we speak and running into similar issues, so I'm glad you posted. Same symptoms… data flows between tunnel endpoints, but doesn't seem to exit the tunnel, even with appropriate routes configured via OSPF.
I have found that you really do have to set up a /24 for the tunnel network and configure the iroutes using "Client Specific Overrides" inside OpenVPN on the server, otherwise data doesn't flow, even with OSPF. This seems to be a new behavior with SSL/TLS relative to shared-key.
I assume you've seen this, which I find works:
https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-tls.htmlAnd it sounds like you're trying to do what I want to do, which is skip the client-specific-overrides manual configuration and let OSPF handle this instead. I've not found a way to do that, yet.
Edit to add this explanation for posterity, as I have a tendency to search something and turn up my own threads in the distant future: https://forums.openvpn.net/viewtopic.php?t=26839
I'm looking for any kind of OpenVPN option to deal with this, but it sounds like OpenVPN's design precludes any other arrangement. Using a /30 causes a lot of unexpected behavior I suppose I need to investigate.
Wireguard is an option, and it's far easier to set up. For IPv4 only, it might fit your bill. With IPv6, you can't use a link-local address following convention without using a virtual IP that has a tendency to go away if the connection drops. Not quite ready to trust WG on pfSense yet.
IPSEC is also an option, but it doesn't work for one of my remote sites that is cellular and trapped behind multiple layers of NAT.
-
@deet
A Client Specific Override is essential, whenever the tunnel is bigger than a /30.
You cannot route traffic directly to the client in this setup. This have to be done within the OpenVPN server.Stating the remote networks in the server settings routes the concerned traffic to the OpenVPN server and with the CSO the server forwards it to the proper client.
A /30 tunnel network would not be compatible with DCO though.
-
@viragomann so basically its impossible to let ospf handle routing unless one uses the deprecated /30 ?
this also means its not possible to create a hub-spoke setup
-
@heper said in site-to-site ssl/tls with ospf:
TLDR: is there any way to use a /24 tunnel subnet in combination with ospf - without having to deal with manual entering subnets into CSO ?
You may have to set the interface to Broadcast under OSPF interface settings. Just a guess but a /30 would most likely be seen as a point2point ospf network type whereas a Broadcast assumes an ethernet segment.
Although if you are using hub/spoke, in that type of design all the links to the hub would be a /30 or /31. There would only be one other neighbor in a hub/spoke set up. -
@heper Pretty much
I'm moving forward now with a separate OpenVPN tunnel per remote site, each on a /30 point-to-point link. Deprecated or not, this works more or less as expected. I'm willing to do a little more manual config on each end of the tunnel in order not to have to do a whole lot of manual routing work.
Good luck to ya
-
@deet said in site-to-site ssl/tls with ospf:
I'm moving forward now with a separate OpenVPN tunnel per remote site, each on a /30 point-to-point link. Deprecated or not
If you are willing to spin up a new VPN overlay why not just use IPsec. Easier to maintain and run dynamic protocols and there are no deprecation notices.