@Chrisiesmit93: so user 1 gets 192.168.3.2 and user 2 gets 192.168.3.2, and so on. Well that would not be good if you gave the users the same IP. In your openvpn setup check the Allocate only one IP per client (topology subnet), rather than an isolated subnet per client (topology net30).   Relevant when supplying a virtual adapter IP address to clients when using tun mode on IPv4. Some clients may require this even for IPv6, such as OpenVPN Connect (iOS/Android). Others may break if it is present, such as older versions of OpenVPN or clients such as Yealink phones. By default clients get IP in a /30 of the subnet you assigned to clients.  In my case 10.0.8.0/24, so they get /30 of that example Ethernet adapter vpn: Connection-specific DNS Suffix  . : local.lan   Description . . . . . . . . . . . : TAP-Windows Adapter V9   Physical Address. . . . . . . . . : 00-FF-5A-2F-7E-EA   DHCP Enabled. . . . . . . . . . . : Yes   Autoconfiguration Enabled . . . . : Yes   IPv4 Address. . . . . . . . . . . : 10.0.8.6(Preferred)   Subnet Mask . . . . . . . . . . . : 255.255.255.252   Lease Obtained. . . . . . . . . . : Friday, February 20, 2015 7:45:05 AM   Lease Expires . . . . . . . . . . : Saturday, February 20, 2016 7:45:05 AM   Default Gateway . . . . . . . . . :   DHCP Server . . . . . . . . . . . : 10.0.8.5   DNS Servers . . . . . . . . . . . : 192.168.1.253   NetBIOS over Tcpip. . . . . . . . : Enabled

The packet is probably getting to the remote sites. But they will need to know how to answer/route back to 172.16.1.0/24 and there will need to be firewall rules in the appropriate places to pass 172.16.1.0/24

OK I managed to get it working by checking the "Force all client generated traffic through the tunnel." option.

@phil.davis: @tsolrm: Once unchecked it opens up 'IPv4 Local Network/s' Do I put the details of my LAN here? And this way only LAN traffic goes through vpn? Yes, you need to tell it the subnet(s) that you want to be reached across the OpenVPN - your LAN(s) Thank you for your help. Everything seems to be working

I followed this tutorial, and it has worked for me… http://hardforum.com/showthread.php?t=1663797 Tks

Yes, it should be easy to change LAN subnet: a) Change pfSense LAN IP b) Change pfSense LAN DHCP range c) Change OpenVPN server Local Network/s list - that cannot have things like LANnet specified, so it has a redundant 192.168.1.0/24 in it  :( d) Check your aliases in case you have any that included specific addresses in 192.168.1.0/24 and fix as needed e) Check your firewall rules for any specific uses of addresses in 192.168.1.0/24 (hopefully your rules all use aliases and/or the pre-defined LANnet and LANaddress - which will apply automagically) f) Diagnostics->Edit File, /cf/conf/config.xml, search for "192.168.1" and see what other stuff is left behind g) Change anything on LAN that has a static IP set (file server, print server, WiFi AP management interface…) h) Get all LAN clients to renew DHCP

I have multiple times with no success.

It is normal - whatever address you NAT the site A subnet to, that needs to be an address that site C knows how to route back to. So you probably might want it to be some address in site B, which site C already knows how to reach.

Post a physical network map with IP's.  Post your openvpn config (server1.conf).

Post your server1.conf. Looking at what you've posted so far, it appears the tunnel is routing and allowing traffic as expected.  I'm betting your packets are making it to their destination, but getting blocked at the endpoint.  A couple things: Verify the device you are trying to ping is using PFsense as the default gateway Assuming you're trying to connect to a windows machine, remember the Windows Firewall blocks ICMP echo requests by default unless the traffic is sourced from the firewall's local subnet.  On Win 7/8 you have to either disable the windows firewall or add an explicit rule allowing ICMP echo from all IP's.  e.g. -> http://www.sysprobs.com/enable-ping-reply-windows-7 On Server 2008/2012, you can enable this inbound rule -> "File and Printer Sharing (Echo Request - ICMPv4-In)"

@deltix: I just had the same problem There are at least 2 if not 3 completely different and unrelated problems described by others in this thread. At least one where Snort was blocking the VPN, at least one other that's probably from delayed DNS resolution and the client getting started multiple times (which is fixed in 2.2), and probably different unrelated ones for others. Please start a new thread with specifics on what you're seeing happen, and what OpenVPN logs you're getting at the time.

@kejianshi: Which version of pfsense? 2.2. I might have found the problem but don't know how to solve it cleanly. The problem is that the OpenVPN server lets the peer connect with the new IP address but changes to WAIT state (echo 'states' | nc -U /var/etc/openvpn/server1.sock shows it). I looked at the OpenVPN management interface documentation and the WAIT state should only happen in the client. To solve the problem for now I put 'keepalive 1 10' in both and this will restart the server 10 secs after the client stops responding. I've did some tests and after the PPPoE connection reset the client takes 15 secs before initiating a new connection to the OpenVPN server and, by then, the server already expired the connection. A peer-to-peer OpenVPN tunnel should only allow one peer IP address and not more. Anything wrong in my theory? Thanks!

haha - Don't mention it.  Anything for you buddy (-; (No seriously - Don't mention it…  To anyone)

Yes!  That works!  Thank You! :)  Im not sure if that entry got deleted somehow or what happened because I know at some point or another it did work just fine! Sweet!

Does the 10.0.6.0 site to site network need to be pushed to the client? No, the road warrior clients do not need to know about site-to-site tunnels, there is nothing in the tunnel that they need to reach specifically. I would tell the road warrior clients about the whole of 10.255.10.0/24 rather than tell them each individual IP with a /32. Do not use the advanced box any more to push routes, just put 192.168.0.0/24,10.255.10.0/24 in the IPv4 Local Network/s box in the road warrior server GUI settings page. Make sure the OpenVPN Firewall Rules tabs at either end are allowing traffic arriving from all the subnets at the other end. traceroute is your friend - you can quickly traceroute from a client to a server and see what hops the packet took, and where it stops. That will give you a clue if there is a routing issue or firewall block somewhere along the path.

I got this working in the end. I had to change the zone files to look at the new ACL as well as the View. I figured I was doing something daft. Thanks for pointing me in the right direction.

OK. I finaly made this work. My client config look like this: dev tun persist-tun persist-key cipher AES-256-CBC auth SHA1 tls-client client resolv-retry infinite remote openvpn-server.org 443 tcp-client http-proxy proxy-dns-or-ip.org 8080 proxy-uyser-and-pass.txt basic lport 0 verify-x509-name "pfSenseOpenVPN" name auth-user-pass pkcs12 mirceass-TCP-443-SSL_VPN.p12 tls-auth mirceass-TCP-443-SSL_VPN-tls.key 1 ns-cert-type server comp-lzo And "proxy-uyser-and-pass.txt" is in the C:\Program Files\OpenVPN\Config. On the first line is username, and on seccond line is password, for proxy Now it's working and I'm pretty happy. Thanks all and have a good day!