What connections are allowed in from an OpenVPN are governed by the rules on the OpenVPN tab and the OpenVPN assigned interface tab.

For client connections to VPN providers such as this, they should be treated like rules on WAN. Delete/disable all rules unless you need something passed.

It sounds like you have a misunderstanding of what it means to be a STATEFUL firewall. Look that up and how it relates to return traffic for an outbound connection state.

Another user posted a solution a few weeks ago.

https://forum.pfsense.org/index.php?topic=107415.0

Hope that helps!

Check if you can ping the site A pfSense's LAN interface.

I can ping Site B's LAN interface from Site A. However I can't ping Site A's LAN interface from Site B.

If you want to access hosts at client site that to not use the pfSense running the vpn client as default gateway, you'll also have to add a route to these hosts for the network behind site B. Or you add the route to the gateway router.

Site A will be using the PFSense as a default gateway to ideally redirect when the hosts make request for Site B's subnet, PFSense will properly route them.

Thanks again for the assistance!  ;D

I fixed the text and removed the impacted screenshot.

Glad you got it working.

If you want an idea of what your certificates look like take a look through the "Certificate Manager" section of your WebGui.

Welcome to pfSense!

There wasn't much detail in the OP, which makes it difficult to help troubleshoot.  Post your config (server1.conf).  Check the routing table on the client, is there a route to your LAN?  Are there any blocks in the logs?

I think so.  I changed the Outbound NAT from Automatic to Advanced Outbound NAT (AON) and created new rules based off the four default rules created by pfSense, just changing the interface.  I now have the four rules created by pfSense and the four new rules for the VPN interface.  For the interface, I had the option to use OpenVPN or StrongVPN (the name I gave my VPN interface).  I used StrongVPN for the new NAT rules.

I attached a screenshot of the NAT rules I have in place.

AON.jpg
AON.jpg_thumb

Did you have to do anything special to configure the VPN gateway?  Mine is getting an IP assigned from the VPN server at the other end, but the gateway always shows it is offline.

The gateway log shows:

apinger: ALARM: STRONGVPN_VPNV4(10.8.4.165) *** down ***

Awesome, thanks guys!

Not sure if it was the state tables (holy hell, thanks for that - wish I'd known about it earlier) or trying to filter the wrong ports, but it works like a charm now!

Grant them this privilege and they can change their own password

That's the most likely suspect at this point, I'd say.

Yes! Checked "Don't pull routes" and now it works!

Now I want to change the gateway for specific vpn-connected-clients:

On LAN:

IPv4 * VPNSERVER net * * * VPN_PP_AMSTERDAM_VPNV4 none

won't work.

That was it! Thanks @marvosa. All is working beautifully now.

@divsys:

If you setup a second server (Serv2), simply create a new Certificate of Authority (Ca2) and build a new Server Certificate (Crt2) from Ca2.
Any connections to Serv2 will then require a Certificate created via Ca2 and will not be valid at all for the original OpenVPN Server.

Pro's

completely separated Certificate chains full isolation of two categories of OpenVPN clients

Con's

two certificate chains to manage

The concern I have is what happens if a mistake is made in one of the CSOs for a static client. That static client would still have a certificate with the original CA and thus would still connect to the original OpenVPN server and network. Since CSOs do not appear to be enforced, that client could get assigned the network from another CSO.

@derelict:

I have to do some testing but it appears the tunnel network on the server and the tunnel network in the CSO don't have to be related.

If you were to, say, route 10.15.20.0/23 to OpenVPN I believe you could set the tunnel network to 10.15.20.0/24 and assign CSOs out of 10.15.21.0/24 You'd just need to add an iroute in the CSO (I think).  So if there was no CSO they'd get an address out of the dynamic pool and not step on any properly-configured CSOs.

I might be completely wrong though.

Can anyone else confirm if this is a valid configuration? can the "Tunnel network" setting in the OpenVPN server config be completely unrelated to the networks assigned in the CSOs? If so, I think this would be the ideal solution

Maybe it is a MTU problem, try a smaller MTU on the server side (can not modify the client).
Is this warning a problem?

WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1300', remote='link-mtu 1542'

this thread is from Jan 2015…

I doubt the OP is still having a problem..

You reach 350kb doing what??  and is that really kb or KB?

You trying to do SMB file copy over a high latency connection?  Yeah its going to BLOW...