Why client-to-client doesn't work using PSK or am I just assuming?

torontob

Hi Everyone,

What is the point of PSK method for OpenVPN if client to client can not be done? I notice that picking up PSK method greys-out the client-to-client field on the server side for OpenvPN setting.

I can get a PSK tunnel setup and running but only the two pfSense servers can ping each other and not the clients on their both sides. Both sides use CentOS. Do I need to add static routes on the CentOS server on two sides to do client-to-client? or do I need to push routes somehow?

Please detail your configuration. Thanks

jimp

With Shared Key, you can't have more than one client on a single server, so client-to-client is a moot point. There is only a single client, and a single server, and they can talk to each other fine.

For additional clients, you need additional servers, but you need to give the proper routes to each so they can reach each other. You can't push routes with PSK, so you need to specify them in the client config.

Sounds like you really need PKI mode for what you want, not shared key.

torontob

Thanks for the input.

So, I guess PSK is only good to reach the pfsense router for it's configuration?

But I am also thinking that theoretically I should be able to reach clients behind pfSense router if I do static routes? However I am definitly not clear how to do that using two pfSenses on two sides as you mentioned that push doesn't work. Can you please detail the Client Config part?

If two routers reach each other then it should be simple to allow the clients behind each router to reach each other as well too….am I missing something?

Thanks

jimp

It's easy to do any of that with PSK, just add route statements to the configuration that tell it what networks can be reached via that instance. Doing PKI would let you push the routes out automatically to clients instead of adding them manually.

So on pfSense server A, with lan A, trying to go to your remote network B, in the server config on A under remote network, put in the IP/CIDR for network B.

In the OpenVPN client config for B trying to get back to A, just add:

route a.a.a.a 255.255.255.a

Substitute your own values for a's in that of course. That tells the system at B that it can reach A via the OpenVPN tunnel.

torontob

Thanks for the input. All clear except for the last part:

route a.a.a.a 255.255.255.a

^^^ Is that in the custom options part of the client setup on pfsense client? I thought you said custom options can't be passed along.

Also, just to make sure, in none of your post you meant to tamper with Client Specific Config TAB on either side right?

Thanks

jimp

What you're saying isn't making much sense, unless I've misread/misinterpreted some of your earlier statements. Is this pfSense on both ends or pfSense-to-CentOS?

If it's pfSense on both ends, the config box on both sides for "remote network" is sufficient if you only have one subnet behind each router. It adds a route statement into the config automatically.

If the server is pfSense but the OpenVPN client software in running on a CentOS box, the route would need added to the client config there.

torontob

Got it. I could be using both methodes but I was referring to two pfsenses case in my last post. I also get it that if PSK is being used with two pfsense routers then no woodoo is needed and both sides should be able to reach each other client-to-client.

e.g. subnet A - > pfsensB –--Internet PSK ----- pfsenseB <- subnetB

SubnetA would be able to ping SubnetB without any further settings setup other than server and client on openvpn and putting the right fields and not using the Custom Options at all?!

Thanks

jimp

Correct, no custom options are needed when going from pfSense to pfSense because on both sides the GUI has a field to list the remote side network.

Then so long as the pfSense routers doing OpenVPN are the default gateway of the internal networks on both sides, everyone can talk back and forth.