IPSEC works only one time after activating it?!
-
Is there a chance of a lifetime mismatch between both ends? I have seen things like this happening if one end was still having an old SAD while the other end's SAD already had expired and a new one was generated.
Btw, I have several installs with dynamic to static IPSEC tunnels out that work just fine (I also did that "old" tutorial ;) ).
-
No - the configured values for the lifetime at phase1/2 are exactly the same. But … other than mentioned in the pfsense tutorial (where both values are set to 1200), i'd set up the values in Phase1 to 28800 and Phase2 to 86400. My first IPSec configuration years ago was based on a m0n0 environment, and the docs there (http://doc.m0n0.ch/handbook/ipsec-tunnels.html) suggest to do like this:
Phase 1:
Lifetime: This field is far more important then it appears. This lifetime, as opposed to the one in phase 2, is how long your end will wait for phase 1 to be completed. I suggest using 28800 in this field.
Phase 2:
Lifetime: This is the lifetime the negotiated keys will be valid for. Do not set this to too high of a number. E.g. more than about a day (86400) as doing so will give people more time to crack your key. Don’t be over paranoid either; there is no need to set this to 20 minutes or something like that. Honestly, one day is probably good.
At that time i only assume these values from the docs without really think about it. There was also no need for me cause it works. But if i think about it, may be it's better to make a phase1 lifetime about 60 and a phase 2 lifetime about 3600?
So what do you mean: Which values are practically for people with a AllDayChangingDynamicIPEnvironment like me?
-
I use an IPSEC Tunnel between Office and Home and have a VOIP-Phone running over this IPSEC. IF the tunnel get's disconnected I only see the voipphone displaying an Errormessage for less than half a minute. My lifetimes are 28800 (for both phases). Office is static SDSL, home is PPPoE ADSL2+ with 24h hour forced disconnects by the ISP (I hate german ISP's for doing this >:( ). Nevertheless it works fine.
-
I'd looked a bit around and found here (http://www.clavister.com/manuals/ver8.5x/manual/vpn/ipsec_basics.htm) a statement about the lifetime:
IKE Negotiation
The process of negotiating session parameters consists of a number of phases and modes. These are described in detail in the below sections.
The flow of events can be briefly described as follows:IKE Phase-1
Negotiate how IKE should be protectedIKE Phase-2
Negotiate how IPsec should be protected
Derive some fresh keying material from the key exchange in phase-1, to provide session keys to be used in the encryption and authentication of the VPN data flow
Both the IKE and the IPsec connections have limited lifetimes, described both as time (seconds), and data (kilobytes). These lifetimes prevent a connection from being used too long, which is desirable from a cryptanalysis perspective.
The IPsec lifetime is generally shorter than the IKE lifetime. This allows for the IPsec connection to be re-keyed simply by performing another phase-2 negotiation. There is no need to do another phase-1 negotiation until the IKE lifetime has expired.(and for those who it's easier to have somthing similar in german language: http://ipsec.gosecurity.ch/allgemeines/einf_ipsec.asp)
… which means that Phase1Lifetime has to be a bigger value than Phase2Lifetime! Maybe thats the problem (even if i don't understand why it's running without problems over years), so I will go to change that. I think I'll try it with the values Phase1 28800 and Phase2 3600, since I found no specific recommendation which values should normally or practically being used …
Cause I can't change these values now while all in company are working (and use the same IPSec configuration), I'll try to change it this evening on all m0n0/pfsense boxes including my own and report back next week!
I hate german ISP's for doing this
Jo - voll der Dreck. Ich hoff nicht mir noch AlwaysOn für 1,50€/Monat extra zulegen zu müssen um mein seltsames Problem zu lösen … ;D
-
@EmL:
I think I'll try it with the values Phase1 28800 and Phase2 3600, since I found no specific recommendation which values should normally or practically being used …
RFC 4308 [http://www.faqs.org/rfcs/rfc4308.html] recommends "standard" suites of security parameters, including ISAKMP SA (ie. phase 1) lifetime=86400 seconds and IPSEC SA (ie. phase 2) lifetime=28800 seconds.
-
Thx dusan for this information! However unfortunately the tunnel has the same problems with these highly official RFC values (comes also only 1-time up and then never again).
So i decided to kick pfsense back to factory state, set it up it again only with dhcp and ipsec - but after that i had the same problems!
Then i tried first time to switch my HomeOffice (dynamicIP) "My Identifier" in IPSec configuration to "Dynamic IP". Here the Tunnel comes never up and the System IPSec logs shows me an error:
Jan 7 18:56:14 racoon: INFO: @(#)ipsec-tools 0.6.6 (http://ipsec-tools.sourceforge.net)
Jan 7 18:56:14 racoon: INFO: @(#)This product linked OpenSSL 0.9.7e-p1 25 Oct 2004 (http://www.openssl.org/)
Jan 7 18:56:14 racoon: ERROR: /var/etc/racoon.conf:7: "d" parse error
Jan 7 18:56:14 racoon: ERROR: fatal parse failure (1 errors)Btw, if i think back to the good old times where my IPSec had made no problems, it'd worked for me great with the setting "Domain Name" at that time!
I tried also to come to a solution with a VPN via OpenVPN, but unfortunaly this is my first try with OpenVPN and so i'm was not able to set up a working environment as the tutorial shows on the pfsense homepage … even thoug it would be better it works only with IPSec like years ago.
But what i really dont understand, is that the tunnel comes up after after enable/disable IPSec completeley or save only the ipsec configuration page (without a change) and then apply the changes. Then the tunnel comes up (till IP changes again).
So - if after the WAN IP changes - the same things would be processed as i klick on the "apply" button - this would the solution for my problem, but i dont understand the different what's done in background, so that IPSec Phase 2 comes up in one case and in other not.
-
@EmL:
Thx dusan for this information! However unfortunately the tunnel has the same problems with these highly official RFC values (comes also only 1-time up and then never again).
So i decided to kick pfsense back to factory state, set it up it again only with dhcp and ipsec - but after that i had the same problems!
Then i tried first time to switch my HomeOffice (dynamicIP) "My Identifier" in IPSec configuration to "Dynamic IP". Here the Tunnel comes never up and the System IPSec logs shows me an error:
Jan 7 18:56:14 racoon: INFO: @(#)ipsec-tools 0.6.6 (http://ipsec-tools.sourceforge.net)
Jan 7 18:56:14 racoon: INFO: @(#)This product linked OpenSSL 0.9.7e-p1 25 Oct 2004 (http://www.openssl.org/)
Jan 7 18:56:14 racoon: ERROR: /var/etc/racoon.conf:7: "d" parse error
Jan 7 18:56:14 racoon: ERROR: fatal parse failure (1 errors)Btw, if i think back to the good old times where my IPSec had made no problems, it'd worked for me great with the setting "Domain Name" at that time!
I tried also to come to a solution with a VPN via OpenVPN, but unfortunaly this is my first try with OpenVPN and so i'm was not able to set up a working environment as the tutorial shows on the pfsense homepage … even thoug it would be better it works only with IPSec like years ago.
But what i really dont understand, is that the tunnel comes up after after enable/disable IPSec completeley or save only the ipsec configuration page (without a change) and then apply the changes. Then the tunnel comes up (till IP changes again).
So - if after the WAN IP changes - the same things would be processed as i klick on the "apply" button - this would the solution for my problem, but i dont understand the different what's done in background, so that IPSec Phase 2 comes up in one case and in other not.
What does line 7 of /var/etc/racoon.conf show? Thats what we really need to diagnose this.
Jan 7 18:56:14 racoon: ERROR: /var/etc/racoon.conf:7: "d" parse error
-
Line 7 looks (at least for me good?) like this - pfsense placed my actual IP instead of 111.111.111.111:
path pre_shared_key "/var/etc/psk.txt";
path certificate "/var/etc";
remote 222.222.222.222 {
exchange_mode aggressive;
my_identifier dyn_dns "111.111.111.111";peers_identifier address 222.222.222.222;
initial_contact on;
support_proxy on;
proposal_check obey;proposal {
encryption_algorithm 3des;
hash_algorithm md5;
authentication_method pre_shared_key;
dh_group 2;
lifetime time 86400 secs;
}
lifetime time 86400 secs;
}sainfo address 192.168.100.0/24 any address 192.168.1.0/24 any {
encryption_algorithm 3des;
authentication_algorithm hmac_md5;
compression_algorithm deflate;
pfs_group 2;
lifetime time 28800 secs;
} -
I'm not sure, but it seems strange that my_identifier is an IP address. As it is a dyn_dns id, it must be a FQDN eg. mysite.mydomain.com, isn't it?
-
First, it looks strange for me too. But the IP was the actual IP i had at this time synced with my DynDNS Account. But something is going wrong in this special case cause i got the errormessage in log.
But, as i wrote: it hade made no problems without the setting "Dynamic DNS" over a year using "Domain Name" before on other machine than the wrap.
-
Well, using 'Domain name' is the only option for me to get it working. Dunno why.
I can connect since I reinstalled pfSense last night and setup the tunnel from scratch.
But "user@FQDN" or "IP address" as identifiers respond with 'parse error' in the logs. I think I can enter an eMail address or an IP on both sides without accidents, though. 8)One other thing caught my attention:
I have allow rules with logging for ESP, AH and UDP500 on the WAN IF. No TCP500.
On connection the log shows an accept from TCP500 stating the above UDP500 rule as trigger.
ESP is logged fine (and I don't use AH).Any ideas?
-
Another wild guess:
Did you check that you did not swap static and dynamic ends when creating the rule set?
This would work as long as the connection is up but gets lost after 24h DSL-hiccups.This might happen easily when working on both ends simultaneously as they look pretty similar… (been there, done that)
-
Hi,
thx jahonix for your reply … after beeing a while away i'd made now some tests with a laptop. I used the live cd and had made a installation on hd.:
Well, using 'Domain name' is the only option for me to get it working. Dunno why.
Same for me. "Dynamic DNS" as option in VPN seems to be buggy … only "Domain name" is working!
Did you check that you did not swap static and dynamic ends when creating the rule set?
No this is also definitely impossible. I saved my configuration from the wrap box, adjustet the interface names for wan and lan, and restored it on the test laptop. Without a change it works immediately there!?!?
Now i can disconnect and connect, the Tunnel comes up as expectet - as many times i tried it. Also after a reboot its no problem anymore!
Does anybody know if there are any known bugs with the embedded image?
-
Try reflashing the wrap with the latest snapshot and upload the working config. I use lots of wraps, also with ipsec. Haven not seen these problems before.
-
Unfortunaly i have not the hardware at home to reflash and as i read in the forum it's sadly not possible to reflash using the GUI. But i think now i know the reason why its not working:
I have a Soekris VPN 1411 (hifn 7955 based chipset) MiniPCI card in my wrap. If i dismount it, it works fine as everybody would except it - reboots and ip changes are no problems anymore! I have also the same hardware running on different co-locations (dynamic) in a m0n0/freebsd4 environment, where the 1411 under freebsd4 is also recogniced as a crypto hardware and they all can also connect to the headquarter running a pc with pfsense (static).
I think something is missing/wrong with the implementation in the way how pfsense initializes or handles the VPN crypto hardware after the ip changes or after i reboot the wrap … cause if i only disable/enable IPSEC, the tunnel comes up and all is running till the next ip change! So if the same things would happen on reboot or ip change, this would may be the solution for my problem.
-
Endorsement: I buyed me a Cardreader and flashed the 1.0.1-SNAPSHOT-02-02-2007 built on Sat Feb 3 06:12:22 EST 2007 on my CF and restored the working config. Also there i got the same problems …
-
After it is certain that the error occurs only in combination with the VPN Crypto Card is there a chance to get a statement from the devs what could i do now? As i wrote the Crypto Card inherently works in a BSD4 Environment, so i think reason is not the card itself …
-
Sounds like a freebsd bug then. Search the appropriate lists for similiar problems or statements on this.
