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)

No, you can't give any fixed/predictable address to clients with mobile IPsec at this time. It's simple to do with OpenVPN though.

@TheSec: In my opinion you are already using the best option available. Because i think that if you would try to consolidate this one a few hosts that the firewall rules alone will give you nightmares  to never sleep from. Side from alle the other config elements you have to manage on that box. Also how would you handel downtime. Then you would have a get permission from more then one client. I think it who'll be better to have 75 or more pfsense boxes running then a few with a lot of connections. because you have to keep things separated, what beter way then you are already doing. If you really want to switch things up have a look at docker / ansible or puppet. Make a template that you just have to put in the unknown var's and the rest gets build automatically. then you can also test if new versions of pfSense break stuff ;) Hope it helps ;) TheSec. Not the answer I was hoping for, but you bring up some really good points.  It is definitely easier to troubleshoot and to do maintenance when I'm working on one client it doesn't affect anyone else.  And my rules are fairly simple per client.

Thank you for your reply. For site-site VPNs, I definitely see the value of DPD.  Disabling DPD for client-site VPNs is an interesting thought, but that alone doesn't sound like it will address what I am hoping to achieve through GUI configuration only.

I would find this option useful as well, to be able to set connection inactivity configuration.

Hi together! Sorry for reactivating this topic, but actually I'm running in the same issue as ronicontora. I know this post is old, but I'm wondering a bit that this is still the case in the actual release. As far as I know there is no option in the BIND section to map a specific IP or Virtual IP for Zone transfers. It is possible to map an interface for incoming requests but it seems that it's still not using his own LAN interface to connect to other BIND servers. Is there still no possibility or am I totaly wrong? My setup is nearly the same as on the initial post, just with other network ranges which are connected over IPSEC tunnel. Sorry but my english is not the best atm. Thanks in advance for all hints. Best regards

I have Same problem, with same config. there is connection but no traffic. Is there anybody who solved this problem?

Also, just noticed I put 4 cents a month.  It's 4cents an hour.  I'm editing my original post.

That worked! Thanks :)

Should this be moved to 2.4 development snapshots forum (is this regression thing? as it seems that people are using IKEv2 for site-to-site 24/7 tunnels, so this should work unless i have made a mistale somwhere (that i cannot find))? Added https://redmine.pfsense.org/issues/7439