Do you have any hw acceleration active on your systems or this is just from plain software crypto ipsec?

The only way at the moment I could connect in VPN to our CLOUD with iPad, was to install sonicwall VPN client, then connect to our own firewall through SSL to be redirected to our CLOUD network, which is not the best way to us.  ::)

@vibenation:

@iced98lx:

Joe-
  This thread isn't suggesting that the cisco client won't work behind a pfSense firewall, it's suggesting the pfSense firewall can't be configured out of the box to accept connections IN from that client.  We're discussing if your wife's new employer was using pfSense as the tunnel endpoint, not if you were using it as a firewall from home.

Apparently I need to go to the Zoolander reading school….Thank you for clearing that up for me.  I suppose thats what I get for trying to burn both ends of the candle at once!

I will attempt the deployment this weekend when I can test it without impacting her normal work routine.

Joe

No worries, I don't expect you'll hit any snags connecting, I used cisco vpn software behind pfSense for a long time.

@jasonr:

I had to chown -R root:wheel /etc/ in the GUI to get ssh and console to work.  Upgrade messed it all up.

I found the source of that issue looking at covex's system. I just fixed that issue, or worked around it at least, by re-issuing the full update files again with "chown -R root:wheel *" of what's within them (when they were re-packed they lost that, which shouldn't matter, but mtree is failing after upgrade from any pre-FreeBSD 10.x base version). We're looking into a proper long-term fix now, but that shouldn't happen upon upgrade to 2.2.2 from 2.1x and earlier versions anymore.

I had this happen to me and started going nuts trying to track it down after my upgrade. When I deleted my phase 1 and 2 entries and rebuilt them using the exact same settings, my issue went away. (well, this particular issue anyway)

I should have captured the config files associated with the GUI to compare.

@iorx:

Hi!

Digging around on one other issue and saw this. Maybe this be of help with your issue.
My LAN routing to the other side of the tunnel was OK but I couldn't get pfsense to reach it (resulting in not DNS Resolver working among o.t.)

This solved every thing for me:
https://doc.pfsense.org/index.php/Why_can%27t_I_query_SNMP,_use_syslog,_NTP,_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN

Exact, iorx : in my prod config, C class IP addresses are all redirected to the LAN, whereas remote end of the IPSec tunnel is also 192.168. From my point of view (maybe mistaking, but why ?) this is normal, regarding routing : remote end of IPSec tunnel is "directly connected" for the pfSense, so not needing any static route.
Have to recognize that adding a bogus internal IP to do it play may appear a little bit strange, though !  :D
Cheers !

Thanks jimp.

Unfortunately my results appear to be slightly different. I get this "none allows XAuthInitPSK authentication using Main Mode" error.

Apr 20 21:23:21 charon: 09[IKE] <24> 166.xx.xx.xx is initiating a Main Mode IKE_SA Apr 20 21:23:21 charon: 09[ENC] <24> generating ID_PROT response 0 [ SA V V V V V ] Apr 20 21:23:21 charon: 09[NET] <24> sending packet: from 72.xx.xx.xx[500] to 166.xx.xx.xx[500] (180 bytes) Apr 20 21:23:21 charon: 09[NET] <24> received packet: from 166.xx.xx.xx[500] to 72.xx.xx.xx[500] (228 bytes) Apr 20 21:23:21 charon: 09[ENC] <24> parsed ID_PROT request 0 [ KE No NAT-D NAT-D ] Apr 20 21:23:21 charon: 09[IKE] <24> remote host is behind NAT Apr 20 21:23:21 charon: 09[IKE] <24> remote host is behind NAT Apr 20 21:23:21 charon: 09[ENC] <24> generating ID_PROT response 0 [ KE No NAT-D NAT-D ] Apr 20 21:23:21 charon: 09[NET] <24> sending packet: from 72.xx.xx.xx[500] to 166.xx.xx.xx[500] (244 bytes) Apr 20 21:23:22 charon: 09[NET] <24> received packet: from 166.xx.xx.xx[4500] to 72.xx.xx.xx[4500] (92 bytes) Apr 20 21:23:22 charon: 09[ENC] <24> parsed ID_PROT request 0 [ ID HASH ] Apr 20 21:23:22 charon: 09[CFG] <24> looking for XAuthInitPSK peer configs matching 72.xx.xx.xx...166.xx.xx.xx[10.104.175.66] Apr 20 21:23:22 charon: 09[IKE] <24> found 2 matching configs, but none allows XAuthInitPSK authentication using Main Mode Apr 20 21:23:22 charon: 09[IKE] <24> found 2 matching configs, but none allows XAuthInitPSK authentication using Main Mode Apr 20 21:23:22 charon: 09[ENC] <24> generating INFORMATIONAL_V1 request 3999605427 [ HASH N(AUTH_FAILED) ]

Android client is the main mode initiator, pfsense is the aggressive mode responder.

The "auto" mode that I can find on my settings is the IKE version, not negotiation mode. I'm sticking with V1 due to the clients I'm using for road warrior use.

I'm using IP address for the identifier. I think this is OK, right? Under the following guide it mentions that the identifier should match, but then I think I wouldn't get "found 2 matching configs" right?
https://doc.pfsense.org/index.php/Upgrade_Guide#IPsec_Changes

(and yes, I have a site to site configuration and a road warrior configuration, hence 2 configs)

Thanks!

Please read the docs and come back when you get stuck somewhere.

https://doc.pfsense.org/index.php/Category:IPsec

@ermal:

I have not tested this on 2.2.2 but for sure it will be usable on 2.3 of pfSense since even FreeBSD has had fixes especially for this in kernel side.

Excellent!
I'll give it a try with 2.2.2. Otherwise I'll wait for 2.3-snapshots.

ipsec or openvpn ?

Talking to myself. No not crazy at all  :o

My solution above is not the right way I think. The underlying issue with IPSEC is traffic from pfsense, how to get it to route its own traffic.

This solved the problem with "DNS Resolver" not working, that is; not reaching a DNS on the other side of the tunnel. After this I could restore the setting for "Outgoing interface" to "All" instead of "LAN".

https://doc.pfsense.org/index.php/Why_can%27t_I_query_SNMP,_use_syslog,_NTP,_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN

Hi!

2.2.2.

It's a 2.2.1 fresh install, updated to 2.2.2

On the 2.2 side, apply the logging changes for IPsec suggested here:
https://doc.pfsense.org/index.php/IPsec_Troubleshooting#Common_Errors_.28strongSwan.2C_pfSense_.3E.3D_2.2.x.29

And then have the 2.1.x side initiate to see what the problem really is.

Yes, saw that. You know that the device the other end only has 1 x P2 configured? Most devices don't have the ability to setup multiple phase 2's, Cyberoam, Sophos UTM, vShield, Palo Alto, they all just allow multiple subnets within the single P2 config or as a route using the tunnel as the gateway. If you were already clear on that, I'm not sure what the answer is. As the 2 x P2 on the pfSense box has identical settings, apart from the subnet.

Done.
https://redmine.pfsense.org/issues/4626

After version 2.2.2-RELEASE upgrade this seems to fix this problem. good job!

Hi,
updated to 2.2.2 but still not working for me, see topic: https://forum.pfsense.org/index.php?action=post;topic=92056.0

You can specify the NAT translation on the phase2 settings page.
It is clearly marked as NAT segment translate.