The trailing number at the end is noise from strongswan's output there, just ignore it. We have a bug ticket open to clean that up in the future. Where you have 0 bytes and packets in like both posts here are showing, it means the other end isn't replying for some reason. Maybe the other end is blocking the traffic, maybe the target system isn't replying, or it might be replying to the wrong device (diff default gateway). Something along those lines. When you have that circumstance as shown, you know the IPsec portion is fine because it's up and you're passing traffic out of it. Look to the other end to see why it's not sending anything back.

Problem is in Android's IPsec client with NAT-D and PSK+aggressive. Use RSA instead.

Unfortunately, there appears to be no way to support a mix of v1 and v2 mobile clients in 2.2.4. https://redmine.pfsense.org/issues/4873 I've had to downgrade to 2.2.3.

In order to provide any assistance or guidance you will need to provide a lot more information, such as: Type of IPsec tunnel (e.g. Mobile, site-to-site) IPsec configuration settings (e.g. IKEv2 or IKEv1, encryption settings, etc) – basically anything except your PSKs or other sensitive info. Make/model/version of the device on the other end of the tunnel Anything else you can tell that would be relevant

If I give it a static public IP I have no problems getting the VPN to come up. Then set up an static public IP and go for it. Suggestions? DynDNS, NoIP, …..

Hi cmb- Thank you for the reply and the offer to look at the configuration.  Everything appears to be working properly now.  It seems like I was not giving the tunnel enough time to come up or I was not passing enough traffic across to bring up the tunnel.  I just got back from the office where I was able to recreate the configuration on the production equipment and everything works as expected.  If I unplug one of the wan interfaces, the gateway group fails over, the vpn ip on the azure gateway gets updated, and the tunnel comes back up on the other wan after manually disconnecting the ipsec connection. I am very excited that everything is working and I learned quite a bit from the experience! Thanks again!

Hi, Can you please help me to configure IPSec between pfsense 2.2.2 to CISCO rv042. I break my head from one week to figure out but no luck :'(. PFsene is on Xen VM in data center. WAN network is a VLAN(73.241.202.232/29) and LAN is also a VLAN (172.51.130.160/27). WAN IP : 73.241.202.238 Gateway(default) : 73.241.202.233 LAN  IP : 172.51.130.190 (Lan Only) LANGW : 172.51.130.190 ( I made it I don't know where it is correct way or not) I am using same LANGW for all LAN. CISCO RV 042 WAN : 35.31.39.153/29 GW : 35.31.39.158 LAN : 192.168.10.0/27 GW  : 192.168.10.1 I Enabled and Created IPSec in pfSense with the settings as you mentioned in your picture except Negotiation Mode "MAIN" . Connection is established but no to traffic is going. From pfSense I am able to ping only RV042(no computers). From CISCO Destination host not reachable. I thought it might be the issue with Gateways or Firewall rules I am not getting anything or is it because of two different VLANS . Can you please help me to fix this. Thanking you in advance. Thank You, Harry.

I have had the same issue with setting up IPsec IKEv1 tunnel (Roadwarriors/Remote mobile setup). I just got parts of the LAN-NW working. Also testet yesterday 0.0.0.0/0 for WAN, but it was not successful. Was not able to think that setting this to LAN interface for Phase 2 will resolve this isseu! Thanks guys! – greetz

I started a new vm on the remote site and started from scratch.  I set it up a while back to connect to the fortigate I used to have here so I can't remember what all I experimented with or had done to get it to work.  The good news is after just setting everything up by hand it is all working so it likely was something like that.

Probably this. https://redmine.pfsense.org/issues/4719  More of an ASA issue it appears, but one we'll revisit.

The GUI certs already have that EKU set but Windows also wants another one "1.3.6.1.5.5.8.2.2" We put some fixes into 2.2.4 to add that into the server cert, so if you update to a snapshot and make a new IPsec server cert it'll be there. So make sure of the following when making a cert: Be on 2.2.4 snapshot, -RELEASE or later Cert is selected as a SERVER certificate Common Name must be set to either the IP address -or- FQDN in DNS of the server, whatever the clients will use to connect, can't make both work.

Your CIDR notations for local subnets have some typos in them.  I think the gist is you want 4 local subnets to access a network 10.41.38.0/22 on the remote end since you were going for multiple phase 2. Did you ever consider GRE over IPsec?  It more or less makes this a routing problem than a multiple SA problem and gives you the ability to adjust MTU per GRE interface/tunnel versus for all IPsec traffic. I found a YouTube video that helped with the basis for my own configuration with pfSense and an HP router a while back maybe it'll help you too.  HP called the GRE interfaces tunnel interfaces, I think Cisco does as well: https://www.youtube.com/watch?v=YPYFcya3Qls You'll be on your own for the corresponding Cisco config commands if you go this route. The only thing of note if you go this route is whenever you reboot pfSense, the GRE interfaces don't like to come up all the way.  You either have to disable/enable them from the web GUI or SSH to pfSense and issue the 'up' command to the interface.  Any workarounds posted on the forums that I've found to use boot time commands from add-on packages didn't work for me.

who can help on that?

Hi guys! Right, got it! Thanks in advance!!! I have another topic about split tunnel. If you guys could help me on that, I appreciate. Diego