It is possible to do this.

Probably the easiest way is to ensure that you have resolvable DNS hostnames for each public facing endpoint interface. I use a DynamicDNS provider with pfSense. Get this working first.

Don't use any public IP addresses in your Phase 1 config unless they are static IP addresses. Use the DynamicDNS hostnames instead.

E.g. on one end…

Remote Gateway: farfaraway.dynamic.dns
My Identifier: Distinguished Name: thisbox.dynamic.dns
Peer Identifier: Distinguished Name: farfaraway.dynamic.dns
Pre-Shared Key: OurSecret

on the other end...

Remote Gateway: thisbox.dynamic.dns
My Identifier: Distinguished Name: farfaraway.dynamic.dns
Peer Identifier: Distinguished Name: thisbox.dynamic.dns
Pre-Shared Key: OurSecret

The Phase 2 configs will have the IP network addresses of your internal network, typically private addresses. No dynamic dns required here.

cmb,

Is there a current howto for setting up a site-to-site IPsec VPN using RSA certs on pfSense 2.2.3?

I found my own way of doing this by experimentation and it's been working fine up to 2.2.2 but it I cant get certs to work on 2.2.3 . PSK works OK.

I wondered if the problems I have with certs not working on 2.2.3 is actually a misconfiguration that didn't cause a problem in earlier releases.

All 3 actually. The one on site A has to know to go via EC2 to reach site B, same in reverse for site B, and the EC2 instance needs both setup so each site will work.

I am having the same problem with 2.2.2. I have IPSEC enabled. Disabling IPSEC, and trying to remove all IPSEC firewall rules, did not fix the problem. I am not using IPSEC at this point.

Hello community,

we resolved this issue with help from the pfSense support.

First of Steve pointed out that our LAN and VLAN10 interfaces were on the same subnet which may cause problems, thus we removed the VLAN10 from our bonded interface to be on the safe side.

The actual problem was caused by firewall rules blocking access to RFC1918 subnets from the local VLANs to our remote networks.

We had a pass rule for the remote subnets, but this rule was on the wrong interface group. We enabled logging on every block/reject rule that we had in place and those packets appeared as rejected by another interface group's reject-rule. Moving the pass-rules to the correct interface group fixed the issue.

Kind regards

There are either issues in vpnc when connecting to strongswan, or in strongswan itself. Configs that work fine with the built-in IPsec client in iOS and OS X, Shrewsoft, and others fail with vpnc where it should function the same as the others. My gut feel is it's a vpnc issue of some sort that racoon just didn't trigger for some reason, given all the other similar clients work fine in the same circumstance. There are a number of instances of people using vpnc with strongswan, though many of those date back quite some time. I updated the bug ticket and will revisit as soon as time permits (in the process of getting 2.2.3 to release this week).
https://redmine.pfsense.org/issues/4784

@cmb:

The issue was this:
https://redmine.pfsense.org/issues/4781

it works now. I applied that change to the 2.2.3 system you brought up, and can connect fine now. If you can confirm as well that'd be appreciated.

Thanks for your help!

I'll check this afternoon when I make it back to a location I can check it from. Thanks, cmb!

Well I'll wait till 2.2.3 is released as a stable version then :)

Yes.

You can use IPSec for mobile cleints, and works perfectly :)

What do your IPsec logs show at the time? What's the router you're connecting to?

Your logs show it's up, so should be safe to assume everything at the IPsec level is correct. Maybe missing firewall rule to allow traffic in on IPsec tab. Maybe a host issue, like having a wrong subnet mask, or a local firewall that's dropping the traffic.

@ermal:

You should start by loading AESNI module.

In pfSense 2.2.x surely its confirmed you can get 800Mbit/s with lower boxes with AES-GCM.
In 2.3 its improved a bit more.

Can you please post your numbers and what ipsec configuration you are using?

Re-testing with AES-128 and I can see that computer #1 (the less powerful of the 2 pfsense computers) is showing much higher loads on the interrupt than on the first snapshots taken, seems like the interrupt is ranging between 70-90% of utilization

computer1.jpg
computer1.jpg_thumb
dashboard1.jpg
dashboard1.jpg_thumb
dashboard2.jpg
dashboard2.jpg_thumb

Hello to all, we have fixed the problem. It was due to another VPN active with same subnets. We changed networks and all is working perfectly now!

Anyone?

Finally back from vacation and back to my IPsec issue  ;)

@ermal:

Probably should try disable the unity plugin!

Sorry, but I can't see that setting on the IPsec tab. Where should it be?

I verified that while status did not show connected, I was able to pass traffic and then the status updated to reflect 2 subnets.

I end up doing it myself.

Read a little of php, touching here and there on a test enviroment and voila.

Being testing a few protocols and ports and seems to be ok.

No idea how to make a pull request, but i've left the modified files attached to this post just in case someone needs them.

ipsec_status.JPG
ipsec_status.JPG_thumb
vpn_ph2.JPG
vpn_ph2.JPG_thumb
protoport.zip