Found the solution: Due to the Dual WAN solution.  all my LAN traffic  wanted to go true the  MULTIWAN  Gateway.    this means also OpenVPN traffic. Now that I made 1 rule on my LAN    that only traffic for port 80 needs to be balanced and go true the MULTIWAY Gateway  then 1 rule  lower pri  that lets all other traffic  true the * default gateway. NOW my OpenVPN works in both directions @pisang98: Site 1 (PFSense 1.2.3-RELEASE) Dual WAN (Fixed IP's) OpenVPN Server LAN 192.168.1.1 Site 2 (PFSense 2.0-BETA1) Dual WAN (Dyn IP's) OpenVPN Client LAN 192.168.0.250 When I had a PFSense 1.2.3 on site 2 my OpenVPN (Site2Site) worked without any problems. Now that I have upgraded to PFSense 2.0 (2x Dyn PPPoE)  I'm having troubles with my OpenVPN My 2XWAN on Site2 are balanced TIER1 and thats working. OpenVPN connects and is working.  Ping on the PFsense interfaces work to all ip's (Site1 & Site2) Connecting from site 1 -> site 2 is working.  (OpenVPN Server) Connecting from site 2 -> site 1 is NOT working. (OpenVPN Client) I need a OpenVPN Bridge <-> from all networks. I have a Firewall rule   *  *  *  *  *  *  none     OpenVPN  for the OpenVPN Traffic on Site2 I have something wrong on my new PFSense 2.0 (Site2) config.  Or I don't understand the new OpenVPN in 2.0 Please help.

Thanks, I had mess up the certificates! Now it works.

Yep, I was able to test it after my office closed today. Just popping the static route in when I need it works for me.

What do your firewall rules look like on LAN? What about the remote openvpn server? Does it have a route back to your LAN subnet? (either via route for shared key, or route/iroute for PKI)

With site-to-site PKI, the "remote network" doesn't really work like that. The Remote Network box is only for Shared Key. You need to do two things to get site-to-site PKI to route back to the client network: a) Add a "route 192.168.x.0 255.255.255.0;" line in custom options, one for each remote site. b) Add a Client-Specific Config entry for each site, using the site's common name of their certificate. In the custom options for this site, add "iroute 192.168.x.0 255.255.255.0;"

Server: local 192.168.10.18 port 1194 proto udp dev tun dev-node MyTap ca ca.crt cert key.crt key key.key dh dh1024.pem server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "route 192.168.10.0 255.255.255.0" push "route 192.168.0.0 255.255.255.0" client-config-dir ccd route 192.168.0.0 255.255.255.0 #iroute 192.168.0.0 255.255.255.0 push "192.168.10.1" push "dhcp-option DNS 10.8.0.1" push "dhcp-option WINS 10.8.0.1" tls-auth ta.key 0 comp-lzo max-clients 100 persist-key persist-tun verb 3 mute 20 Client: client dev tun dev-node MyTap proto udp remote 110.60.20.217 1194 resolv-retry infinite nobind persist-key persist-tun mute-replay-warnings ca ca.crt cert client1.crt key client1.key ns-cert-type server tls-auth ta.key 1 comp-lzo mute 20

Not sure about ubuntu clients, but on Win7 were you running the client as Administrator? When connected, go to a CMD prompt, and type "route print" and see if you have a route to your home network that has an IP in the OpenVPN address pool as its gateway.

The client doesn't need dh parameters. As for the other problem, on the road warrior server config, in the custom options, put: push route 192.168.2.0 255.255.255.0; And then on the site2 client for site-to-site, in the custom options, put: route 10.0.0.0 255.255.255.0; The first part should tell the clients that they can reach site2 via the OpenVPN connection. The second part will tell site2 how to route back to the OpenVPN road warrior subnet.

and the other part of my config [image: 4.jpg] [image: 4.jpg_thumb] [image: 5.jpg] [image: 5.jpg_thumb] [image: 6.jpg] [image: 6.jpg_thumb] [image: 7.jpg] [image: 7.jpg_thumb]

A few simple tests could confirm this behavior, but I'm not sure offhand. I haven't tried this myself, but you could require having a CSC entry, and use the directive ccd-exclusive; In the custom options to enforce the requirement that a client exists on the CSC tab before they can connect. The OpenVPN man page doesn't really clarify whether or not the ifconfig-push directives for the CSC entries are taken into account during general pool assignment.

Thx i think i got it now. I ve changed Address pool to 10.0.8.0/24 (on servers side) an on client side Interface IP: to 10.0.8.0/24 and now i can ping from hosts on A site to host on B site. Now I am going to play with DNS. Thx once again.

It's resolved. There were two different problems. One was with Tunnelblick. I switched to a different VPN client on the Mac (Viscosity) which worked right away. The problem with the Windows PC was that I was using a different VPN config, who's alias was mistakingly being blocked from DNS via a firewall rule.

This was solved on IRC, I believe. He switched to using a real PKI setup (not shared key/PSK), and adding route/iroute statements as needed, and it started to work.

Never mind, I figured it out. It is base64 encoded, just without line breaks. I just removed all the line breaks from my encoded string.

I'm not sure how it goes on Windows, but on unix, you have to run a different program first that sets variables that makes sure it's reading all of the proper files and such.