It is a client from pfSense up to an internet-VPN service. Advanced box: remote-random auth-user-pass persist-key persist-tun tls-client comp-lzo verb 1 I have added link-mtu 1574;tun-mtu 1532; and restarted but I see the following in the log: openvpn[4644]: /usr/local/sbin/ovpn-linkup ovpnc2 1500 1542 10.12.0.22 10.12.0.21 init Thank you for your help

You should be able to just add an Outbound NAT rule on LAN, source "the VPN tunnel network", destination LAN net, NAT to LAN address. The traffic from your client device should have a source IP in VPN tunnel network, so will match that NAT rule, be translated to LAN address, go to the switch/es and the switches can answer.

It is a shame that Windows does not have a concept of adding a drive letter mapping for a share that is available system-wide ("net use /systemwide" command). It is happy to let an administrator define drive letters for the real partitions on the local disks, and those are seen by all users, so it couldn't be that difficult to allow the same for network shares.

hi, thx all for time. ok, i want only access internet from one pfsense box but also want two different ways how to connect from internet to LAN (two HW with openvpn server). I thing that i need some NAT rule and portforward rule. But from what you wrote, i thing that it is impossible..

@Derelict: The wizard is for Remote Access (Road warrior) setups.  Not site-to-site. Yep!  Figured that out now lol. Got it going with the standard setup for site to site using just shared key. Thanks guys - both sides ping!

firewalls on the lan-devices or gateway not correct on lan-devices?

I guess I'd suggest you get a set of working instructions for a bigger vpn provider that has very well tested instructions, like strongvpn, and apply thier instructions to pure VPN.  Substitute in purevpn credentials, IP etc.

TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Usually means that there was no response from the remote end, which often is because the remote end is not reachable. UDPv4 link remote: [AF_INET]10.0.2.15:1194 It is trying to reach a server that is in private IP address space. If this is a real link across the public internet, then you have got the setting of the remote address wrong.

Jim, I got it.  We dont have that many users so I think we will use the certificates. Thank you for taking the time. H.

@Derelict: It would be nice to be able to set defaults for client export in a particular vpn instance.  I understand this pretty much means incorporating client export into pfSense instead of it being a package, but it sure would be nice. I raised a feature on Redmine a while ago: https://redmine.pfsense.org/issues/3478 There is nothing to stop the OpenVPN Client Export package from being able to save some default settings. I thought about doing it but have not got around to it. I want 2.2 to happen more than I want this  ;)

Sorry just worked it out, i thought you needed to download openvpn but pfsense comes already with openvpn i just needed to download the package "openvpn client export" to download the clients for my different devices

@Derelict: System->User Manager->Servers Of course is located there. its the only place I didnt look  ;D Thank you..

You might have to create three different OpenVPN Servers, each with it's own defined LDAP server with different authentication containers for your groups. I don't think there's a way to pass group membership from LDAP into OpenVPN and change behavior, such as what traffic is allowed. With three OpenVPN servers and assigned interfaces it'd be pretty easy.

Try adding this to your OpenVPN server: reneg-sec 43200; I believe I also put reneg-sec 0; in my client export so I can change it at the server and affect everyone the same. I have reneg-sec 0; in my client specific overrides but I'm not sure it can be pushed like that. Exchanging login credentials again is part of the renegotiation.  My Duo starts firing after an hour if I don't do this.  12 hours seems to be long enough to get me through every session. This doesn't affect site-to-site since there's no manual 2-factor auth.

This did it for me : Marked this in the OpenVPN conf : Strict User /CN Matching : When authenticating users, enforce a match between common name of the client certificate and the username given at login.

I'm with jimp - the 2.2-BETA really has got out all the bugs I can think of in the parts I use. I also think that 2.2-RC will not need to live for long before an official release.

Happy to help. The addresses checked in rules are the real source and destination addresses of the packets arriving on the interface, which often (usually) are not in the interface subnet itself. This only gets "messed up" when there is NAT happening somewhere - if you are receiving packets that have been NATed somewhere by the sender then the source IP (destination when heading back to the NAT) will be whatever the NAT rewrote it to.