@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

I am still having this problem.  I have also tried just running openvpn from the command line using the above listed configs.  It just seems like the float command is not doing anything or is not working the way that it should.  I see the client try to re-establish the link, and the server just doesn't accept the connection.

Any thoughts / suggestions?

Thanks

Hi,

Problem Solved.

In WAN2 firewall rules for OPENVPN there was WAN2 gateway. I changed it to default gateway and it started working.

thanks

It seems to all be working now. I didnt change anything else so I am unsure what the cause was. Tomorrow I am bringing the 3rd branch online.

Not me, but someone else might.

It may just be a matter of setting up a FreeBSD 7.2 VM and recompiling openvpn with the option you want.