@johnpoz @Rico Everything is working now. Thanks. I want to do a few things like guarantee it's the VPN or nothing and some other items. Thanks for your help

Using Local Network(s) is the preferred method because pfSense has a way to know about the networks there in the configuration.

It is synonymous with the push route as has been said. Doing both should be harmless though will probably result in a logged error on the client side when the client tries to add the route to the routing table a second time. This can make people chase their tails for nothing.

Forget about it, I figured it out. I had to change the interface from WAN to LAN. I am too dumb.

@KOM said in OpenVPN Clients aren't always able to resolve DNS:

I don't think it matters but I have my OpenVPN instance tied to my WAN address. I have 14 VIP-IP aliases and could have used anyone of them for the VPN but I stuck with the default.

Mine's also tied to the WAN interface. I went ahead and removed the OPT1 assignment and I'm going to give it some time and have a few users test to see if it works now.

"Is it really necessary to update the device that protects my network from bad guys so that security bugs which have been found can be fixed?"

Ask yourself that again, and keep asking until the answer becomes clear.

If there is no packet loss at the gateway then it likely isn't a pfSense problem. What type of NIC are you using for WAN?

I'm with user @JKnott here -- do you hate your job there? Do you want to perhaps receive disciplanary action or even get terminated just so you can use a VPN on the company's network and on the company's time?

I don't know your specific company, but they have likely blocked VPNs for a reason and may not take kindly to attempts by you to circumvent the restriction. At the Fortune 500 US company where I worked what you are attempting on a first offense would at a minimum get you time off without pay to reflect upon your actions. And a second offense would get you an escorted trip to HR and then the parking lot -- permanently banned (as in terminated).

If you establish a VPN connection on a computer it has at least two network interface, the Ethernet or wireless and the virtual VPN interface.
Which interface is used for outgoing traffic is ruled by routes on the computer.

Now, the OpenVPN client is capable to add routes on the client computer and the OpenVPN server can tell the client, which routes are to be added (push routes).

In the server settings you have two options to push routes to the client:

If you check "Redirect gateway" the server pushes the default route to the client, which means that the client directs all upstream traffic to the VPN server. This way you can surf the internet via the OpenVPN servers internet connection and its public IP. If you don't check "Redirect gateway" you can enter the subnets which should be directed over the VPN into the "Local Network/s" box. So if your local LAN is 192.168.50.0/24 and you state this subnet at "Local Network/s" only the route for this subnet is added to the clients routing table. So if you access an IP within this subnet on the client it goes out over the VPN virtual interface, while other traffic is directed to its default gateway.

Thank you sir, that appears to have done the trick.

You already know what was happening, but I'd like to document it for the next guy. :)

Keywords: FreeIPA LDAP pfSense Authentication Server OpenVPN

Scenario: When using a LDAP server, either stand alone or as part of FreeIPA, and that LDAP server is using a "real cert" such as a Let's Encrypt cert, you should use the Global Root CA when defining the Authentication Server in pfSense. Then login to the pfSense system via ssh, issue a restart command for PHP-FM via option 16, followed by a Restart webConfigurator command via option 11 before testing via Diag->Auth or requesting a list of containers via the Select Containers button.

If you are custom a self signed cert in your LDAP server as part of FreeIPA, then you should insert the Root CA cert for the FreeIPA PKI into the CA section of pfSense, then select that CA cert when defining the Authentication Server in pfSense, followed by the option 16, option 11 commands mentioned previously.

I followed the instructions at the link below which work, except for the use of a "real" cert, which you should use my modified instructions above for.

https://fattylewis.com/2018/01/19/using-freeipa-to-authenticate-openvpn-users-on-pfsense/

I setup network type as "net30" instead of "subnet" and all works. Thank you, you can close the thread.

Solved:

Edit Advanced Outbound NAT Entry:

LAN interface
Protocol Any
source: Any
dest: lan network

Translation:
address: Interface Address

wofks perfect!
Thanks!

Thank you @Rico and @netblues - I really appreciate the help.

Show your OpenVPN Config and Firewall Rules (Screenshots).

-Rico

LDAP browser tool helped a bit and allowed me to see a more specific error:

[LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1]

After a bit of research I've managed to connect using account@domain.co.uk format in "Bind credentials" username.

This might be worth adding to the pfSense-LDAP troubleshooting guide.

You want to use self signed Certs with OpenVPN, not from any other CA!

-Rico

You may be able to do that using reneg-bytes in the custom options field. It depends how the client authenticates. If they have to enter a password, and the client does not retain it, they would need to reenter the password after the specified number of bytes. That's a sum of bytes up and down.

Steve

System logs? OpenVPN logs?.... "No Internet" isn't a particularly helpful description. Can you ping 8.8.8.8 for example? What error messages are returned to you, if any? For example, if you use a web browser to go somewhere, what specific error does it give you? Timeout? Can't resolve address? etc etc.

First off, keep upper and lower case straight when discussing bandwidth and speeds. For example, B = bytes and b = bits. Also, a 140 mb, that's millibit connection which would be damn slow. Perhaps you meant Mb, which would be a decent bandwidth. Also, do your Internet connections have symmetrical or asymmetrical bandwidth? It's often asymmetrical, which means you're going to be limited by the uplink bandwidth at both ends. Now you say 100 kbps. Is that supposed to be bits or bytes? If bytes, then it works out to a 800 kb/s, which is a typical value for some ADSL uplinks.

After a long time we decided to try "second servis" upgrade from pfSense 2.3.5-p2 to 2.4.4-p3 on our remote offices. Everything went fine, so there is a little survey:

OpenVPN site-to-site (shared key) tunnel has so called "dynamic" gateway in 2.4.x on client side, which is created automatically on the system startup. So if your old version has a manually created VPN gateway (routes to headquarter not included in OpenVPN config...), you have to remove this gateway before upgrade. My best practice was backup old configuration, upgrade, login to the upgraded pfSense and completely remove the old OpenVPN client and his TUN interface. Then I created new OpenVPN client. VPN gateway was created by system and a I could set up required routes again.

Its my home network. Sometimes i would play with my Xbox far away from home - im travelling much.
With tap mode, remote stream/play/power-on works well, and i cant get it to work with tun mode. But i would not run another service just for my phone - but i have no choice..

@Gil Hi, How did you solve this problem? I upgraded from 2.4.4-RELEASE-p2 to 2.4.4-RELEASE-p3 and started having the issue after a couple of days. Please share your solution.