Thanks again divsys, you really saved me lot of time!

I just watched the recent gold hangout with jimp and this very topic was addressed.  I haven't done it and don't really understand it but there's a way to get reply-to working to put the return traffic back over the VPN and not out the default gateway.  The hangout is kind of a deep dive covering a lot so I'm not quite sure exactly what he's talking about…yet.

Got a report from a customer that these installers do work so long as you take "persist-tun" out of the client config.

So… it's not an OpenVPN vulnerability, but it's a potential vector for one. That's like saying Apache is vulnerable because it can be configured to run scripts that might happen to call bash... Still not a problem for us, none of our scripts would use bash. :D (Now if someone manually added bash and added their own scripts, perhaps, but that's not on us...)

What about bridge: server1+server2+lan?

My client setup file dev tap persist-tun persist-key cipher AES-128-CBC auth SHA1 tls-client client resolv-retry infinite remote 81.233.18.249 1194 udp route-gateway 192.168.1.253 lport 0 auth-user-pass ca srv-pfsense-udp-1194-ca.crt ns-cert-type server comp-lzo

1. In some articles pointed out the server mode needs to be "Remote Access(SSL/TLS)" when using multi-sites conection, I am going to setup another client sites later. But anyway, I will try to test in both way. 2. The rules are same on the OpenVPN tab on both ends. 3. Forgot to mention, I have been using a gateway groups as my openvpn client interface, include default gateway and 192.168.60.1 could both conect to internet. server1.conf –----------------- dev ovpns1 dev-type tun tun-ipv6 dev-node /dev/tun1 writepid /var/run/openvpn_server1.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp cipher AES-128-CBC up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 123.x.x.x tls-server server 192.254.0.0 255.255.255.192 client-config-dir /var/etc/openvpn-csc tls-verify /var/etc/openvpn/server1.tls-verify.php lport 1194 management /var/etc/openvpn/server1.sock unix max-clients 10 push "route 192.168.0.0 255.255.255.0" client-to-client ca /var/etc/openvpn/server1.ca cert /var/etc/openvpn/server1.cert key /var/etc/openvpn/server1.key dh /etc/dh-parameters.1024 tls-auth /var/etc/openvpn/server1.tls-auth 0 comp-lzo persist-remote-ip float route 192.168.1.0 255.255.255.0 client1.conf dev ovpnc1 dev-type tun tun-ipv6 dev-node /dev/tun1 writepid /var/run/openvpn_client1.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp cipher AES-128-CBC up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 192.168.60.2 tls-client client lport 0 management /var/etc/openvpn/client1.sock unix remote 123.x.x.x 1194 ca /var/etc/openvpn/client1.ca cert /var/etc/openvpn/client1.cert key /var/etc/openvpn/client1.key tls-auth /var/etc/openvpn/client1.tls-auth 1 comp-lzo 4. Packets captured on em3 interface: 14:11:55.909401 IP 192.168.60.2 > 192.168.0.6: ICMP echo request, id 50999, seq 16729, length 40 14:11:57.408812 IP 192.168.60.2 > 192.168.0.6: ICMP echo request, id 50999, seq 16985, length 40 14:11:58.884478 IP 192.168.60.2 > 192.168.0.6: ICMP echo request, id 50999, seq 17241, length 40 No icmp packets were captured on vpn interface.

A couple things: 1.  Without seeing the configs we can only speculate, but my best guess is the OpenVPN server on the remote end does not know how to reach the 10.100.6.x subnet, so return traffic is being dropped.  Most likely the remote end is missing a return route for the 10.100.6.x subnet. 2.  If I'm not mistaken, "iroute" is a server-side directive, so you can remove "iroute 10.100.6.0 255.255.255.0;" from your client config.

Post the server1.conf and client1.conf.

bump

Not at this time.

There is not one currently. It may be possible to add in the future, or one could be manually added into the /etc/inc/openvpn.auth-user.php above/below the success syslog message.

That option exists on 2.2 in the OpenVPN client settings. On 2.1.x, place your file in /root/ or /conf/ and it should carry over between updates.

That would be between OpenVPN and OpenSSL, not something we've done. The box prints the list of ciphers from OpenVPN and if it can't use one it states, it must be something between there and OpenSSL. You might post that same question to an OpenVPN board, see if anyone else has tried it. Or test it on a 2.2 snapshot.

@kejianshi: Try using a full mesh VPN like TINC at all 3 points and then everything with happily talk to everything else. IPSec also works. In small networks it isn't complicated to setup. With 3 sites, 3 tunnels give full mesh connectivity and no routing issues.

I think this is the setting you're looking for: Navigate to "System: Advanced: Miscellaneous" Then go to "Gateway Monitoring" and check "Skip rules when gateway is down"