At the moment all you can do is make new ones. Since the old ones have expired and are invalid, you can safely delete them.

Maybe this one gives the basic setup (use FRR instead) or ?

https://help.pureport.com/support/solutions/articles/43000485827-vpn-config-guide-pfsense-route-based-vpn-with-bgp

On further thought (& reading) , i think i'll skip VTI for now.
It seems to be quite a new feature, and i'll get trouble if i loose a site halfway around the world.

Maybe i should just stick with OpenVPN & Static routes.

I have an L2L openvpn @home -> Summerhouse , using Certificates & the full monty.

Would there be any significant disadvantage in using a Loooong shared key for this setup ??

Or should i go for a CA on the central site & distribute the certs from there.

/Bingo

@jogofus said in Issues with OpenVPN:

@JKnott first subnet is in 192.168.5.0/24 and the second in the 192.168.0.0/24

Look at both sides of either router:

Router 1 - 192.168.5.57 (WAN) pfSense (LAN) 192.168.5.200 - Client computers
Router 2 - 192.168.0.200 (WAN) pfSense (LAN 192.168.0.2 - Client Devices.

Router 1, both WAN & LAN are in the same subnet. Same with router 2, assuming the LAN subnet mask is /24. It may work if the mask is /25 or longer.

Please post the subnet mask for all interfaces.

that log doesn't really show anything.

can you post your client page? are you connecting by host name or IP? i've heard several use IP and it resolves this..

are you using the DNS resolver, if so how is it configured..

Hi, What was the final outcome with this?

I've just set up pfsense, with a VPN, I can prevent leaks if I send ALL dns lookups to resolver and only select the VPN interface for outbound requests, but then my internet slows for all clients (especially non VPN clients), speed tests come back slow, high ping and gdrive uploads are slow. When I perform a trace route to google.com it goes through massive hops, if I remove the VPN interface from the resolver and add back in my WAN, everything works and trace route hops drop. If I add both, I get leaks.

I assume the content delivery network stuff gets messed up like one poster mentioned?

I think my only solution at the mo is to no use VPN client in pfsense, and stick to the windows/Mac clients on the machines that I'd like to use the VPN....

I'd like to add Pihole or adblocker next, so keen to understand if this got resolved.

Also how can I prevent the resolver using my fail back LTE link for dns, but still support dns when WAN is down? This all feels related and like there should be an easier way to achieve this out of the box :-)

Random brain dump - do we need to ultimately have 2 x Pihole, resolver etc. (1 for WAN 1 for VPN clients) to get around this problem? Is it a design constraint with a single resolver?

Thank you for the suggestions, but they really don't address the basic issue. Once connected with the VPN, the server should know who I am and credentials shouldn't be needed again.

I tried this on a couple of other computers and discovered that it's something particular to my computer. That makes for a much different troubleshooting process. I'll close this as I look into it.

Thanks!

Thoughts anyone?

@guardian Any hints/suggestions? I know how to set up and interface/VPN client... It is just the selective routing I need a hand with.

Welcome :)

Hi viragomann,

thank you for your reply.

You're right, the internet traffic is bypassing the VPN connection.

My user reported otherwise.

The real issue seems to be recurring DNS latency in around 20% of the WWW queries (i.e. using the web browser when the VPN connection is established.)

@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!