Answered my own question.  Below groups are effective permissions, you can add the permission to that for IPSEC Xauth dialin.

Hey, I eventually (this friday) gave up. I even tried running openVPN on the USG directly (command line) which worked but the transfer speed was abyssmal slow. I installed a tiny Intel NUC (12 Watt) that does OpenVPN just fine with the pfsense. Even with double-Nat :) -Chris.

Thanks for the reply! I'm checking those tabs, and I only see the remote public IP, not the local IP that the client is receiving from pfsense. The scenario is, I'm rolling this out to a company of multiple users, and I would like to be able to identify each client on the router, but it seems like that info is obfuscated from me at this point. Appreciate your help!

One more part – Feb 7 14:07:00 charon 13[NET] <con1000|3>sending packet: from 172.16.200.20[500] to xxx.xxxx.xxx.x[500] (180 bytes) Feb 7 14:07:00 charon 13[NET] <con1000|3>received packet: from xxx.xxx.xxx.x[500] to 172.16.200.20[500] (160 bytes) Feb 7 14:07:00 charon 13[ENC] <con1000|3>parsed ID_PROT response 0 [ SA V V V V ] Feb 7 14:07:00 charon 13[IKE] <con1000|3>received XAuth vendor ID Feb 7 14:07:00 charon 13[IKE] <con1000|3>received DPD vendor ID Feb 7 14:07:00 charon 13[IKE] <con1000|3>received FRAGMENTATION vendor ID Feb 7 14:07:00 charon 13[IKE] <con1000|3>received NAT-T (RFC 3947) vendor ID Feb 7 14:07:00 charon 13[ENC] <con1000|3>generating ID_PROT request 0 [ KE No NAT-D NAT-D ] Feb 7 14:07:00 charon 13[NET] <con1000|3>sending packet: from 172.16.200.20[500] to xxx.xxxx.xxx.x[500] (244 bytes) Feb 7 14:07:00 charon 13[NET] <con1000|3>received packet: from xxx.xxx.xxx.x[500] to 172.16.200.20[500] (244 bytes) Feb 7 14:07:00 charon 13[ENC] <con1000|3>parsed ID_PROT response 0 [ KE No NAT-D NAT-D ] Feb 7 14:07:00 charon 13[IKE] <con1000|3>local host is behind NAT, sending keep alives Feb 7 14:07:00 charon 13[ENC] <con1000|3>generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ] Feb 7 14:07:00 charon 13[NET] <con1000|3>sending packet: from 172.16.200.20[4500] to xxx.xxx.xxx.x[4500] (108 bytes) Feb 7 14:07:01 charon 13[NET] <con1000|3>received packet: from xxx.xxx.xxx.x[4500] to 172.16.200.20[4500] (92 bytes) Feb 7 14:07:01 charon 13[ENC] <con1000|3>parsed INFORMATIONAL_V1 request 907020096 [ HASH N(AUTH_FAILED) ] Feb 7 14:07:01 charon 13[IKE] <con1000|3>received AUTHENTICATION_FAILED error notify Feb 7 14:09:19 charon 00[DMN] signal of type SIGINT received. Shutting down</con1000|3></con1000|3></con1000|3></con1000|3></con1000|3></con1000|3></con1000|3></con1000|3></con1000|3></con1000|3></con1000|3></con1000|3></con1000|3></con1000|3></con1000|3></con1000|3></con1000|3>

What do you mean NAT? Based on this: access-list acl-vpn-NJB permit ip host 172.17.0.254 172.17.7.0 0.0.0.255 access-list acl-vpn-NJB permit ip host 172.17.0.4 172.17.7.0 0.0.0.255 access-list acl-vpn-NJB permit ip host 172.17.0.51 172.17.7.0 0.0.0.255 You would make three phase 2 tunnel entries: Local Network: Network: 172.17.7.0 /24 Remote Network: Address: 172.17.0.254 Local Network: Network: 172.17.7.0 /24 Remote Network: Address: 172.17.0.4 Local Network: Network: 172.17.7.0 /24 Remote Network: Address: 172.17.0.51

Ok I think I found a solutions. Somehow my HTTP(s) got dropped when using SHA512/AES256 to the Mikrotik box. When I use SHA1 and AES128 http(s) requests works fine and I am able to access the webconfigurator. Spend a lot of time finding this out, because only http(s) connections got dropped somehow.

In Status > Interfaces you will see the second interface. That is the internal interface (lan). It does not matter what the interface description is.

Not quite an answer to your question, but I'm watching this thread with curiosity. First of all, if you want to use AES you should activate it (in pfSense Advanced-Misc-Cryptographic hardware) My very limited experience with AES-NI (I just installed the proper hardware 2 days ago and am still running tests) is that with AES crypto active and using AES-GCM128 it doesn't actually push a lot more data thorough, but it does let the CPU breath for other stuff. In other words, before I had AES-NI the router became unresponsive during large transfers, but  in the end the transfer went through through sheer CPU-power. Right now, with AES-NI, the transfer is slower (even with a much faster CPU!!!) but the router stays 100% responsive to everything (SNNP, run of the mill routing, etc) - the CPU actually hovers at 3% usage during transfer, as reported by the pfSense dashboard. It used to hit 90%+ on the older non-AES-NI hardware. I have no idea if this is what to expect (and if so, it's disappointing, I wanted faster transfer). I don't want to hijack your thread but additional hints and tips would be welcomed and would probably help you too.

You'll either need to add a rule for ICMP or change the top protocol to any if you want pings to work as per Derelicts post. Status -> System Logs -> Firewall -> Normal View if you click on the + it will add a rule if your not sure.

Same question here again. Is there a definitive "No, it doesn't work" yet?

I have a question…do you mean OPENVPN or IPSEC on a LAN gateway so like two different subnets? For example: 172.16.0.1/24 192.168.0.1/24 ...?  Tell us more about your config.

Just to provide some more detailed information. After the VPN is connected as described, both from the pfSense server console and from any client in the LAN 10.0.0.0/24 I can access the Internet, being able to ping both the Zywall interface to which the pfSense WAN belongs (192.168.0.254) and any other site, such as google.it. But when I try to ping one IP of the remote VPN side (172.16.16.122 for example), this does not work. I managed to have this ping to the remove VPN client working only from within the pfSense console, after changing the "Local Network" settings in the IKE Phase 2 configuration, from "Local subnet" to "Network" with address "0.0.0.0/0". It looks like there are still some kind of firewall issues preventing an IP in the subnet 10.0.0.0/24 to properly communicate throught he VPN. I've already firewall rules completely open for WAN, LAN and IPSec. I've also noticed that there is an Automatic Outbound NAT generated, from the LAN subnet to the WAN IP of the pfSense (192.168.0.51). What am I missing to have client-to-client VPN communication in place? Maybe some kind of port forwarding from the WAN to the LAN, for the IPSec ports?

If you use IP Alias type (probably what you want) you should use the interface subnet. If you use CARP type (not sure why you would) you should use the interface subnet. You cannot use Proxy ARP or Other because you cannot bind services on the firewall (like IPsec) to them.