This is a known limitation, huh. https://doc.pfsense.org/index.php/Multi-WAN_2.0#Policy_Route_Negation I guess a reasonable practice would be to always define at least a management network in IPv4 Remote Networks on your client so you can get in and add other networks if you have to go Multi-WAN on the client side. Something like this also seems reasonable and seems to work.  (Screenshots aren't uploading): IPv4 * LAN net * RFC1918 * * none   Add private destinations to negate for VPN traffic IPv4 * LAN net * * * WANGROUP none   Default allow LAN to any rule

@kejianshi: Try this - Just list it in "IPV4 local networks" along with the other /24 you have listed there and remove your push command. I wonder what that would do? Sorry, would you mind to elaborate? Thanks! :)

Do you have two separate pfSense boxes or one installation with two WAN NICs or one pfSense and something else?  It's not clear from your explanation. Are these two firewalls actually independent of each other or does one get it's WAN from the other? Is the pfSense OpenVPN instance the client or the server? Perhaps a simple diagram would make it easier to understand. The only thing else I can guess from your description is you may have a description/config issue as you say So I can connect to the pfsense but cannot ping any devices on the 10.1.52.0/22 network. but you describe the pfSense LAN as: LAN: 10.1.53.5 (connected to the main network 10.1.53.0/22 ) No dhcp, Do you expect a ping from 10.1.52.x to reach 10.1.53.5? What do your route tables on the OpenVPN connected device look like? One last sanity check, are you sure the internal LAN device will respond to pings from an external subnet (Win firewalls off, AV disabled, etc.)?

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.