Many https sites have trouble with loadbalancing. For security reasons they assume that when a session is suddenly change source ip, it must be "hacked".

it is allways a good idea to create a seperate gateway group in failover-mode for all https traffic, this will reduce trouble with financial transactions

The redirect-gateway def1 does not only add the 0.0.0.0/1 it also adds the 128.0.0.0/1 plus the x.x.x.74/32 pointing to your local gateway.

The route commands are to be used in a peer-to-peer connection and not in a PKI.

From your description i don't really see what your goal is.
If it is to simply have multiple VPN tunnels up and use failover pools between them:
In such a setup your routing table isn't relevant anyway.
You define gateways and traffic is forced to them directly, bypassing the routing table.

FYI- on 2.1 if you assign the openvpn interface and add a pass rule on its tab, that rule will get reply-to added so that the return traffic will flow back the right way without needing the extra NAT to mask the source address.

2.0.2 should be out in the near future (had a few things hold up the release… still trying to get it out) There are test images out there for 2.0.2, linked in a thread on the forum here.

2.1 will be out in the next few months if all goes well, realistically close to the start of the year, maybe later.

@phil.davis:

The DMZ OpenVPN Server end will need rules to allow traffic in from 172.242.242.0/24 - if the existing pass rules on OpenVPN are not wide enough already, then add one.
In the DMS OpenVPN Server Advanced box, you can just tell it routes, no need to "push" them from the other end. e.g.

route 172.242.242.0 255.255.255.0

This tells the server end that the OpenVPN link is the next hop for reaching 172.242.242.0/24
From your description, I think that is all that is needed - allow the packets into the DMZ pfSense from across the OpenVPN, then give the DMZ pfSense knowledge about how to route the responses back.

That did the trick!

thanks  ;D

@jimp:

I try to hand-deliver VPN configurations where possible, or at least put them into a directory that can only be accessed via something more secure (typically an SCP host set for key-only auth, etc).

You're right and I eventually came to the same conclusion. 
So I'm sending them a 15+ char disposable pass in an encrypted email that's good for a 3 hour download window from a server that publishes to rotating ports.

I've also been using pfBlocker to restrict server access to our local ISPs.

It's not a key but it's something.

When I stop OpenVPN service this root disappears.

I've tried to reboot it. Also I've tried to re-configure clean installation using i386 and amd64 2.0.1 releases.
Similar logs received.
I suppose that something has been changed on provider's side and I don't know what to change on my side to make it work.  :-\

The other thing to check is that the devices that do not respond (e.g. 192.168.0.115) do have their default gateway set to your pfSense LAN address (192.168.0.2). Devices like WiFi APs etc often get setup with their IP address/netmask on the LAN, but no-one enters a default gateway for them (or their default gateway is set to some old router address from years ago…). So they talk happily on the LAN, but can't get outside.

I didn't look hard at your pfSense version - 1.2.3. I updated one of those a few weeks ago, but I really have no useful memory of what the menus looked like - and certainly not how VPN was done! Someone else who knows the 1.2.3 menus and VPN please feel free to advise.

Thanks! It works

I created the certs but independent from the wizard. Maybe there went something wrong…
I will try it the next few days again and notify about the result.

mhab, I think this is a similar issue i am having which I believe is related to this bug:

http://redmine.pfsense.org/issues/2582

Post your smb.conf.

Useful thread, but I need a little more help.

What exactly is "route-metric 512" for?
It doesn't seem needed, pushing the route alone fixes the "unidentified network".

Also,
Win 7 firewall allows inbound echo's only on its subnet.
i.e. if Win 7 road warrior IP is 10.0.8.6 and VPN "home LAN" is 192.168.1.1
Win 7 will block the ICMP coming from the "home LAN".

Is there an elegant solution to this?
Changing firewall rules on each Win7 road warrior is far from ideal.

You're welcome!

I think there is something that remains unhappy when a carp virtual IP (VIP) (a setup with a live failover PF box waiting)  is used as the gateway on the lan side when the same PF box is used as the openvpn server via bridge and tap.   It all appears to work, but there are lots of unexpected log entries.    Still trying to track it down.  Also remember that all the traffic goes through the tunnel, so a slow 'upload' link on the openvpn server will be felt by the road warriors…

Clearly the whole 'tap' interface idea has the clean aspect of road warriors having the same ip whether on the local wifi not via openvpn or remotely via openvpn.   The biggest weakness the current openvpn tun mode has is that at least I haven't found a way to assign fixed static ip addresses to each of my road warriors--- short of creating a whole separate server instance for each of them, or just resorting to dropping the dhcp mechanism altogether and resorting to static IP's -- a pain to keep track of across the client boxes as they come and go.

A good upgrade for PFSense would be to store the XML in the openvpn client exporter, particularly the options and other details, so that later uses of the same certificate would recall the advanced options used the first time that cert was the source of an export activity.