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!

@Derelict:

Note my first post on this thread.

Thank you, I dont know how I missed that all the when ever I checked, that rule should of cause have a limited source address range, adding that it works perfect

, thank you again

Im getting this error message when Im trying to install 1.5 liveCD.

Any ideas why Im getting this error message?

Im using a download from http://files.nyi.pfsense.org/mirror/downloads/

IMG_0330.JPG
IMG_0330.JPG_thumb

No. Wipe your browser cache. Frankly, not even clear what are you doing where. There are no buttons. Use the links in the export column.

Thanks for all the help.  I'll diagnose again in a bit.  Had an issue last night where my pfsense box froze and lost a few settings so i will have to go back in and fix everything up again.

Should have configured autobackup…

Perfect thank you, not sure why that didn't come up when I did a search for PIA.

Hi Jimp:

I have two FW-7551 devices set up, with an Ethernet cable directly connecting the WAN ports. They came pre-loaded with PFSense 2.2 and AES-NI is enabled in the BIOS on both devices. AES hardware support is also enabled in the System>Advanced>Miscellaneous section.

I successfully built an OpenVPN tunnel through the devices using AES-128-CBC, SHA1 and the BSD Cryptodev engine. Oddly, the maximum transfer rate I can achieve with an encrypted tunnel is 100 Mb/s. The AES-NI support makes no difference in throughput. If I turn encryption off, the rate increases to 200 Mb/s.

I changed many parameters in the Open VPN setup and turned AES-NI support in PFSense on and off, but the peak transfer rate stayed at 100 Mb/s. I do not have any explicit traffic shaping defined.

I used two Windows laptops (one at each end of the tunnel) to exercise the link. When the computers were connected directly to the Ethernet switch, I saw transfer rates approaching wire speed (800-850 Mb/s). When connected via the tunnel, the rate was the previously mentioned 100 Mb/s.

At this point I'm a little mystified, since I would have expected the transfer rate to be a little higher, especially with encryption turned off.

Cheers,
Ed

@doktornotor:

@phil.davis:

If you use pre-shared key (PSK) then you can only have 1 client for 1 server and they authenticate by having a matching PSK. In that mode there is no way to tell the difference between multiple clients.

One more reason to avoid PSK configs. ;)

Ok, now I remember why… I followed a s2s guide that was using PSK... In my case it would have been better to use SSL/TLS and manage all with certs on one server ... next time will do better :)

thanks anyone for the feedback (learnt something more today) now I have a much clearer view on the pfsense OpenVPN settings

There are some bright people hanging around here, but with this little info expect no miracle answer.

Anything else? How about the usual… (draw your setup. Some info on the vpn setup could help also)

after reading your post a couple of time, I make these assumptions:

pfSense is your VPN head-end. Synology will be the client, which needs to connect.

Did you:

open a port to allow the vnp client connection in? configure the Synoloy vpn client correctly? post or attach server & client config check FW logs in pfSense? There is a separate tab for OpenVPN check Synology log? What error do you see when it attempts to connect?

You may export certificates using the certificate manager in System menu and import them on the other box at same way.

For future readers, when some devices are reachable on a remote subnet across VPN but others are not, the common problems are:

The target device has its own Firewall. Often that firewall might allow access by another device directly on the subnet, but not from a remote subnet. Prime offender - Windows ****. Turn off firewall.

The target device does not have a (correct) gateway set. In that case it can answer directly on its LAN but not to anything off the LAN.

The target device has the wrong subnet mask - causing it to think the wrong range of IP addresses are local, or to not be able to reach the gateway or…

The target device is a really stupid print server or whatever that has nowhere in the firmware to even enter a gateway IP. First choice - ditch it. Second choice - NAT out onto that remote LAN so the traffic from the subnet/s on the other end of the tunnel looks like it comes from the local pfSense LAN IP.