@dolbie2: Site-to-Site followed exactly what the book said. In the book for the client configuration, the "Interface IP" is not specified but it is requred in pf1.2.3. How did you get past that? There was an issue in the book, you might need to read errata #2 here: http://www.reedmedia.net/books/pfsense/errata.html

its working.

Then double check that you also set TCP instead of UDP. The log seems to indicate it isn't making a connection at all. You probably need a firewall rule on WAN to allow that traffic in as well.

No, you can't use 1194 for a port forward and for incoming OpenVPN connections. Just run the pfSense instance on 1195 or any other port. It's not a big deal to adjust the clients to connect to the other port.

@jimp: You can try adding a push entry again for that subnet, or adding a route statement for the subnet to the loc3 client config. Yes it works!!!!! thanks Ive add a route to the loc3 client config

Hi, no matter about this, i found an entry in the logs for openVPN saying 'VERIFY ERROR: depth=1, error=certificate is not yet valid:' and it turned out to be an invalid time setting. Thanks

You need to setup the second OpenVPN instance manually, and on both of them, in the custom options put "local x.x.x.x;" where x.x.x.x is the CARP VIP on WAN. It doesn't really matter how you try to reach the secondary, its routing won't find its way back to the master from a VPN like that. A couple ways around it: 1. Put the master and slave OpenVPN instance on a separate subnet, and add a static route to the opposing router for that subnet or 2. Assign the OpenVPN interface as an opt interface, and setup NAT so that the traffic coming from OpenVPN and going to the secondary router has NAT applies such that it leaves from a VIP on the LAN side, so the secondary will only see that the traffic is coming from a LAN host and it should be able to get back to the source then.

ah cool… i figured it out! i think i just had to add the option 'local <wan carp="" ip="">' to the VPN's custom options in addition to the 'engine cryptodev' i also added an AON rule before trying this, which didn't help, but maybe it was needed too?  i made the rule for source <new 24="" subnet="">:* to : with NAT address<wan carp="" ip=""></wan></new></wan>

I found out how to do this. When making a an OPEN VPN tunnel there is a box labeled "other options" simply put the router there An example would be Branch A 192.168.1.xxx Branch B 192.168.2.xxx Headquarters 10.0.0.1 If they each branch has a tunnel to headquartes it will automatically add the correct routes for them to talk. However, branch a and branch b will not be able to communicate. On Branch A's router in the "other options" box simply enter route 192.168.2.0 255.255.255.0 and that will send traffic for branch b through headquarters. Of course you have to change branch b's as well to read route 192.168.1.0 255.255.255.0 as soon as that is done it will immediately start passing traffic.

@mrquintopolous: Hate replying to myself but apparently I need to setup routes on the servers … since this is a transparent bridge, traffic needs to hit the firewall for it to be encrypted, and not hit the default gateway which is on the other side of the firewall. Yes, if it's not directed to an IP on the firewall, it won't route it. Without that, you're directing the traffic to the default gateway, which the firewall isn't going to route, it'll pass to the default gateway as it should (that's what the host is telling it to do by using that dest MAC).

I've solved my own problem. The REAL default gateway at work needed a route added for the ADDRESS POOL, not the client side's LAN.  Using a route for the client side's LAN allowed them to see me, but not respond to me. Hope this helps anyone else attempting to configure a similar setup.

Ok, I assume thats installed from Packages and is fairly straight forward. I have the pfsense book so I will reference it and see if it mentions anything of it. Thanks for your help.

Is it choppy both ways?

I haven't tried that one, but I have used Pidgin+Bonjour to use local network chat across OpenVPN by running the Avahi package on both ends of the OpenVPN tunnel.

thanks, your suggestion worked