"TLS Error" sounds difficult but it's easy: Just take the TLS string from your server, put it into a textfile on your openvpn client.

2048 bit OpenVPN static key

…

I have a slightly different question, but I think it is related to this.

I want to bind together at least 2 (up to 5 or 6 if possible) entirely different connections (same ISP; two ISP accounts; two modems) and load balance. I'm trying to improve my bandwidth (avoid caps and maximize overall throughput) to the VPN service I use. Here's the question: Is it possible to load balance a single session of OpenVPN over two (or more) different connections? It gets slightly trickier, I need to run pfSense virtualized on Win7. I'm thinking of something like http://bora.bilg.in/blog/04/multi-wan-load-balancing-under-windows-with-pfsense, with a single session of OpenVPN load balanced. If it did work, it would go something like this:

Win7 with OpenVPN Client <–> Virtual PfSense with Load balancing <--> Connections 1, 2,...,n <--> VPN Server <--> Internet

Please note that I only have one VPN tunnel I want to make, I just want to expand the number of physical lines I can use to reach the server.

Is that even possible? Does the Server need to be setup in a special way? Should PfSense be running the OpenVPN client instead of Win7? If this is possible, are there any particular methods I need to use? What are they?

Update!  :)

Problem solved using the OpenVPN Access Server. I purchased user licenses and downloaded the VMware OVPN appliance. I then converted and imported the appliance into my Citrix XenServer and configured the OpenVPN Access Server. Now remote users can access both of my offices over a single VPN connection using OpenVPN and IPSec. I'm currently running both servers side-by-side until I replace my user clients with the ovpn client generated by the Access Server. The pfSense server is using UDP 1194 and the OVPN AS server is using UDP 1195. I can now route traffic between the various subnets in my network over the VPN.

Using my Windows Server 2008's Network Policy Server (RADIUS), remote VPN users use their Active Directory credentials to authenticate with OpenVPN. In addition, all VPN users belong to a special Windows Security Group and only members of that group are allowed to access the OpenVPN AS. My site-to-site tunnel using IPSec remains unchanged and I have removed the OpenVPN site-to-site configurations from my pfSense boxes. I have also shutdown the 2nd OpenVPN server located in my satellite office which was used to access the remote network located there. I had been at this for 3 months and I simply never could get the site-to-site tunnel using OpenVPN to work on pfSense so I am most pleased with the outcome.

ISSUES RESOLVED!

For some reason, there was a static route set to 192.168.0.1 for the 10.0.10.x subnet.  I have no idea who set this up, but the route had zero traffic on it.  I'm guessing one of the other admins (gone now) who was responsible for this location had made the change and not documented it.

Thanks for the help.  I was about to go out of my mind.

Yesterday it was confirmed on the OpenVPN mailing list that OpenVPN isn't vulnerable.

Hi torontob,

Please, when you get a chance post what you did on the outbound NAT/static port to get this working. I've been having the same issue and it's driving me insane!! The tunnel simply won't work over UDP.

After analyzing my packet captures I realized my error:  the routes that I was trying to set up in the router obviously can't work because I am requesting a 10.10.11.x resource through pfSense that has an origination address of 192.168.100.x.

The correct route I needed was:
ip route 192.168.100.0 255.255.255.0 192.168.1.203

All fixed Neil from 12vpn helped me out :

"The important thing is not to put the rule on the WAN interface, but on the OpenVPN interface instead.

If the VPN client is connected when you go to the NAT->Outbound rules you'll have the option to select WAN, LAN and OpenVPN."

BTW, source and destination can both be "any". As long as the interface is set to OpenVPN and the translation address is set to "Interface address".

I knew it was one line and I knew it was going to slap me when I figured it out.

On GW1 (Cisco router) all I needed to do put a route that forwarded all 192.168.6.0/24 back to 192.168.3.1

or

ip route 192.168.6.0 255.255.255.0 192.168.3.1

;D

Yes, just do a manual update to the same version you have.

You might also want to install smartmontools and run a hard drive test (See http://forum.pfsense.org/index.php/topic,26626.0.html for how to install/run a test) and see if any of the S.M.A.R.T. indicators point toward a hardware failure.

Thanks for the answer. That helps me a lot. I will go and recreate my local network.
It's a very good forum and keep it up.

Greetings l084

If you just want to view it, use "cat" not "vi".

And with cat, you can also do that from the GUI under Diagnostics > Command

What would the client.conf look like for using PKI on the OS?

Thanks

I changed the iroute to "iroute 192.168.0.0 255.255.255.0;" and did some testing with a linux based vmware host as client. With this client I connected successfully and could also ping in both directions!!

So the problem seems to be my home-router, which is an embedded version of 1.2.3… So I installed tcpdump and did some capturings. All I could see is that no packages are arriving at the tun interface's. So the problem seems to be the routing!

so if someone with more routing experience on pfsense could give me a hand?

Greetz
Mircsicz

P.S.: here's an output from tcpdump:

\ [mirco@macbook-pro-wlan.mirco.home ~] 4$ ping 192.168.115.2 PING 192.168.115.2 (192.168.115.2): 56 data bytes 36 bytes from wall.mirco.home (192.168.0.1): Redirect Host(New addr: 192.168.0.1) Vr HL TOS  Len  ID Flg  off TTL Pro  cks      Src      Dst 4  5  00 0054 6d9c  0 0000  40  01 1878 192.168.0.66  192.168.115.2 Request timeout for icmp_seq 0 36 bytes from wall.mirco.home (192.168.0.1): Redirect Host(New addr: 192.168.0.1) Vr HL TOS  Len  ID Flg  off TTL Pro  cks      Src      Dst 4  5  00 0054 4fd4  0 0000  40  01 3640 192.168.0.66  192.168.115.2 Request timeout for icmp_seq 1 ^C --- 192.168.115.2 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss [root@wall.mirco.home]/root(8): tcpdump -i sis0 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on sis0, link-type EN10MB (Ethernet), capture size 96 bytes 19:51:40.556932 IP macbook-pro-wlan.mirco.home > 192.168.115.2: ICMP echo request, id 30693, seq 0, length 64 19:51:40.557817 IP wall.mirco.home > macbook-pro-wlan.mirco.home: ICMP redirect 192.168.115.2 to host wall.mirco.home, length 36 19:51:41.555681 IP macbook-pro-wlan.mirco.home > 192.168.115.2: ICMP echo request, id 30693, seq 1, length 64 19:51:41.556078 IP wall.mirco.home > macbook-pro-wlan.mirco.home: ICMP redirect 192.168.115.2 to host wall.mirco.home, length 36 4 packets captured 50 packets received by filter 0 packets dropped by kernel

Any VPN will have an overhead.  I can't find any product called "Simple VPN" it's hard to say much more than PPTP and IPsec should have slightly lower overhead than anything using SSL.

Perhaps your current system shipped with driver integrity checking disabled. Google for it, there are ways to turn it off.

VPN would add overhead to VOIP calls, it wouldn't help call quality, it may hurt it.

The only advantage might be that it would look like a different protocol to your ISP's equipment and may be bypassing some QoS in places.

It depends on what kind of filtering is being done by your ISP, but they could detect and block VPN traffic if they have powerful enough equipment to run protocol analysis on every connection that passes through their network.

Our staff are able to access windows shares over a bridged (tun) openvpn connection just fine. I looked into a bridged network, but it seemed to be too much of a headache to make it work on pfsense.