This is a simple User access VPN, not a site to site Internal IP's are 192.168.10.X PFSense is 192.168.10.254 Cisco is 192.168.10.1 PFSense gives out 172.30.30.X addresses to VPN I can access 192.168.10.254 via VPN when connected. My IP address is 172.30.30.2 when connected. Now that the office is 'waking up' I do get some DHCP addresses; the two internal printers are both PING able, but I cannot print to them. Says it's offline. Although the Redirect Gateway option is specified, "Force all client generated traffic through the tunnel" when I connect I don't see it: Connection-specific DNS Suffix  . : corp.com Link-local IPv6 Address . . . . . : stuff IPv4 Address. . . . . . . . . . . : 172.30.30.2 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : I can trace a route to a printer, for example, but not connect: Tracing route to HPOJ8600.corp.com [192.168.10.100] over a maximum of 30 hops: 1    22 ms    19 ms    24 ms  172.30.30.1   2    28 ms    *      21 ms  HPOJ8600.corp.com [192.168.10.100] Which makes me think I'm missing some allow rules, but the wizard added the following rule: 3/10 KiB IPv4 *  *  *  *  *  *  none    OpenVPN Remote user access wizard Do I need to add allow rules from 172.30.30.x to 192.168.10.x and vice versa? == John ==

bump for the night crew

Ah, got it, thanks..

I get the same error when pfsense boots up from snapshot upgrade. Every time I upgrade I have to wait for it to boot, then reboot again and then it`s fine.

Thanks, that's exactly what I was looking for! Before I thought that 'description' is a usual 'comment' attribute which is visible only when editing ovpn profile

Hi Marvosa, Here's the config: dev ovpns2 verb 1 dev-type tun tun-ipv6 dev-node /dev/tun2 writepid /var/run/openvpn_server2.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto tcp-server cipher AES-256-CBC auth SHA1 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown client-connect /usr/local/sbin/openvpn.attributes.sh client-disconnect /usr/local/sbin/openvpn.attributes.sh local xx.xx.xx.xx tls-server server 192.168.89.0 255.255.255.0 client-config-dir /var/etc/openvpn-csc/server2 username-as-common-name auth-user-pass-verify "/usr/local/sbin/ovpn_auth_verify user 'Local Database' false server2" via-env tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'router.domain.local' 1" lport 443 management /var/etc/openvpn/server2.sock unix max-clients 1 push "route 192.168.88.0 255.255.255.0" push "dhcp-option DOMAIN domain.local" push "dhcp-option DNS 192.168.88.3" push "dhcp-option DNS 8.8.8.8" ca /var/etc/openvpn/server2.ca cert /var/etc/openvpn/server2.cert key /var/etc/openvpn/server2.key dh /etc/dh-parameters.2048 tls-auth /var/etc/openvpn/server2.tls-auth 0 persist-remote-ip float topology subnet push "route 192.168.88.0 255.255.255.0" mute 10 comp-lzo

Hey, have you found a solution to your problem? Cause i have exactly the same trying to connect to VPN Service provider (nordvpn). thanks. kind regards,

You haven't described what connects to what in this setup. Is a Linux server acting as an OpenVPN server and other boxes connect as clients? Any Windows clients? How many boxes/connections are we talking about? Is it a full mesh setup? Have you designated a single server or other system as the "Keeper of the Certificates"? In general it shouldn't be too tough to migrate over to pfSense fairly seamlessly. Should be a matter of importing the required CA and (possibly a new) Cert for the pfSense OpenVPN server. Then it's a matter of copying in the settings from the existing config into a new OpenVPN server instance under pfSense. Personally, for one server, I would hand enter the settings from the old OpenVPN server's config into the pfSense GUI. Better error checking and less chance of something "odd" happening.

@dotdash: Try deleting the gateway under system, routing. Also check if it is assigned as an interface (interfaces, assign) Aaaand: it's gone. I just hit you with da karma stick, thank you  :-*

i think this boils down to the way OpenVPN is implemented in tomato. if i use a client from behind the tomato, i'm able to connect. if i use the same parameters, it connects but no traffic flows thro. ::) :o :o >:(

Theres one extra line in the vpn config with the problem = lport 0

@mark1210: unable to ping the server. The OpenVPN server? From where? Have you added proper firewall rules to the OpenVPN rule tab?

@PGalati: I was able to solve this scenario and soon hope to create a how-to to help others that specifically use pfsense and Tomato.  This link pushed me in the right direction: https://doc.pfsense.org/index.php/Why_won't_OpenVPN_push_routes Click on this link to get some additional info about the correct way to configure the openvpn server on pfsense: https://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_PKI_%28SSL%29 To the point, once I changed the pfsense openvpn server mode from Remote Access (SSL+User Auth) to Peer to Peer (SSL/TLS), made the appropriate adjustments on the Tomato side, I started getting ping responses from clients from the server side.  Our Cisco voip phones work both ways now too. Finally! Hi , i'm trying to do the same thing. can you please tell me what your tomato side config is? have you enabled TLS Authentication? did you enable Extra HMAC authorization (tls-auth)? i'm getting TLS Error: incoming packet authentication failed from [AF_INET]

If the interface you are pinging on the server isn't its primary interface, ensure the server has a valid route for return traffic on the interface that you are pinging. Examin "route print" on the server to see where traffic from your OpenVPN subnet will end up.

So, configure an implicit deny firewall rule and only allow what you want.

With Derelict on this - I can see zero reasons why your vpn used by your clients would need to use public CA certs..  The only time public certs need to be used is when you would have uses accessing it that need to trust the CA that you do not control their devices used to access and can not add your CA to their trust list.

HINT: Don't forget to reload / restart your OpenVPN server, after chancing CCD / User specific config.