Yes I do. All/All Pass. Its definitely odd behavior… I have rules on OpenVPN, and All/All pass on each OpenVPN interface, assigned and set. And the block would show as coming from that interface. See, TCP SYN packets get through.. its something to do with state keeping. I am not a pf savvy guy (I know the basics, but analyzing the blocks is a bit beyond me at the moment)

Tried that it though I didn't wait that long enough. I ll just tried again if that works. Thanks

Post your tunnel settings and the firewall rules on your openvpn tab.

This line looks like a problem: 10.0.0.0        255.0.0.0        On-link          10.0.0.9    266 Your 10.0.0.9 interface (on your server, if I understood the descriptions correctly) is thinking that it is sitting on a 10.0.0.0/8 network. So when it replies to any 10.n.n.n addresses, it will think it can reach them directly on its local LAN. It should be in the 10.0.0.0/24 network. Then it will send packets for 10.0.10.0/24 network addresses to the router.

Did I put the wrong files??  ???

i dont see a reason to use any kind of nat. as i understand currently the 10.10.88.0/24 is routed over the vpn and can contact clients on 192.168.78.0/24. if it were me i'd just add routes on both ends for the openvpn subnet (10.0.34.0/24), that way vpn users can go over the tunnel to reach the devices behind ASA5505.

What were you entering into all of the fields for the CA? As it says there, one of the strings was too long. Not sure which one it was complaining about though, if we can find out and repeat it, the input validation can be fixed to print a nicer error.

It is now working again  ;D The problem was that one of the routes did not survive the reboot.

I can make one for you also - just send an e-mail to wikiadmin (a) pfsense (d) org and it'll go to anyone who can make it for you. We'll need the username, password, e-mail, and name you want on the account.

Look at the server configuration [image: 476896openvpnconfig.jpg]

Im still new to most network related issues, so maybe I'm using the wrong terminology when I search for how to set this up. But I have read every tutorial I could find with Google, I have read every tutorial I could find here on the forums, and I cannot find how to set-up this VPN connection. Can anybody at least point me in the right direction?

I use a P2P Shared Key tunnel… Not sure if this will help you but here is an example of my DD-WRT config.. And nothing is NAT from what I can tell. Straight routing..  pfsense site is 192.168.0.x, the other site is 192.168.50.x... 172.16.50.x is the tunnel. Startup commands # Config for Site-to-Site SiteA-SiteB echo " remote pfsense IP/Host proto udp          port 1195 dev tun0 persist-tun persist-key resolv-retry infinite secret /tmp/static.key nobind mute-replay-warnings verb 3 comp-lzo keepalive 15 60 daemon " > SiteA-SiteB.conf # Config for Static Key echo " -----BEGIN OpenVPN Static key V1----- -----END OpenVPN Static key V1----- " > static.key # Create interfaces /tmp/myvpn --mktun --dev tun0 ifconfig tun0 172.16.50.2 netmask 255.255.255.0 promisc up # Create routes route add -net 192.168.0.0 netmask 255.255.255.0 gw 172.16.50.1 route add -net 192.168.1.0 netmask 255.255.255.0 gw 172.16.50.1 route add -net 192.168.60.0 netmask 255.255.255.0 gw 172.16.50.1 route add -net 192.168.100.0 netmask 255.255.255.0 gw 172.16.50.1 route add -net 192.168.200.0 netmask 255.255.255.0 gw 172.16.50.1 # Initiate the tunnel sleep 5 /tmp/myvpn --config SiteA-SiteB.conf firewall commands, I need to tweaks these but they work… just can't ping the dd-wrt router but i can telnet/web into it # private subnets (anything FROM these subnets) iptables -A ALL_ACCEPT -s 192.168.0.0/16 -j ACCEPT iptables -A ALL_ACCEPT -s 172.16.50.0/24 -j ACCEPT iptables -A ALL_ACCEPT -s 172.16.60.0/24 -j ACCEPT # Open firewall holes iptables -I INPUT 2 -p udp --dport 1195 -j ACCEPT iptables -I FORWARD -i br0 -o tun0 -j ACCEPT iptables -I FORWARD -i tun0 -o br0 -j ACCEPT

I ended up reinstalling pfSense on the client side and testing with all packet filtering disabled, everything then started working as expected.

The server log would probably be more telling than the client's log. That sounds like what happens when multiple clients are sharing a cert, one connects and knocks off another, then that one reconnects and knocks off the previous, over and over.

The latter requires a specific certificate for each user, and the former doesn't.