[SOLVED] OpenVPN multiple clients are assigned same virtual address v2.0.1

[MrEmbedded]

Been killing myself over this in the last 24 hours.

My setup is as follows:

• CARP VIP used for OpenVPN on interface (have tried IP alias also on WAN)

• 3 pfSense boxes with one acting as server and the others as clients with NAT type networks behind

• Generated certs on the server and imported them and the ca on the respective clients

• Setup everything using peer2peer ssl/tls as per http://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_PKI_(SSL)

My problem is that when connecting from a single client, everything works well.  However when I add the 2nd client everything breaks.  This seems to be because that the virtual addresses for both are identical.

Furthermore I have a /24 in use for the tunnel network and the address that shows up and duplicated is the x.x.x.2 address which I find kind of strange.  Its my understanding that OpenVPN carves out /30s for each client and the server as well so x.x.x.1 and x.x.x.2 should be used for the server.  Is this correct?

I am wondering if this is a NAT issue or not.   The server has manual outbound NAT for other configurations and I have added a rule for OpenVPN and its LAN network but it does nothing.  The clients both have automatic outbound NAT.

The thing is, at times I am able to get each client with a different virtual address by deleting certs/configs and redoing them.  I get x.x.x.6 and x.x.x.10 which is exactly what I would expect.  However the config doesn't hold long and will revert back to the multiple x.x.x.2 addresses on its own or after a restart of the OpenVPN service (not sure if its the client or server restart that triggers this)

Now I am having another situation where I have disabled one client and the remaining client still has the x.x.x.2 address.  Traffic seems to be passing and the link is connected but my thinking is that the address provided should be the next /30.

I can't seem to find the consistency here.  The OpenVPN logs all look good with no errors in them except for the certificate mitm warning.

One more tidbit.  Ping tests show a variety of scenarios.

When I am lucky to get the x.x.x.6 and x.x.x.10 addresses on the clients, I can ping from the clients to a machine behind the server on its LAN.  I can also ping from the server to each clients LAN gateway.

When both clients are connected with the x.x.x.2 addresses, only one can ping the machine behind the server, and the server can sometimes ping the LAN gateways of the clients.  There seems to be flip flopping here.

When the single client is connected with the x.x.x.2 address you can ping from the server to the client but not vice versa.

The routing tables look ok but show entries for x.x.x.1 as lo on the server side and as ovpncX on the client side and x.x.x.2 show as ovpncX on the server side and as lo on the client side.  I am a bit puzzled about this.

All the firewall rules are set to any/any for now.

I have read several posts on this forum and other OpenVPN forums suggesting to rebuild the CA and certs focusing on different content in each one, which I have done many times but the problem keeps coming back.  Those posts don't have any other resolution.  Rebooting doesn't seem to help either other than sometimes temporarily working depending on the configuration in use.

I can post logs if required.

The thing is, I had set this up using one of the 2.0 betas and it worked fine all the way up to 2.0.1 and I was asked to investigate the possibility of cross client connectivity (which should be a simple checkbox and maybe a pushed route) and it all broke and I can't even seem to roll the config back.  Reinstalling from scratch is not really an option.

I am at my end with this so if there is no advice, I think I will try to make more of a mesh topology instead of hub and spoke to see if that works.  I have seen a few posts about that but its neither here nor there.

[MrEmbedded]

For those of you in a similar situation, I scrapped that topology and went with a mesh like this: http://forum.pfsense.org/index.php/topic,41078.0.html

Get out a pencil and paper and draw it all out for clarity first. There will be plenty of settings to mess up so this is a good way to validate your work if you have trouble.

I put one client and one server on each box and cross connected them using a shared key setup.  One key point to note is that I setup the tunnel, local and remote networks for each client and server without using the advanced configuration for this feature.  In hind sight the original hub spoke topology I was attempting probably needs to be setup that way also with some primary networks, and any additional networks should be in the advanced configuration.  It would be a good test to make as the documentation specifically says to leave this blank and use the advanced configuration instead.  I guess that was probably meant for a 1:1 vpn connection and not for hub and spoke.

It works well and everything pings just fine from everywhere.

Because of my carp setup on one of the boxes I ran into this issue: http://forum.pfsense.org/index.php/topic,39199.0.html

Authenticate/Decrypt packet error: bad packet ID (may be a replay) 
```was showing up in the logs

It was simpler to fix than I thought.  The log message also tells you how to fix it (for a carp setup if you are sure there is nothing else bad going on):

-- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

So I just put the –mute-replay-warnings string in the advanced configuration for the server of the machine that had that in the logs and its suppressed that nicely.  There seems to be nothing adverse from doing this in my situation.

The last thing for me to do is to harden up the access from subnet to subnet with firewall rules on the openvpn interface and backup my configs.

I hope this helps someone.

[craigduff]

Surely there must be a better way than setting up a server and and client on each pfsense box. That just has to be!

[jimp]

The only way you get the same address is if:

1. The tunnel network isn't big enough (but I thought openvpn logged that as an error)
2. You're trying (incorrectly) to use the same client certificate on more than one client at the same time, and you don't have the box checked to allow duplicate connections (which is a bad idea).

When configured correctly, according to the wiki doc, that config works fine.