The MAC of your machine is only locally-significant. Your traffic from the VPN, when it gets to your LAN, is sourced from the LAN NIC MAC of the firewall. Allow its MAC (see Status>Interfaces).

OK Thanks; I will try that. Alfredo.

@dharrigan: Hi, Very similar. I've updated the bug report with the configuration I have, along with a log file of the connection attempt. -=david=- I had the exact same config.

You're sending traffic out, but the other side isn't replying. Likely the other side is blocking your requests, either on the Zywall, or on the destination host (host firewall).

I just disabled AES-NI and rebooted and it works for me as well.  We have dual redundant firewalls as they are production, so I will wait to update the second one entirely until 2.2.4 is ready.  I hope that is soon; disabling AES-NI seems to have a performance impact on our OpenVPN tunnel performance, as I suppose one should expect with AES-CBC. :P

Thanks for the help but I already figure out this problem.

@georgeman: Hi guys, let me outline some issues I have found with RSA IPsec, which I already debugged, found the cause, workarounds and reported the bugs  ;) georgeman, thank you, thank you, thank you! I did suspect it was a data matching problem, thanks for proving it.

https://redmine.pfsense.org/issues/4791

Thanks a lot Delict !!! rigth to the point. It works perfect now, the pfsense box can reach all the other sites subnets.

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!