There is a box on the server config:

Concurrent connections
Specify the maximum number of clients allowed to concurrently connect to this server.

That limits the how many total connections can exist to the server.

Thanks for the reply.

The windows firewall was disabled on the server.

I've tried it in reverse, and that worked.

tracert 10.0.101.3 Tracing route to W7WS [10.0.101.3] over a maximum of 30 hops:   1    <1 ms    <1 ms    <1 ms  172.28.1.1   2    41 ms    41 ms    40 ms  10.0.2.1   3    77 ms    76 ms    76 ms  W7WS [10.0.101.3] Trace complete.

I then tried accessing a non Windows Server and that worked too.

After a bit more hunting round (as I said it's a network that I've inherited very recently) there was a firewall enabled on windows servers at the remote sites by the Endpoint Security with trusted networks that didn't include the VPN Network.

I have an example install like this. The real internet comes through a Tp-link ADSL router (also has WiFi builtin) to an internal network - 10.49.120.0/24. The TP-Link is 10.49.120.41/24 and also has its wireless enabled so people with WiFi devices can connect to the LAN. But DHCP on the TP-Link is turned off.

The pfSense is an Alix box with just the WAN port connected to this internal LAN and has address 10.49.120.250/24, and default gateway 10.49.120.41 (the TP-Link). pfSense DHCP is enabled, it gives out a range of addresses 10.49.120.100-199/24 with itself as the gateway. Manual Outbound NAT is enabled, and a rule added so that traffic from the clients comes into pfSense and then is NAT'd out through the TP-Link to the internet. (see screenshot - last rule) The advantage of this is that the TP-Link sees all the traffic as originating from the pfSense WAN IP 10.49.120.250 - so when traffic comes back in response, it is routed back to the pfSense, which can "unNAT" it and deliver to the original client. This means that pfSense can work properly (traffic flow in both directions goes through it) and you can do whatever filtering there.

The pfSense has OpenVPN clients connecting out to other offices. The DNS Forwarder has Domain Overrides added to refer internal names to other office DNS Servers for internal resolution. Because the clients on the LAN (which to this pfSense is WAN) are using pfSense completely as their gateway, they can happily talk internally to things across the internal OpenVPN links, or externally to the real internet. The pfSense does all that for them.

The main requirement is that you have a way to NOT get DHCP from the current default gateway (equivalent of the TP-Link in this example) - either disable DHCP on the current default gateway, or manually configure IP on the clients that you care about, so they use pfSense as their default gateway and DNS.

(Note: in the screenshot 10.49.122.0/24 is the pfSense LAN port - there is nothing connected to that, but it would work as another routable subnet if needed/useful)

IJP-Manual-NAT.png
IJP-Manual-NAT.png_thumb

Couple things:

In the Cryptographic Settings section, make sure you have a Peer Certificate Revocation List listed

If the remote host has a software firewall enabled, make sure it is configured to respond to icmp

What is the IP of the machine you are coming from?  Make sure it's not on the 192.168.101.0/24 network

It looks like my cluster configuration is somehow "crippled", the openvpn problem i have must be a collateral damage.
I'll update as soon as i'll have resolved.

In that way, if HDSL link goes down, all services will be still reachable via VPN / WAN2 link, even WAN2 is a private/natted connection.

yes probably

Also, if the WAN2 link goes down, VPN can be activated via WAN1, and again all services are available on both public IP.

this might be a little tricky … there is, by my knowledge, no way to "activate" an openvpn connection upon failure.

two things that might be worth a shot:
-run the openvpn client (pfsense) on a virtual ip on the LAN interface and use a failover group to decide what WAN interface the client should connect to the server <-- perhaps someone has done this allready
-perhaps the vpn provider is willing to offer 2 seperate openvpn connection, attached to the same public-ip ?

Do you think is it possible ?  How I can manage the VPN as a WAN3 ?  Have someone any other suggestion ?

most of it yes, some detail are a maybe. assign an interface to openvpn (interfaces–>assign). Lots of folks will probably have suggestions about the details :)

Solved :

A /30 will only work if you set up this with a shared key.
For site-to-site you should use a shared key.
Yes you will have to set an interface IP, because with a shared key no routes/IPs/DHCP-settings/anything will be pushed from the server.
The configuration is only what you put into the config file.

The reason why a /30 with a PKI won't work:
In a PKI you have the x.1 IP for the server.
Every time a client connects a new dynamic /30 subnet is added to the virtual interface.
So
x.0/30 initial IP of the Server.
x.4/30 first client (x.5 server, x.6 client)
x.8/30 second client (x.9 server, x.10 client)
etc.
This ensures that the clients can talk only with the server and not with each other directly.

HA! I feel dumb now :) Thank you for the quick response, and for the link!

Thanks, fixed.  I had to create both WAN and LAN rules specifying the correct gateway interface.

The keys to operate the VPN are kept in config.xml and will upgrade.

If you want to start managing the keys from the GUI rather than easyrsa, then see this:
http://doc.pfsense.org/index.php/Using_EasyRSA_Certificates_in_2.x

I have no experience in making an OpenVPN connection be NAt'd on arriving into the local LAN. Someone who has some idea (or can say why it is not possible), please feel free to advise!

Thankyou, an entry in site B domain overrides pointing the domain to site B's DNS server did trick.

@AlanMAC:

Thanks guys! I did a write up, which is attached. Hopefully someone will find it useful.

Thanks Much for the write up, i haven't tried it yet (will do in the coming days) appreciate the effort  ;)

Thanks again, you are my hero!

Site to site VPNs should never be bridged, that's a bad network design that's begging for problems. Not related to the problem, but I'd stop trying to fix something that shouldn't be done, and put a proper routed setup in place.