Wow, that compression option was the problem. I checked the box on the pfSense interface and now its working.  I had kinda seen that in the logs, but since it was a WARNING I really didn't give it much attention.  I'm used to seeing all kinds of warnings in my open source product logs that should usually just be ignored.

Thanks for the help!

Hello, do you mind sharing more details of the setup you used that made it work for you?

Thanks

Screenshot of WAN rule and OpenVPN log (I think for the ovpn client config above).  I hope this may give some more clues.

rgds Tor

Rule.JPG
Rule.JPG_thumb
Syslog.JPG
Syslog.JPG_thumb

I still dont know if this is a PKI or PSK setup.
For a PSK setup you just can create multiple keys and sav them.

For a PKI i'm not sure… you would have to create multiple CA's and safe them in different locations.
Read up on http://openVPN.net how to do that.

Solved.

I was adding routes to server side not the client.  Once route added to client side pfsense OpenVPN client it started to work as expected.

Thanks GruensFroeschli for your help

–Seth

I've tried this and it didn't work. I'll try to change an ip address from an unused device to the 'working' range to make sure I have the same effect.

Edit :
I've changed the ip from 10.1.101.200 to 10.1.0.200 and then it worked.

I want my client public IP appeared to be my server IP. I installed and set up OpenVpn (all my client traffic is now forced through the tunnel to the server where is NATed) - all works sweet except the one test here: http://www.proxyserverprivacy.com/adv-free-proxy-detector.shtml which detects me using proxy.  All other tests I found (i.e. here: http://whatismyipaddress.com/staticpages/index.php/advanced-proxy-test for example) I passed undetected. Do you have any idea what could the test at proxyserverprivacy can test on?

Pushes only work for PKI's where the connecting clients recieve their configuration from the server.

In a site-to-site setup the whole config comes from the local config-file.

Could you desribe this a bit more?
Because as i wrote before: there is no firewall for OpenVPN.

Fixed this with a custom ifconfig option :)

@GruensFroeschli:

As many as you want, limited by the bandwidth and CPU power you have.

sound nice and interesting ::)

thanx gurens !!!

Ahh yes, I'm sorry.

I'm trying to obtain more information about the setup and what's been done so far. I appologize as this is not my network and I am merely relaying what I have.

Ok, it doesnt seem to have anything to do with the default gw.

I changed several things and I cant really tell what the solution was, but now it works.

my systemtime was wrong for some reason it didnt work with wlan (ubuntu client) in the option field i put local xxx.xxx.xxx.xxx (static ip) to force ovpn to listen on the static ip i had to start ovpn with sudo on the commandline because with normal user rights the tun device couldnt be configured

Maybe this helps somebody.

e.

Thanks Kev, try using the older release openvpn-2.1_rc7 with your same configuration and see if you successfully complete initialization.  Its at the bottom of the following link:

http://openvpn.net/release/

Or even openvpn-2.1_rc8 from this link if you use Windows:

https://secure.openvpn.net/beta/openvpn-2.1_rc8-install.exe

Those 2 versions still work for me while rc9 does not.

The hifn chips are supported on pfSense, and work well for IPSec. Search for vpn1411 for some more info. I'm not that familiar with OpenVPN, so I'm not sure if it uses the hardware crypto. BTW, you should have posted in the openvpn forum, not the IPSec forum…

@chpalmer:

I copied from my(release) config file and pasted to the config file for the snapshot.  That may have not been a good idea so Im going to start over later when I get some time.

Probably not a good idea!  I don't know what might have changed but you never know.  I's suggest that you create it from scratch on teh new GUI.  If you really wanted to you could compare the .xml files to see any changes …

Cheers
Jon

Thanks for reply, GruensFroeschli

@GruensFroeschli:

1: I suppose it's possible. If one of the connections goes down your other balancer will put the attempt to reestablish the connection just on the second link.

2: I'm not sure what you're trying to ask.
Do you mean if it's better to let theRV042 do the loadbalancing or pfSense?
If you want failover for OpenVPN i think it's better to let the RV042 do the loadbalancing the job.
I dont think you can create failover-pools for pfSense itself, since pfSense uses outbound only its WAN for services running on it.

I need site-to-site OpenVPN Loadbanace not fail over. :)
[pfSense Box]-WAN-192.168.1.2< –--->192.168.1.1-LAN- [RV042 Loadbalance Router]-WAN1-[IP by ISP]–---Modem1--->
[ OpenVPN  ]                                                              [                                  ]-WAN2-[IP by ISP]–---Modem2--->

Sompong

You don't say what OS you are using on your laptop.

I would suggest that you run a local DNS server on your laptop.  Configure it to forward to your work DNS for their internal domains and at your home system for its domains.  Then point it at what ever can get out of the door for everything else (can be both).  Finally, point your laptop at its own DNS server on 127.0.0.1.

Cheers
Jon

@razor2000:

When running OpenVPN on your OPT1/OPT2 lines, be sure to use TCP instead of the default UDP for your port.  pfSense has issues when trying to connect to any port that runs on the UDP protocol when not using the WAN interface.

Give it a try and good luck! :)

You sir a genius!  I think I saw that posted somewhere but must have ignored it.

OpenVPN received wisdom is that TCP over TCP is a bad idea, something to do with a double exponential stand off which can cause serious performance snags.  Funnily enough I've been running it like that for years prior to putting in pfSense but thought I'd do the right thing this time - oh well!

I have (briefly) tested all three of my external connections to my office LAN via this and they work very well.  I'm nearly ready to bin the many IPSEC tunnels which are a constant pain - regularly dropping and not recovering, unlike OVPN which has always struck me as far more robust.