Ok, but I seem to not be able to have QuaggaOSPF and OpenBGP installed, and I am not able to tear down our OpenBGP configuration and move to Quagga without taking serious down time.

Not sure why but the config change was never picked up even after restarting the service. Rebooted the firewall and it's now sending the clients the right subnet so probably something is cached and not reloaded on restart.

Did you ever find a solution for this problem? I face the exact same problem and tried pretty much every single approach described here and none worked  :(

Yes, that works fine, provided you setup all of the appropriate Phase 2 entries in IPsec and routes in OpenVPN. For example, your IPsec tunnels would need to have phase 2 entries such as: Site A<->B: P2 for A-B, OpenVPN-B Site A<->C: P2 for A-C, OpenVPN-C OpenVPN: Local network set for A, B, and C And if you want B and C to reach each other through A, you'll need additional P2 entries to cover B-C / C-B on the appropriate tunnels and in the proper direction.

Ah.. Yeah that is a problem…

Thank you for the suggestion. IKEv2 from what I'm reading involves shipping certs to your users and installing them. (correct me if I'm wrong on this) And for that reason, If I go with IKEv2, I may as well go with OpenVPN. Regards.

Hi, With IPsec the easiest solution is filter by port in transport mode. A Linux host with Strongswan or Libreswan supports it. However I think the Pfsense GUI doesn't support that setting yet (I would need it also). So you could create a GRE tunnel over an IPsec tunnel and forward that port to/from the GRE tunnel interface. For example with a rule in your LAN which that remote port would translated (NAT) to the GRE tunnel IP.

Hmm, Seems this is similar to my problem… https://forum.pfsense.org/index.php?topic=134812.msg738845#msg738845 Well, here is my, late, contribution to this thread: 1. A crypto map does the trick with transport mode. 2. Crypto map with Tunnel mode works only if a Crypto Access-list matching the one on PfSense is applied to the Cisco map (restricted to IPv4 or IPv6 range selection) 3. If an "IPsec Profile" on the Tunnel interface (Tunnel Protection..) is used instead of a Crypto Map on the Physical interface then the auto generated Crypto Access List on the Cisco selects only GRE protocol traffic instead of IP. This has no chance to match the IP protocol traffic selection on the PFSense side and this is why I believe the Tunnel Protection Cisco config fails. This can be verified on the cisco side using the commands: "debug crypto ipsec" "show crypto ipsec sa" (the command "debug crypto isakmp" will show that although phase 2 attributes are accepted the proposal is rejected "No_Proposal_Chosen". The reason can be found in the output of the "debug crypto ipsec" command) 4. Not sure if Tunnel protection can work with Transport mode between Cisco and PFSense. Will be happy to try once "3" is solved This is why I am asking for a way to configure PFSense in a way that I can select only GRE protocol traffic instead of IP as IPsec Phase2 interesting traffic.  This will also make possible to narrow  down the selection of packets to be encrypted by IPsec on the PFSense WAN interface to GRE and allow for WAN sourced non GRE packets to leave the interface unencrypted. Would be nice to see this in a future update. More options in selecting IPsec interesting traffic Until then..  Is there a way to tweak PFSense configuration file to achieve this? Regards, Alexandros

Hi, I'm not sure about open a new topic for this feature. Is it already implemented? Could it be achieved with any rule? Regards.

I finally found a solution! On the remote PFsense router I went to VPN -> IPSec -> Advanced Settings and disabled "Enable bypass for LAN interface IP" (scroll all the way down) and I finally can connect to the remote host! Check if your windows firewall on that host is on, as it likely will recognize the incoming traffic as non-private traffic and thus might filter it (to test it, shut down the firewall for public networks).

@tweek: If you could please consider BIRD for inclusion.  My router expert friend assures me BIRD is much more powerful and better architected than FRR. Our router expert employees prefer FRR/Quagga and assure us it's better than BIRD in various ways.

@Derelict: If your OpenVPN Tunnel network is 192.168.100.0/24, do something like this substituting the proper remote network, of course. That will need the reciprocal settings on the other side. You`re totaly right I just added my open pn tunnel network to ipsec phase 2 It works !

I have the EXACT same issue. What's strange is the problem is only occurring one way. I decreased MSS clamping on both sides to 1300 and everything is working now.