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.

Thank jimp for your speed reply.
I will go to contact the another company for up this value.

OpenVPN is pretty much never faster than IPsec. Not sure where you would have read otherwise.

It can, however, be more flexible.

If raw performance was not the #1 requirement, I would lean toward OpenVPN SSL/TLS so I could centrally-manage things.

@warmadmax:

error in the log is here :

Jul 27 20:50:32 charon 07[IKE] <5> found 2 matching configs, but none allows XAuthInitPSK authentication using Main Mode

did you add the user login? can see you've added the pre-shared key

Wow, I forgot to add permissions to the users to allow it to dial in. I also changed the phase 1 to Main instead of aggressive. IPSEC Xauth PSK works like a charm now.

I found it, had to set keep alive in SonicWall.

After some analisys I see that in one client the Handshake use TLSv1.2 in all other use SSL. I check all settings but machine win its quite similar…