i frequently face this same identical issue, bytes one direction, but zero bytes opposite direction.  its reversed on the opposite pfsense.  this happens on a pfsense has has 26 or so IPSec tunnels, and just 1 tunnel will do this, the other 19 are functioning normally. sometimes it self recovers, sometimes this will go on for hours (effectively killing the tunnel and traffic from clients) until i massage it back online. i have not been able to figure out the root cause.

I was struggling for more than one week to make IPSec for mobile clients to work (only Android natively worked) and disabling "Provide a list of accessible networks to clients". I don't know if it's a bug or a feature, but disabling "Provide a list of accessible networks to clients" works on 2.4-BETA too.

@Derelict: I would use much longer IKE (P1) and ipsec (P2) lifetimes. Something like 86400/28800 should be more than sufficient. Most IPsec incompatibilities occur during re-key. Why make it re-key far more often than is necessary? Yea, 99% of problems occurs when re-keying. About the lifetimes I think you'd have to ask Netgate support since they provided the config. But personally, I will try to use longer lifetimes.

solved! In Interfaces->wan i set MTU to 1450 and everything work. Thanks anyway

Hello, I have a similar problem with 2.3.3 version, on pfsense 2.1.5 works fine.

Hello, I have a similar problem with 2.3.3 version, on pfsense 2.1.5 works fine. What is your pfsense version? I'm running the pfsense into  a xenserver 7.0.

