Fixed.

It appears I've figured out what was causing this, but not exactly why it was causing it.

The two locations having this problem each use their own 4G router as a backup WAN (set as tier 2 in a failover group that the LAN points to), and the router is set to automatically reboot every Sunday morning. When I tested by initiating a reboot of the 4G router with a running ping to the remote LAN network, sure enough the tunnel stopped passing traffic about 30 seconds after beginning the reboot. This happened reliably when trying it for both locations. Once again, going into the remote firewall and restarting the OpenVPN client connection brought it back.

So now it's a curiousity why bouncing a tier 2 and not-currently-active WAN connection would break an OpenVPN tunnel.

No, that's not already done. You are setting up the port-forward on LAN, according to the screenshot. It won't do anything useful there. Also, if you have any rules on OpenVPN tab, remove them.

Your site-to-site and remote access OpenVPN instances are both on 1195 on site 1?

Thanks Jim.  I've seen many a bandwidth provider (Comcast primarily) actually strip tagging once the packet reaches their network, so this would simply accomplish ensuring that the PFSense is forwarding VOIP packets before others, whether inside a tunnel or not.  Actually, this is good news for VPN tunnel QOS, as I've seen several postings on here arguing that QOS within a tunnel doesn't work.  While that is technically correct, this feature at least allows for QOS on specific traffic, whether its inside a tunnel or not.

You didn't mention which pfSense version you're using in all this?

If this is the same configuration as your previous thread (https://forum.pfsense.org/index.php?topic=93729.msg520236#msg520236, then the simplest solution IMHO is to change your setup slightly so that the HO has only 1 OpenVPN server that handles both BrO1 and BrO2.

You tell the OpenVPN server about all the remote networks in a comma separated list entered in "IPv4 Local Network/s" (192.168.1.0/24, 192.168.0.0/24 in your case).
You use the Client Specific Configurations on the server to specify which remote network gets routed to which client (this has to be currently working or your dual server setup wouldn't be working now)

The BrO1 and BrO2 clients both connect to the same HO OpenVPN server and the CSC settings make sure things are routed where they need to go.  The server hands out all external routes to both clients so they understand how to get to each other's networks (through the server).

The only other way is to setup say, BrO1 as it's own additional OpenVPN server and add a client from Br02 to Br01.

I'm not sure where I'm supposed to look for my ip route.

However, it's finally working! I reset all "Firewall: NAT: Outbound" rules then copied two from the WAN rules creating them for VPN. That solved it!

Thanks for the help!

Continuing my monologue…
A bit more of experiment reveals that if DHCP relay is enabled then OS X DHCP client works with internal DHCP server, too.
But I have a DHCP server running on DMZ interface and I cannot run DHCP relay.
I will continue this topic in DHCP/DNS forum as it seems more appropriate.

You may also want to note that HMA doesn't really HYourA.  ;)

https://www.reddit.com/r/torrents/comments/1lpey9/just_learned_why_hide_my_ass_is_such_an_awful/

Try these guys https://cryptostorm.is/

Free connections limited to 1Mb/s down and 500kb/s up.

After performing a series of packet captures and CLI debugs, it turns out the phone system is actually sending the RTP traffic to the local IP instead of the VPN allocated IP - no problem with pfsense at all. Thanks again for your help, at least I know my setup is working fine.

The outbound rules should be working ;) I checked the automatic rules aswell.

Selection_070.png
Selection_070.png_thumb

wow, thats exactly what I was looking for!
thank you a lot!! :-) :-)

I like this method:

https://forum.pfsense.org/index.php?topic=84463.msg463226#msg463226

It is working! if somebody has this problem just add the google DNS or your internet provider DNS and its working!Thanks for the help ! ;D

What was set as the tunnel network in the OpenVPN server and the clients?  This stuff kinda just works.

Are you sure you need mesh?  Hub-spoke is a lot easier to maintain.

normally you should be able to use the export utility every time, and it should add a seperate "menu' for each openvpn connection (when you rightclick the icon in the tray).

the only reason i know that this fails is:
–> your pfsense systems all have the same hostname+domain. (system->general setup)

so if thats the case, make them different/unique from eachother and reboot the boxes. then try the client export utility again.

Just set up different clients.  They will all get a /30 out of your tunnel network.

Sorry, but I am not going to rehash all the OpenVPN documentation again here.  doc.pfsense.org.

@eekay:

@viragomann:

I think your LAN hosts don't know the way to your VPN client and send their packets to the default gateway.
You should add a NAT rule to the VPN server, translating the source IP of packet from VPN clients to the servers LAN IP when they are going to LAN network.

Thanks for the reply. On the firewall/gateway, I currently have an additional gateway setup (vpn server) and also a static route that points all VPN network traffic to the VPN server. Is this not the correct way to do it? Should I remove these and use NAT instead? If so, what would the proper way to add an NAT rule to translate the source be?

No. You need a NAT rule on your VPN server for fixing that, not on pfSense. A VPN server is also a router on the other side and should be able to do NAT.
The NAT rule must translate the whole traffic coming from VPN clients to the servers LAN IP (172.28.35.22). This way response packets from other hosts are addressed to 172.28.35.22 and enter the VPN server where they are translated to client IPs.