As I said, everything used to work with the same VPN config with my OpenWRT router, I just figured when the VPN was connected the domain information was getting passed through before. But I went and found the domain passthrough and set it up, and it is working like it used to now, I can connect just by ComputerName. Not sure how the other router worked without the same setting. Thank you both for your help.

@marvosa That actually was the problem. I was mistakenly connecting the router's WAN port to the LAN port of the Netgate. Admittedly I should have recognized the issue with having the two networks (Netgate - Router, then Router's LAN). So, everything just about works. I want to access a particular host on the LAN (a network share). I looked up the DHCP client list and found its assigned IP address and was able to remotely (through the VPN) connect to it. Because I wan't this to be reliable, I assigned a static DHCP rule for this specific LAN host. But now the VPN client's cannot see it anymore. What could be going on? All other dynamically allocated DHCP slots remain reachable from the VPN. I have a rule on the OpenVPN group to allow any to any, which is why the first part worked. But for some reason the statically assigned DHCP rule is acting as if it were not part of the LAN? I did notice that the host was marked as "offline" in the DHCP client list despite being active and reachable from other hosts on the LAN. I tried adding a rule specifically allowing access to this static IP from the VPN, but of, course, the any to any rule takes precedence so this new rule does not get used. Any ideas? Actually, the issue seemed to have resolved itself after some time.

Post your server1.conf (/var/etc/openvpn).

@scilek said in Clients cannot communicate with each other.: I have learned through hardship that it is a good idea to reboot your router after configuring router OpenVPN clients/servers A reboot is not necessary. Only stating this so future readers will know. Glad you got past whatever problem it is you were having.

Post your server1.conf (/var/etc/openvpn).

Which version of the client are you using, and can you post server/client configurations on your thread here? I suspect if you aren't pushing this from your server the client may be setting it. Windows also has metric priorities on each ethernet adapter and it may be the case that if both are publishing default routes, the interface with the lower metric value is winning out.

@alagave said in User Auth issue: can't ask for 'Enter Private Key Password:' Somehow it thinks your certificate private key is password protected. If it is, then don't do that. Remove the password from the key and then import it again.

The problem was caused by Network Manager which was handling the opvn config. To disable sending all traffic through the VPN do this Click NetworkManager applet icon > VPN Connections > Configure VPN... > select VPN network > Edit > IPv4 Settings > Routes... > Check ‘Use this connection only for resources on its network’ SOLVED!

Well, the topic is "How do I force all internet through the VPN tunnel?", so my assumption is you want internet traffic on your LAN forced thru a VPN tunnel, correct? If so, your end is the local end and the network behind the VPN is the remote (or far) end. how do I do a Policy route? Assign the VPN to an interface. On the LAN tab, create a firewall rule (above your LAN net/any rule) that has: a. Protocol = any b. Source = specify your LAN subnet or choose " c. Destination = any d. Gateway = The gateway IP created from assigning the VPN to an interface (This is done by expanding the "Advanced Options" section)

thank you @Rico for you reply I will read it soon! then I should connect the internet cable directly to the WAN port of the pfSense. If I use pfSense in place of the ISP router: do you think I should ask my internet provider for the line parameters to be settled up on pfSense? or maybe have I to set up some other special configuration on the pfSense because I use it in place of the ISP router? thanks!

Gosh! So easy. Thank you very much.

@viragomann said in How to allow roaming clients access remote LANs?: @scilek said in How to allow roaming clients access remote LANs?: Remote Networks -> 172.16.0.0/24, 172.16.1.0/24, 172.16.2.0/24 These networks has to the added to the "Local Networks" in the access servers settings. Leave "Remote Networks" blank. Iam sorry, in my haste, I made a mistake. I have corrected my original post. Additionally you have to add the tunnel subnet of the remote access server (10.0.2.0/24) to the "Remote Networks" in the OpenVPN settings of both branches. I did that and it worked. Thank you very much. (Well, I had to create static routes again, but still, I now understand the whole concept.)

@Crimzinza Also run Packet Capture on pfSense, to determine if it's getting that far. It's hard to solve a problem when we don't know the details.

Hello Jim, thanks for your suggestions, of course you were right. On the LAN side I had a default gateway to reach some internal subnets, which tricked pfSense into thinking that LAN was actually a WAN. I suppose that this was the reason that caused the masking of packets routed by OpenVPN and directed downstram via the default gateway. The setting of Firewall > NAT > Outbound was and remains "Automatic outbound NAT rule generation. (IPsec passthrough included)". Added the proper static routes on LAN side, removed the default gateway on the LAN side, everything was back to work as expected, that is: no automatic masquerading happening for packets coming from remote OpenVPNs. Lesson learned: the "add gateway for WAN, none for LAN" advice during setup process is there for a reason. Thank you again Gino

No. I got a public ip from my ISP.

The Remote IPv4 networks were also defined in 2 other OpenVPN server definitions. While the tunnels not being active, it does seem to create routes for it. In the end this seems pretty logical, but was unexpected while doing the configuration. I was under the impression that the routes would only be set upon actual OpenVPN connection. Changing the subnets, eliminating overlap (wether connected or not), did the trick. "Duh".

Yea that fixed it. I didn't have to add a gateway on the pfsense at site B. I added the interface/gateway on site A side and created rules in LAN tab to route IPs in alias over to site-to-site interface gateway. Then pushed the routes to site B in the site-to-site OpenVPN server configuration on site A. On site B, I only needed to create NAT outbound rules so that packets would be able to get out to the internet.