Elnadmin, EAP-RADIUS auth scheme just means you're using a radius server to authenticate your IKEv2 clients instead of using the pre-shared keys on IPSec pfsense tab. Your initiator becomes a supplicant and will send authentication to your vpn server, which becomes a radius client that forwards the request to the radius server, that in turn will performs authentication. I'm trying to explain it as simpler as i could in english, which is not my primary language, and i hope i understood correctly your issue. Think the RADIUS server as a sort of "authentication gateway" that receives the authentication requests from some devices (in your case the VPN server) and authenticates or redirects authentication to the right server accordingly (could be locally, against an LDAP server like a domain controller, or certificate based), and replies back with a YES or NO and eventually some other messages. It's completely transparent to the device you're connecting with, which will use the authentication configured on the radius server itself. Depending on how you configure authentication on the radius server, you need to set up clients accordingly. If you're using certificates to authenticate clients you're likely to use EAP-TLS, if you use usernames and passwords, you're very likely to use EAP-MSCHAPv2. All those protocols can be configured in the FreeRADIUS:EAP/EAP section in the package configuration section, it's up to you to decide which one. The main advantage of using a RADIUS server instead of the internal database is that you can use the same authentication server for multiple devices, such as network devices (managed switches and routers which normally don't support more complex authentication schemes), VPN servers, 802.1x networks and well, you got the idea. It's a standard protocol for Authentication, authorization and (eventually) accounting. EDIT: in your case, under mobile clients you must also select the radius server database. You can configure pfsense to use other databases for authentication under Settings / User Manager / Authentication Servers, then your vpn server to use EAP-RADIUS, and your radius server with the correct EAP authentication. From the message you posted in your first post, it seems the IPSec server is not configured to accept EAP requests. What protocol do you have under the P1 auth method and under FREERADIUS/EAP?

You're connecting to ipsec using a client or another firewall? the tunnel remote network list usually states which traffic will pass over the tunnel, if you have 0.0.0.0/0 then everything will afaik.

Which dyndns provider works with pfsense? I thought dyndns.org was gone now

Define "inexpensive". A Netgear GS-108T will run $60-80-ish and has good VLAN support (and LACP and other decent things). It's not the greatest switch in the world but it gets the job done. I've seen others tossed around from HP and TP-Link that have decent VLAN support cheap but I haven't used those. I have a larger TP-Link switch and it's great but it was ~$120 for a 16-port switch.

@StaChris: I have multiple site to site connections, some going from PFSense to Netgear boxes via IKEv1 PSK, 2 going to other PFSense boxes using IKEv2 PSK. I have mobile client enabled and configured, I have a mobile policy for mutual psk + Xauth for road warriors. When I enable that policy no matter how it's configured, all IKEv1 tunnels going to the netgear boxes drop and don't come back up until I disable the policy. All IKEv2 tunnels going to PFSense boxes seem to be operating fine however. Does anyone have any idea why this is happening? I'm running the latest stable build of PFSense 2.3.3. Are you using IKEv1 or IKEv2 for the mobile setup?  Considering all the IKEv2 tunnels stay up but the IKEv1 tunnels go down, I wonder if there is some conflict.  If using IKEv1 for the client, have you tried using IKEv2 for the client and see if it affects anything?  Do the IKEv1 tunnels still go down, do the IKEv2 tunnels go down instead, or does everything continue working like normal.

OK, so I figured it out.  It was a configuration error on my part, but not with radius.  The problem was this setting in the OpenVPN server configuration: IPv4 Tunnel Network Essentially, I accidentally put in my internal network into this field instead of an unused subnet for VPN access.  I'm thinking this screwed up communication between OpenVPN/Pfsense to the radius server (Windows AD/NPS).  Basically, I could not get OpenVPN users to authentication over radius so I tested with the local database.  It worked.  I looked at the OpenVPN client and found that it was assigned an address that should be on the internal network, not a VPN address.  That is what lead me to re-review the settings and find the error.  Once adjusted, everything worked.  I can also authenticate to both OpenVPN and Mobile IPsec via radius with both running at the same time. I hope this helps someone else.

Hello guys, as i am having the same problem, where can i find this config in order to change it?

Solved, netgate suport found dynamic peers on same crypto map on Cisco side. Please buy them a beer from me :D

I believe IKEv2 security protocol is what most of the paid vpn apps do use. So, based on that i think it is quite feasible to use.

The IPSec log if it means anything to anyone - doesn't to me sadly. Apr 7 09:31:48 charon 11[IKE] <20> received FRAGMENTATION vendor ID Apr 7 09:31:48 charon 11[IKE] <20> received DPD vendor ID Apr 7 09:31:48 charon 11[IKE] <20> 192.168.1.33 is initiating a Main Mode IKE_SA Apr 7 09:31:48 charon 11[CFG] <20> received proposals: IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:AES_CBC_128/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024, IKE:AES_CBC_128/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:3DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024 Apr 7 09:31:48 charon 11[CFG] <20> configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 Apr 7 09:31:48 charon 11[IKE] <20> no proposal found Apr 7 09:31:48 charon 11[ENC] <20> generating INFORMATIONAL_V1 request 4286656525 [ N(NO_PROP) ] Apr 7 09:31:48 charon 11[NET] <20> sending packet: from 86.178.124.128[500] to 192.168.1.33[500] (56 bytes) Apr 7 09:31:51 charon 11[NET] <21> received packet: from 192.168.1.33[500] to 86.178.124.128[500] (724 bytes) Apr 7 09:31:51 charon 11[ENC] <21> parsed ID_PROT request 0 [ SA V V V V V V ] Apr 7 09:31:51 charon 11[IKE] <21> received NAT-T (RFC 3947) vendor ID Apr 7 09:31:51 charon 11[IKE] <21> received draft-ietf-ipsec-nat-t-ike-02 vendor ID Apr 7 09:31:51 charon 11[IKE] <21> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID Apr 7 09:31:51 charon 11[IKE] <21> received draft-ietf-ipsec-nat-t-ike-00 vendor ID Apr 7 09:31:51 charon 11[IKE] <21> received FRAGMENTATION vendor ID Apr 7 09:31:51 charon 11[IKE] <21> received DPD vendor ID Apr 7 09:31:51 charon 11[IKE] <21> 192.168.1.33 is initiating a Main Mode IKE_SA Apr 7 09:31:51 charon 11[CFG] <21> received proposals: IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:AES_CBC_128/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024, IKE:AES_CBC_128/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:3DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024 Apr 7 09:31:51 charon 11[CFG] <21> configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 Apr 7 09:31:51 charon 11[IKE] <21> no proposal found Apr 7 09:31:51 charon 11[ENC] <21> generating INFORMATIONAL_V1 request 319277664 [ N(NO_PROP) ] Apr 7 09:31:51 charon 11[NET] <21> sending packet: from 86.178.124.128[500] to 192.168.1.33[500] (56 bytes) Apr 7 09:31:55 charon 11[NET] <22> received packet: from 192.168.1.33[500] to 86.178.124.128[500] (724 bytes) Apr 7 09:31:55 charon 11[ENC] <22> parsed ID_PROT request 0 [ SA V V V V V V ] Apr 7 09:31:55 charon 11[IKE] <22> received NAT-T (RFC 3947) vendor ID Apr 7 09:31:55 charon 11[IKE] <22> received draft-ietf-ipsec-nat-t-ike-02 vendor ID Apr 7 09:31:55 charon 11[IKE] <22> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID Apr 7 09:31:55 charon 11[IKE] <22> received draft-ietf-ipsec-nat-t-ike-00 vendor ID Apr 7 09:31:55 charon 11[IKE] <22> received FRAGMENTATION vendor ID Apr 7 09:31:55 charon 11[IKE] <22> received DPD vendor ID Apr 7 09:31:55 charon 11[IKE] <22> 192.168.1.33 is initiating a Main Mode IKE_SA Apr 7 09:31:55 charon 11[CFG] <22> received proposals: IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:AES_CBC_128/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024, IKE:AES_CBC_128/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:3DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024 Apr 7 09:31:55 charon 11[CFG] <22> configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 Apr 7 09:31:55 charon 11[IKE] <22> no proposal found Apr 7 09:31:55 charon 11[ENC] <22> generating INFORMATIONAL_V1 request 914008803 [ N(NO_PROP) ] Apr 7 09:31:55 charon 11[NET] <22> sending packet: from 86.178.124.128[500] to 192.168.1.33[500] (56 bytes) Apr 7 09:31:58 charon 11[NET] <23> received packet: from 192.168.1.33[500] to 86.178.124.128[500] (724 bytes) Apr 7 09:31:58 charon 11[ENC] <23> parsed ID_PROT request 0 [ SA V V V V V V ] Apr 7 09:31:58 charon 11[IKE] <23> received NAT-T (RFC 3947) vendor ID Apr 7 09:31:58 charon 11[IKE] <23> received draft-ietf-ipsec-nat-t-ike-02 vendor ID Apr 7 09:31:58 charon 11[IKE] <23> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID Apr 7 09:31:58 charon 11[IKE] <23> received draft-ietf-ipsec-nat-t-ike-00 vendor ID Apr 7 09:31:58 charon 11[IKE] <23> received FRAGMENTATION vendor ID Apr 7 09:31:58 charon 11[IKE] <23> received DPD vendor ID Apr 7 09:31:58 charon 11[IKE] <23> 192.168.1.33 is initiating a Main Mode IKE_SA Apr 7 09:31:58 charon 11[CFG] <23> received proposals: IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:AES_CBC_128/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024, IKE:AES_CBC_128/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:3DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024 Apr 7 09:31:58 charon 11[CFG] <23> configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 Apr 7 09:31:58 charon 11[IKE] <23> no proposal found Apr 7 09:31:58 charon 11[ENC] <23> generating INFORMATIONAL_V1 request 3324214621 [ N(NO_PROP) ] Apr 7 09:31:58 charon 11[NET] <23> sending packet: from 86.178.124.128[500] to 192.168.1.33[500] (56 bytes)