IPsec pfSense 2.2 to 2.1.5 failing
-
I can confirm that connecting a pfSense 2.2 IPsec with a IPsec 2.1.5 node does not work for me too. My setup is quite simple: connecting two locations and for testing a additional connection from my home network. A possible problem may be that all locations are NATted but this is not a problem for two 2.2 or two 2.1.5 connections. Besides I am using Negotiation mode 'main', AES256, SHA256 and 2048 key length. Testing between two virtual machines does not work either. So if someone has a solution?
(BTW why do you guys use those F********* captcha's for a simple post?)
-
Split this to its own thread as it's unlikely the same as the other and keeping one issue per thread helps us follow up.
I can confirm that connecting a pfSense 2.2 IPsec with a IPsec 2.1.5 node does not work for me too. My setup is quite simple: connecting two locations and for testing a additional connection from my home network. A possible problem may be that all locations are NATted but this is not a problem for two 2.2 or two 2.1.5 connections. Besides I am using Negotiation mode 'main', AES256, SHA256 and 2048 key length. Testing between two virtual machines does not work either. So if someone has a solution?
By "all locations are NATed", you mean the WANs are private IPs, or?
Does the connection establish but not pass traffic, or not establish at all, or?
(BTW why do you guys use those F********* captcha's for a simple post?)
Only your first post. Because, spammers.
-
@cmb:
Split this to its own thread as it's unlikely the same as the other and keeping one issue per thread helps us follow up.
I can confirm that connecting a pfSense 2.2 IPsec with a IPsec 2.1.5 node does not work for me too. My setup is quite simple: connecting two locations and for testing a additional connection from my home network. A possible problem may be that all locations are NATted but this is not a problem for two 2.2 or two 2.1.5 connections. Besides I am using Negotiation mode 'main', AES256, SHA256 and 2048 key length. Testing between two virtual machines does not work either. So if someone has a solution?
By "all locations are NATed", you mean the WANs are private IPs, or?
Does the connection establish but not pass traffic, or not establish at all, or?
On both locations the pfSense node connects to a ADSL modem with NAT enabled. As far I can see the connection is not established.
A selection from my logs:racoon: INFO: unsupported PF_KEY message REGISTER racoon: [SiteA]: INFO: IPsec-SA request for x.x.x.x queued due to no phase1 found. racoon: [SiteA]: INFO: initiate new phase 1 negotiation: x.x.x.x[500]<=>x.x.x.x[500] racoon: [SiteA]: [x.x.x.x] INFO: Selected NAT-T version: RFC 3947 racoon: INFO: NAT detected: ME PEER racoon: [SiteA]: INFO: KA list add: x.x.x.x[4500]->x.x.x.x[4500] racoon: ERROR: ignore information because ISAKMP-SA has not been established yet. -
How are your phase 1 identifiers configured?
One relevant change in behavior we've seen is racoon didn't seem to care whether the ID it was sent matched if it had a match for the IP where the traffic was actually being originated. So for instance if you have the remote end behind NAT set to use "My IP Address" for its identifier, it puts the private WAN IP in there as its identifier. racoon would still find it by matching the IP where the request was initiated (probably technically incorrect). But strongswan has to find a match to the ID being sent by the other side, it won't fall back to "eh, you're coming from X IP and I have a match there, so that's good enough."
-
@cmb:
How are your phase 1 identifiers configured?
One relevant change in behavior we've seen is racoon didn't seem to care whether the ID it was sent matched if it had a match for the IP where the traffic was actually being originated. So for instance if you have the remote end behind NAT set to use "My IP Address" for its identifier, it puts the private WAN IP in there as its identifier. racoon would still find it by matching the IP where the request was initiated (probably technically incorrect). But strongswan has to find a match to the ID being sent by the other side, it won't fall back to "eh, you're coming from X IP and I have a match there, so that's good enough."
That could be the problem indeed. Although it works with two 2.2. nodes and two 2.1.5 nodes. I tried Distinguished name and User distinguished name but racoon wants a IP address in 'main' mode accordding to the logs. So as a last resort I used the IP addresses and this works! Not wat I like because IP adresses changes more often than FQDN but for the moment it works. Thank you!
-
You don't actually have to use the public IP it's using, for that case behind NAT you could let it use its private WAN IP as the ID. Just make sure both ends are set to match accordingly for that private IP.