Usually that means you have two connections attempting to use the same cert/username at the same time that are bumping each other off.

Allowing Duplicate Connections in the server options can help there, but it's best to use additional certs/users rather than allow multiple connections.

@chris4916:

Indeed. Well, you can have some settings where matching is not verified ;-) but better to make this clean.
Looking more in detail, the outbound page seems quite strange. As explained, there is not need for NAT and gateway.

I also was wrong with my proposal (in fact copy/past error): overrides should be done, as you did BTW, in the local network field.

If it doesn't work, what I suggest is that you look, in pfSense GUI, at potential dropped or rejected packet in log.
Did you try traceroute, targeting internal machine but also pfSense internal interface.
This will tell you, more or less, if issue is with route or FW.

i can connect to lan thinks but not acces
in pfsense

@adamjs83:

There was no internet connectivty on devices on VLAN 80.  After numerous restarts of the service and the router it just started working with no changes to config.  Thanks anyway.

You might try out to set up for the entire VLAN80 the OpenVPN Gateway as their Gateway or on the clients inside
of the VLAN80 you might set up their the OpenVPN Gateway as their Gateway.

@viragomann:

By default pfSense doesn't do NAT for OpenVPN tunnel.

I did ever played with NAT rules. It is set to Automatic.

If you check  online, they basicly do all the same procedure on youtube or on website, but you can follow this video
PfSense Open VPN Tutorial (with Narrator)    from    DlStreamnet
https://www.youtube.com/watch?v=VdAHVSTl1ys

The only step that i did more was the step that i write in the commend below

Certificate Export Options   
      X Use Microsoft Certificate Storage instead of local files.
      X Use a password to protect the pkcs12 file contents or key in Viscosity bundle.

Make sur you check those before download the openvpn file….

Look in the OpenVPN log when it won't start, it'll tell you why.

If you're not using IPsec, go to System>Advanced, Tunables, and add a tunable for net.inet.ip.fastforwarding set to value 1. Save and apply changes and try again.

When pfSense moved to StrongSwan from Racoon, our mobile ipsec went dead for ever. Site to Site works. After that I moved out from pfSense ipsec and took closen look to OpenVPN. I had problems with udp protocol - it did just not work, but after I changed to use TCP - no problems and it works like charm.

So do everything with TCP protocol. With udp I could establish conection and even saw trafic coming from client to LAN, but all trafic from LAN back to client did not work. I had automatic rules done allowing any to all…. => change to TCP and all went right!

As you suspected, this is a routing issue that has been addressed before, but we know it can be hard to search for.  The issue is the remote end has no idea how to route the return traffic because it appears local.  So, while viragomann's solution works, you lose auditing capabilities because all incoming connections at the remote end appear as the server side interface address.  This limitation is a potential risk because you lose granular control and are unable to isolate, identify and firewall incoming connections from RAS users across the tunnel.  Your client will need to make a decision on whether losing that granular control on this particular tunnel is an acceptible risk.

As long as you have access to both ends, the cleaner solution is to make some minor adjustments to the openvpn config:

One the server side, add a push route for the remote LAN to your VPN clients

On the client side, add a return route for the RAS tunnel network

What your isp most likely is doing is blocking access to their smtp server from IPs not owned by them, ie their clients.  So going through a vpn you would be coming from that exit IP not an IP on their isp network.  So yeah - prob block you from sending mail..

Since your on the pfsense forums I assume your using pfsense to connect to this vpn they use.. Then create a policy route so that talking to their smtp server does not go through the vpn.

Logging into a VPN won't log you into the domain. Two completely different tasks.

@ega:

Tried with another Laptop?

If another device reach LAN IP address, and reaches internet, is not crazy to think that the problem is not in the server.

If its in the server, try with the same usr that cannot connect on your phone, and with the usr that can connect on your laptop, this is the unique variable that I saw on first plane, if the problem is on server.

Interesting! Thanks for the suggestion. Here is what I came up with.

1. Laptop user on phone: Works! By "works", I mean I can connect to my network AND tunnel web traffic through the VPN, i.e., "surf the web". Phone <–> LAN/VPN server <--> WAN

2. Phone user on laptop on neighbor's network: Works!

2. Phone user on laptop ON SCHOOL NETWORK: No go! Again, I can connect to my LAN/pfSense box/OpenVPN server, but I CANNOT get through to the WAN. Laptop <–> LAN/VPN server <--///--> WAN

…So I am guessing it is something on my Macbook? I know we are venturing out of the scope of this forum, but what could it be?

..................

Could it be the super-locked-down network I am on when away from home? It's a public university network that uses 802.1X. It seems everything is blocked except TCP 443 (which is what my VPN uses). Could it somehow let me connect to my VPN but not allow me to access websites? My setup USED to work on this network. Could they have somehow blacklisted my MAC? It seems to go against the point of the encrypted tunnel...

Here is where I´m saying

OpenVPN_Conf.png
OpenVPN_Conf.png_thumb

Yes.  That should work fine.  Like I said, leave both iroutes enabled and check the routing tables after they connect.