One-way traffic over VTI IPsec tunnel between pfSense and Cisco ASA

[ml198]

Hi everyone, I'm new to pfSense and the forum, and am hoping someone might be able to help me get a VPN setup working that I have been struggling with for about a week now.

My issue is similar to the ones described in this topic, though none of the solutions in that seem to work for me.

Here is what I am trying to achieve:

🔒 Log in to view

To elaborate, I have my local pfSense firewall, and I followed these instructions to set up a Routed IPsec, with 10.250.250.0/30 as the tunnel subnet.

At the remote end, there is a Cisco ASA firewall, configured the same way.

The IPsec tunnel comes up just fine, phase 1 and phase 2, but traffic only seems to flow one way, from my local pfSense to the ASA. Packet captures at both ends show ICMP packets being sent from here, arriving at the VTI interface on the ASA, replies being sent from the ASA, and then disappearing.

I have not set up any routes yet, as I figure there's little point doing anything until there is full connectivity on the tunnel subnet. I am not 100% sure which end the problem lies, but do have a lot more experience with the ASA, and have VTI tunnels to other endpoints that work, so it feels more likely to be an issue with pfSense.

Firewall rules seem fine, and throwing in some allow all rules at the top of the IPsec and WAN tables makes no difference, so I don't think that's the problem.

The only thing that seems off is that the IPsec VPN status shows both the local and remote subnets for the VTI tunnel as 0.0.0.0/0. It could be normal, but in the earlier post referenced at the start, that status showed the actual tunnel subnet, instead.

I am including screenshots of all the config on the pfSense, and here is the relevant config from the ASA firewall, all edited to obscure any confidential details:

group-policy pfSense internal
group-policy pfSense attributes
 vpn-tunnel-protocol ikev2 

crypto ikev2 policy 3
 encryption aes-gcm
 integrity null
 group 14
 prf sha256
 lifetime seconds 86400

crypto ipsec ikev2 ipsec-proposal pfSense
 protocol esp encryption aes-gcm
 protocol esp integrity sha-256

crypto ipsec profile pfSense
 set ikev2 ipsec-proposal pfSense
 set pfs group14
 set security-association lifetime seconds 28800
 responder-only

crypto ipsec df-bit clear-df WAN
crypto ipsec security-association replay window-size 128

tunnel-group <pfSense public IP> type ipsec-l2l
tunnel-group <pfSense public IP> general-attributes
 default-group-policy pfSense
tunnel-group <pfSense public IP> ipsec-attributes
 peer-id-validate nocheck
 ikev2 remote-authentication pre-shared-key *****
 ikev2 local-authentication pre-shared-key *****

interface Tunnel7
 nameif pfSense
 ip address 10.250.250.2 255.255.255.252 
 tunnel source interface WAN
 tunnel destination <pfSense public IP>
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile pfSense

Phase 1 config:
🔒 Log in to view
🔒 Log in to view

Phase 2 config (VTI):
🔒 Log in to view

IPsec status - note incorrect addresses, and traffic counter only incrementing on the TX side:
🔒 Log in to view

Gateway status - the VTI interface and the associated interface are being created properly, as far as I can tell, though the status is always pending.
🔒 Log in to view

I'd appreciate any help anyone can offer with this, I am completely out of ideas.

[pete35]

You may try to set the lifetime on the pfsense site to 28800, same on the ASA site. I always set it identical.

[ml198]

Good suggestion, I have now updated the config so the lifetime matches at both ends - 86400 seconds for phase 1, 28800 for phase 2.

Unfortunately, it has not solved the issue, still unable to receive traffic at the pfSense end.

[pete35]

did you check this: https://forum.netgate.com/topic/60633/pfsense-2-1-and-cisco-asa5520-one-way-traffic-solved?_=1598350584376

[ml198]

As this is a connection between two virtual tunnel interfaces, there is no NAT involved - while it is certainly possible for NAT rules to interfere with traffic outside the tunnel, the two VTI endpoints should be able to reach each other.

I have run the Cisco packet tracer on both this connection, and another VTI-based tunnel to AWS, and the results are identical - in both cases, it identifies the correct VTI to use based on source IP, does not apply NAT, checks that there are no rules or policies blocking the outgoing traffic, and concludes that the packet is allowed and should be sent over the VPN.

The config in both cases is identical except for addresses, names and PSKs, but the connection to AWS works (can ping the remote VTI address), and the one to pfSense does not.

[pete35]

Hmm.... did you reboot the pfsense ? Sometimes it helps ....

[pete35]

Which version of Pfsense do you use, pls update to 2.4.5 p1. Mobike is gone on the latest GUI.

[ml198]

I have rebooted pfSense many times over the course of troubleshooting, I don't think turning it off and on again is going to be the solution in this case.

And I am already running the latest stable release:

🔒 Log in to view

[pete35]

ok, im out of ideas now ...

[Derelict]

Have you done packet captures on the outside interface to be sure the ESP being sent by the ASA side is actually being received on the pfSense side?

[pete35]

Hmm, i had this problem before with pfsense ipsec vti tunnels. You may try to disable and enable the vti gateway, to bring it up from "pending".

[ml198]

@Derelict - I just logged into the pfSense and set up a packet capture on the WAN interface, as suggested, and saw that ESP packets were being received when I sent out test pings.

And, as it turns out, so were the ICMP replies on the tunnel interface. I changed nothing locally, but other configuration changes were being made on the ASA, so presumably, there was a conflict in some other part of the configuration that I had not noticed.

Thanks everyone for your suggestions.

[lfoerster]

Maybe it helps...
You can find a running Cisco pfSense VPN configuration here:

Cisco-pfSense with VTI

Unfortunately in German but the screenshot and config is pretty self explaining.