Hi iorx,
The OpenVPN road warrior can go to all the LAN where it is connected to as well as all the Ipsec tunnels. Where I have a problem is that the OpenVPN road warrior cannot go to other OpenVPN site-to-sites…

Regards,

Carlos

I found the solution to my problem.

I went through a clean install, but there was no change in the issue of the OpenVPN client disconnecting.  I finally tried changing from UDP to TCP for OpenVPN.  This resolved the issue.  I believe it is due to poor line quality from my ISP and TCP dealing with the errors better.

I don't really want to see your asci art.. Post up your setting in your gui..

Where is the one that works… So your trying to use the same port on both of them??

lport 1194

If you guys could share your OpenVPN Client config screens, that would be great.  I've been configuring it and I'm being jerked around by an AUTH_FAILED error, when I know for a fact that the user/pass are correct because I can connect with those creds when using their app on Windows.

Edit:  Bizarre.  My creds work just fine when using the VyprVPN app.  When using their .ovpn file with OpenVPN, I can't authenticate with those same creds.  That explains why I couldn't connect via pfSense.  Time to see what's up with the VyprVPN folks.

Why are you bridging if the subnets are different?

You have given the two sides no way to reach each other. There is no tunnel network on the VPN for them to use as a gateway, and they have no subnets in common. Routing requires both sides to have an address in a common subnet. It can't push nor use routes because there is nowhere for them to go.

Usually in a bridge scenario the LANs are the same subnet.

From the look of your network layout, you don't need nor want a bridge. You could use tap but there is no advantage in this scenario. Remove the bridge components and follow this to setup the VPN using SSL/TLS like you have started: https://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_PKI_(SSL)

There is no way to accomplish what you're after. We get that request fairly often but we have not implemented it because we consider it to be a security problem. OpenVPN gives you multiple factors of authentication: TLS Key, User Certificate, plus Username and Password. Allowing someone who has obtained the username and password to easily obtain the other factors weakens the overall security of the VPN.

Use www.torproject.org

Aug 31 14:11:39  openvpn  50596  FreeBSD ifconfig failed: external program exited with error status: 1

That means the IP address it's trying to use for the tunnel network is already in use – either on another interface or it's in the routing table somehow (e.g. from quagga). Figure out what is conflicting and fix that, and your problem will go away. If it's quagga, disable redistribution and acceptance of 192.168.12.1/32 for example.

Yes, you can do this. But connections are only accepted by the master. After a failover to the other box, the client has to reconnect, but OpenVPN clients do these automatically.

The "dev tun" line is left out of the IOS/Android one because the OpenVPN connect app would choke on it. Not sure if it still does, though.

As to performance.. with tap your going to see all the broadcast traffic since your L2.. So all devices on both sides will be sending your broadcast traffic down your wan connection.  Which is normally a limited pipe that should be used to carry useful data not every client broadcasting for wpad, or all their UPnP data - all the noise that your typical device sends out.

Since it Layer 2 you will also have all the ethernet overhead on all traffic going over the tunnel..  Is that at a basic enough level for you to understand?

"I've found tons of people who have site to site VPN's via tap and are bridging their networks"

I don't doubt it - there are lots of people that just don't have clue one to what they are doing at all..  And don't even understand what they are working with and why it doesn't work.  They just know that hey if I use a tap it works… There are a lot of people in the world that have to think rabbit through the hole when they tie their shoes ;) hehehehe

"Several of the resources that are being accessed have software firewalls that are configured to only allow the main subnet (192.168.1.x)."

Well the proper way to solve that issue would be to adjust the firewalls to allow the traffic you want and desire.. Not just blindly trust traffic because its on the same natwork?  If you want to allow port xyz, then allow that from your other sites machines either by specific IP or by the remote network address space as source, etc.  Another way to work around that issue would be to nat your traffic over the tunnel so it looks like its from the same network ;)

So these devices are going to directly connect into your vpn server?  Or your going to do a site to site tunnel?  So lets go back to your "to only allow the main subnet (192.168.1.x)."  So these clients already have an IP on 192.168.1, and now you want them to connect to your vpn and also give them another 192.168.1.x address?  So when they want to talk to a machine on the local network, how do they know to send it down the tunnel or just out their local interface?  So you want to bridge these devices tap devices to the their local interface as well?  Did you do that?

Connecting a site to site with a tap/bridge setup to extend a vlan is much easier to accomplish then client to server with client on the same local IP as the VPN via tap, etc.

As to openvpn gui being buggy.. I would assume its more you have not gone through all the steps in configuration of a tap setup, etc.  Here is the thing while it can be done, normally it should not be done.  The only valid reasons to have to use a tap would be if you have some protocol your running that is not IP based and can not be routed..  Your reasoning is that there is some software firewall that what you can not adjust?  Who does??  Get them to do it if your going to setup a vpn from their machine to your network.

Did you get it working? I'm having the same issue: https://forum.pfsense.org/index.php?topic=117749.0

interface widget on the dashboard

smb/cifs over a high latency connection is going to blow no matter how you look at..  Your doing what 1 stream - do the math that is going to suck for performance.  Would never use that as method of moving files over long fat pipe.

I have a seedbox in Luxembourg, I use https to grab files from there to my box.  I use a web file manager called kloudspearker.  Max out my internet pipe here at 80mbps..  Or could just use sftp as another option but its normally not going to scream over high latency either but going to be way better than smb because its not as chatty.  Public key auth pretty freaking secure ;)  I don't lock down access but you have to auth to it..  There is nothing of personal nature on this box - if someone guessed username and password or used an exploit that would have access to what you normally put on a seedbox ;)

My seedbox ping is 108ms from me here..  So with default window size, 1 stream
a TCP window of 64 KByte and RTT of 108.0 ms <= 4.85 Mbit/sec.

Bump that window size up to 256 and your still only talking 20 Mbps.. You need more streams and large window size if you want to move files over a long fat pipe.  SMB is not the protocol to do that since its chatty as all get out.. Do a simple sniff of your file copy even local, look how many packets..  Now increase the time for each packet from your local 1ms to 100 plus ms and how long does that file copy take ;)

So depending what is on there - sure https with some sort of login works, sftp or scp very secure method of moving files going to be faster than smb that is for sure.  Comes down to what is on this vms that you would be worried about to how secure you need to make it.  Any sort of admin I wouldn't open up to just public internet via its gui.. Like the esxi host managment or pfsense web gui.  Make sure that is secure.  Locked to your IP would be fine - but make sure you have another secure method to get in that doesn't lock to your source IP.  What if that source IP changes ;)