Thanks for the quick replies! bcruze: I did try that guide, I reckon its the same as the first link I posted. I'm a bit confused by it, as Step 18 has: Set Interface to "OpenVPN" But it doesn't show where to setup this interface, or where it came from? I think it's missed a step somewhere (or I'm misunderstanding). V3lcr0: If I remove those two rules, I just get a data from LAN to go over my normal gateway ie WAN. Sorry might have misunderstood your instructions. Alias for source (Firewall -> Alias -> IP): Name:PIA_VPN_IPs Type:Host(s) IP or FQDN: 192.168.1.48 Any other hints? Edit: Sorry everyone, the answer was hidden in plain sight! A new interface OpenVPN is added automagically when you configure it. I added all the NAT outbound rules as specified in the guides with OpenVPN as the interface this time and it worked straight away!

reserved

Correction: I'm running 2.4.2 Release FreeBSD 11.1 Release -p6.

I did a little bit of digging and found the following. Port Forwarding from VPN Provider to Torrent Client: https://forum.pfsense.org/index.php?topic=65094.0 Which also refers to this thread: https://forum.pfsense.org/index.php?topic=65230.0 So the floating rule did the trick and now port-forwarding works! :) Is this a bug? Was it reported back in 2013? Has it been fixed and then regressed?

@Nadar: We're discussing the exact same issue in this thread: http://forum.pfsense.org/index.php?topic=65230.new;topicseen#new From what I can understand, the reason is that the reply-to address for some reason isn't used for the return packets for the associated firewall rule for the port forwarding NAT rule. I've managed to get it to work by: On the NAT port forwarding rule, select "none" under "Filter rule association". Create the rule manually instead, under floating rules. The rule is basicly a "copy" of the one automaticly created by NAT: Pass, Quick, in, IPv4, <protocol>, source: any, Destination: port forwarding destination host, Destination port range: forwarded port Make sure it's high up/on top in the floating rules, and make sure it's a quick rule. When I look in rules.debug, the effect of this is simply that the rule (it's the firewall rule that contains the reply-to address) ends up much higher in the resulting ruleset, and that seems to make all the difference. I haven't quite figured out why yet.</protocol> Thanks! You saved me from a lot of troubleshooting. Is this a bug which has still not been fixed?

Very well. So I followed your hint of P2P with Shared Key and configured as the following: Site A is Server for Site B Site A is Server for Site C Site B is Server for Site C Site C is Client for Site A Site C is Client for Site B Site B is Client for Site A Everything seems smooth in terms of route learning and inter-site connectivity. I did some traceroutes and I was able to see that if I interrupt the direct connectivity between A and B then A goes through C to achieve B. That's what I wanted! I had to set the same metric on quagga "Interface Settings" for all interfaces on all boxes to let OSPF decide the best paths. OSPF implementation seems to be smart enough to know the shortest path. Question: On site C I'm using 2 PFSense with CARP. Is there any way to sync the QUAGGA configs between them? I only found the option to monitor the CARP interface…

https://www.netgate.com/our-services/gold-membership.html

@viragomann: With "Redirect gateway" checkt, the client should get pushed the default route. However, the default route is split in two parts: 0.0.0.0/1        <ovpn-server>128.0.0.0/1</ovpn-server> That's why the OS doesn't see the vpn server as default gateway. So check the clients routing table or try a traceroute to a public address to verify if you go over vpn. Nevermind!, i ran a "tracert" command to "X" public IP and i noticed it is going trough my VPN server, i also checked on http://www.whatsmyip.org/ and i had my VPN server public IP. Thanks for the tip !

So the pfSense local network address 10.10.0.4 is not set as default gateway on the remote machines? You have garbled the vtnet0 address, so I assume it will be a public one, isn't it?

@viragomann: If the cloud has no route back to the clients LAN, you have to set an S-NAT rule on the server site for the client-cloud connection. Ah ha!  This was the missing piece.  I added an outbound NAT rule for the remote LAN on the WAN interface and that completed the route. Thanks!

DERP! I figured it out.  I had the tunnel network set to a /24 instead of a /30.  with a /24 you need to specify routing commands manually on a site-to-site.

Tired of tinkering with the production environment to find out the problem and sometimes knocking down all the connections I decided to build a lab of virtual machines / networks and followed this tutorial creating an environment from scratch. https://forum.pfsense.org/index.php?topic=144212.0 And I have achieved connectivity between all pfsense hosts also between pfense hosts and the servers located in the Main Office. With this result I went into the production environment and created a new openvpn server on different port and started to migrate the branches from old configuration to new successfully. The above link is very practical and produces very little configuration on the clients, controlling almost everything in server configuration. Thanks to the friends who tried to help. Now I can rest my head, 8) 8) 8), because I have not thought of anything else for more than 7 days.

@bond_it: The only issue is that the OpenVPN export exports the interface IP address On the client export page, change host name resolution to 'other', enter vpn.mycompany.com in the host name box, then click the 'save as default' button.

Since I had a similar issue the solution I found was written here: https://forum.pfsense.org/index.php?topic=88467.msg491409#msg491409 System -> Advanced -> Networking (tab) and check the "Disable hardware checksum offload"

If you were using SSL/TLS, then the exporter will only show users with certificates created by the same CA set in the OpenVPN server as the Peer Certificate Authority. Without that they wouldn't be able to log in anyway so they are not shown for export. There is no Shared Key remote access server so I don't know what you actually did. Why are we talking about the Windows client when you're dealing with a site-to-site?

@svarto: The OPENVPN_interface is what I assigned in the Interfaces to network port ovpnc1, the other OpenVPN was created automatically when initializing OpenVPN service however there was no gateway created so that is why I bound the Network port ovpnc1 to a OpenVPN_interface. I assume this is the one I should be using? @svarto: I have DHCP activated on DO_VPN interface (and subnet), however the OpenVPN_Interface has both ipv4 and ipv6 types set as None. @svarto: I have specified explicitly the DNS servers for the DO_VPN DHCP_Server, please see attached screenshot. However, for LAN and OPT1 I haven't explicitly specified it and I assume they will be able to pull it automatically from my ISP through the WAN interface?