Hello. I'm having some issues aswell. What did you do?

Thank you! Windows Firewall really blocked the ICMP packages.  ??? How I made ithis beginners failure to not check this?  :-[ Now everything what I need is working. There is still an Item I just can't understand. I can ping now from all clients all other clients in all locations, but my clients coming from outside over OpenVPN can't ping one of the Openvpn servers?!? Also the frontend of pfsense is not accessible from these notebooks if I choose the internal IPs. If I go over WAN, everything is fine?!? Packet captures show, that the echo and the reply is visible in two devices only: The TAP of the server for remoteclients and the server for remoteclients itsself. Nothing in LAN or in the bridge interface…. It is really funny, that a ping goes over two VPN tunnels and two servers without any trouble, but the servers themselfes are stealh devices  ;D

?????????????

@kapara: Also strange that I need to open gui as administrator You need to complain to MS. (There's also this management interface/ OpenVPNManager export option to avoid this.)

All you need to do is go into the shell portion and type: 11 to Restart webConfigurator, after that it should restore the openvpn portion. Worked for me just fine.

Update So I just systematically went through my setup point by point. Here is what went wrong: Under Interfaces –> (assign) the network port was wrongly assigned to one of the OpenVPN interfaces. Under Firewall –> Rules --> LAN my redirect rule for one of the OpenVPN interfaces didn't have the right Gateway. Both of these should have pointed to the OpenVPN connection in question. But my Interface pointed to an extra ethernet port which is not connected and my firewall was going through my "default" WAN interface. I think what threw me off was that the connection sort of worked when they both were connected and completely worked when only one was connected. So I didn't immediately expect an Interface issue although the Rules I picked up on pretty quick. Anyway… Hope this will help someone in the future. It was a minor issue but took me hours of headache.

I am on 2.1.5 because Transparent proxy with Squid Squidguard don't work. Anyway I am a very beginner, which manual NAT roule do I need? HMA  192.168.1.0/24 * * * HMA address * NO Fixed. Thank you soo much

@II_Echelon_II: What routing settings would i have to use to get an IP from my home network instead of that of the VPN's virtual network? Or should i just redirect all traffic with the the destination of my home network? As said obove, I recommend to use a special tunnel network and a tun device. So the VPN client gets an IP from this tunnel network and pfSense does the routing. For this just enter 192.168.1.0/24 in "Locale Network(s)" field of VPN server config and traffic from client to this subnet will be routed over VPN connection. As mentioned above, you need a rule at pfSense in addition at VPN interface to permit traffic to 192.168.1.0/24. That's all.

Use IP addresses instead of hostnames in drive mappings.

Part two: Configure netfl!x/spot!fy/whatever via VPN (when traveling abroad) 1. Install & Configure pfBlockerNG pkg Install pfBlockerNG Firewall: pfBlockerNG: General Settings Enable pfBlockerNG [Check] Keep Settings [Check] Enable De-Duplication [Check] Enable Suppression [Check] Disable MaxMind Country Database CRON Updates [Check] Inbound Firewall Rules - Interface: "WAN", "VPN1" Outbound Firewall Rules - Interface: "LAN" Floating Rules [Check] [[color=limegreen]Save] Firewall: pfBlockerNG: IPv4 [+ [color=blue]New] Alias Name: "sites_via_vpn" IPv4 Lists: Format "html", State "ON", URL "http://bgp.he.net/search?search[search]=netfl!x&commit=Search", Header "Netfl!x" +Add another list for spot!fy List Action: "Alias native" Update Frequency: "Weekly" (Please don't select Every hour) [[color=limegreen]Save] Firewall: pfBlockerNG: Update Click "Force reload" 2. Create custom FW rule w/ pfBlockerNG Firewall: Rules: LAN [+ [color=blue]New] TCP/IP Version: "IPV4" Protocol: "Any" Destination Type: Single host or alias Destination Address: "pfB_sites_via_vpn" (pfBNG creates alias name with pfB_ prefix and the alias name in Step 1) Description: "pfb_sites_via_vpn" (Must be exactly same as Destination Address, except change capital B to small) Gateway: "VPN1 - 10.8.0.5" [[color=limegreen]Save] PS: In Step 1, replace exclamation marks with "i". Don't put whitespace or weird symbols in pfBNG's alias name or header.

just recognized what my problem was: I opened the thread when I experienced the same like the guy here: http://askubuntu.com/questions/254031/change-openvpn-clients-default-route Ubuntu adds a default-route by itself if you don't check the "use this connection only for resources on this network" When I tried to compile the mail with all configs and details I used the commandline client. thats why it worked like expected. just for the records.

Fixed. It appears I've figured out what was causing this, but not exactly why it was causing it. The two locations having this problem each use their own 4G router as a backup WAN (set as tier 2 in a failover group that the LAN points to), and the router is set to automatically reboot every Sunday morning. When I tested by initiating a reboot of the 4G router with a running ping to the remote LAN network, sure enough the tunnel stopped passing traffic about 30 seconds after beginning the reboot. This happened reliably when trying it for both locations. Once again, going into the remote firewall and restarting the OpenVPN client connection brought it back. So now it's a curiousity why bouncing a tier 2 and not-currently-active WAN connection would break an OpenVPN tunnel.

No, that's not already done. You are setting up the port-forward on LAN, according to the screenshot. It won't do anything useful there. Also, if you have any rules on OpenVPN tab, remove them.

Your site-to-site and remote access OpenVPN instances are both on 1195 on site 1?

Thanks Jim.  I've seen many a bandwidth provider (Comcast primarily) actually strip tagging once the packet reaches their network, so this would simply accomplish ensuring that the PFSense is forwarding VOIP packets before others, whether inside a tunnel or not.  Actually, this is good news for VPN tunnel QOS, as I've seen several postings on here arguing that QOS within a tunnel doesn't work.  While that is technically correct, this feature at least allows for QOS on specific traffic, whether its inside a tunnel or not.