Not and ISP issue, same hardware on two different providers behaves the same, also on the same provider. Different hardware on the same two different providers work without issue, also on the same provider. Quality of circuits is outstanding in all my remote locations. I'm using a hub spoke model, with a pair of Palo Alto 3000 series as the hub. Multiple spokes, all pfSense. Any pfsense running 2.2.2 has no issues (AES-256). All running 2.2.4 work fine except the pfsense official hardware firewall from the store. I have no issues other than with this one firewall hardware. All other factors I can remove, have been removed. CMB has I think all the details he's asked for, but I'm sure if he needs more he'll ask. And trust that I have nothing but respect for CMB and the team at ESF. I honestly believe that pfsense is the best platform for perimeter security out there, commercial or not. The only reason I use PAN as my hub is because of executive concerns around an open source platform doing all security between all subnets, local and remote. I'm just in an awkward position. I promised the CEO of the company that I would get him the best of the best, rather than what I usually build using spare parts, and I looked like an amateur after 2.2.2. All the technical reasons aside, he sees me handing him a black box that doesn't work as I told him it would. Meanwhile an old grinder under the desk supports 10-20 people on a regular basis and never blips. The only reason I bought the pfsense branded hardware was because I read these forums regularly, and I see pfsense experts brag all the time about their bulletproof hardware from the pfsense store. I wanted to be one of those too because quite frankly although I have good good success with old hardware, one day I'm sure that might end (given the end user problems on these forums). :) I'm grateful, honest! Cheers,

Hi Please see here: https://wiki.strongswan.org/issues/1062. It actually might work with the shipping 5.1.x binaries but I was already down the rabbit hole. Try this: Edit the /etc/NetworkManager/VPN/nm-strongswan-service.name file and under [GNOME] add "supports-external-ui-mode=true" without quotes. Create your connection using Network Connections in the NetworkManager applet. Invoke the connection and the save password dialog should popup. Otherwise follow the directions in the link above to build the package from source. This is only affecting Debian distros like Ubuntu and Mint. I tried many things including some ln -s to various places. If this does not work for you post back and we can find out what links need to be made. /M

got it via /etc/devd.conf. if WAN-Interface goes down the ipsec restarts.

I have found the fix. Had to enable "Clear invalid DF bits instead of dropping the packets" in System > Advanced > Firewall/NAT.

The APU Board has 2gig RAM, i also used a board with 4GB, the RAM isn't the issue, the maximum RAM usage was about 20 %. :(

Hi, Is there any update on showing connected users via IPSEC on the dashboard? 2.2.4 Displays: Note: There are no configured IPsec Tunnels although they are working.

Disabled the service, tried to change the handshake for phase 1 to certificate, but couldn't get it to work. Changed it back to psk, changed encryption type to blowfish and DH to 5 from 2 (honestly, just because I was bored). Started the service back up, and it reconnected… holy crap, I hope I never have to come back to this forum again! Down with PFSENSE!

Means the remote end is trying to initiate a connection (hence the "responder" part), with settings that don't match what you have configured. If you're on 2.2.3 or newer, multiple P2 is fine.

Seems like 2.2.4 got even worse performance. The results is fluctuating and I'am not sure if AES-NI is even being used. Anyone got a working IPSEC setup using AES-NI? [root@test3 strongswan]# iperf -n 32M -c 10.75.0.1 -P 5 –---------------------------------------------------------- Client connecting to 10.75.0.1, TCP port 5001 TCP window size:  204 KByte (default) [  7] local 10.75.0.3 port 42604 connected with 10.75.0.1 port 5001 [  3] local 10.75.0.3 port 42600 connected with 10.75.0.1 port 5001 [  4] local 10.75.0.3 port 42601 connected with 10.75.0.1 port 5001 [  5] local 10.75.0.3 port 42602 connected with 10.75.0.1 port 5001 [  6] local 10.75.0.3 port 42603 connected with 10.75.0.1 port 5001 [ ID] Interval      Transfer    Bandwidth [  6]  0.0- 8.0 sec  32.0 MBytes  33.5 Mbits/sec [  7]  0.0-17.2 sec  32.0 MBytes  15.6 Mbits/sec [  5]  0.0-20.0 sec  32.0 MBytes  13.4 Mbits/sec [  3]  0.0-25.6 sec  32.0 MBytes  10.5 Mbits/sec [  4]  0.0-26.5 sec  32.0 MBytes  10.1 Mbits/sec [SUM]  0.0-26.5 sec  160 MBytes  50.7 Mbits/sec Note: Have now discovered that "top" shows some load.. Idle interupt goes to zero and "nice" goes up: [image: top.png]

Thanks for that hint, I already did that and managed to get DHCP relay into the tunnel (without that workaround it refused to send the paket into the tunnel and showed up something like 'no route to host' in DHCP-logs). With the route from the workaround you suggested I managed to get the request out to the DHCP server, but it refuses to re-enter the pfSense it originated from. As a workaround for this I took another pfSense behind the pfSense (which was intended to to the relay in the first place) as LAN-B-client-only doing the relay instead of pfSense2. This worked without any problems. It's just the need of a third machine doing the relay since it refuses to work on the same one that is the end of an IPsec tunnel. @cmb: […]it's probably not a great idea to rely on a remote site over VPN for your DHCP, unless in a scenario where that entire network is dead anyway if the remote site is unavailable. I totally agree; that's what I'm thinking too, however I'm being told to get this working exactly this way, no matter what problems it brings. Thanks for your help ^.^