Not sure why that might be. Does it go up if you increase the timeout?

The timeout may just be a 'maximum' and rekeying earlier is actually better (more secure) than letting the keys fully expire.

We don't set a data timeout or I'd suspect it might be triggering another limit.

What shows up in the logs when it expires?

no, personally i don't think you have to worry, it's just like saying i hang my stuff 30 feet high so no one could reach it (under normal circumstances, before someone tells me, yes, but if..) and then saying it would be more secure to hang it 35 feet high.

openvpn has no flaws like lets say pptp with it´s weak password hashing or poor encryption keys..

to me it would be fine if everybody (universities, big networking companies, OS-Providers, etc..) would do SSL-VPN's as their standards, but unfortunately they don't. i.e. of iPhones which don't support installing third party devices (tun, tap) you don't have much choice, or if you have to connecting to third-party-vendor-stuff…

it depends, on implementation (i heard, IPSec with NAT-T is too not an ace either), on technology being used, on the usecase, on so many things.. but i'm glad that pfsense does them all.

Hi jimp,

Yup I fully understand :)

What I'm trying to prevent, is that compramised remote endpoint gaining access to some of my hosts that only other IPSEC tunnels have access to. It boils down to the fact that IPSEC is firewalled by one interface, and all filtering is done by IP. But if you say that it's impossible to pass traffic for a different subnet than a tunnel is configured for, unless both end agree to it, I guess this is safe enough (As my box would need compramised as well).

Thanks

It depends on how sensitive the transfer type is to failure, and how long the renegotiation takes.

If it's a quick renegotiation, and it drops a couple TCP packets, it should pick back up.

I don't think there is a fix for this in 1.2.x

In 2.0 it's a moot point since you can have multiple phase 2 networks in a single tunnel so they'd have the same name anyhow.

Sorry about the lack of ipsec logs, but IPsec seems to be fine now and I'm nowhere near the computers in question.

I've made some progress with this on other computers, but I haven't got it to work yet.  I followed the tutorial in http://www.pfsense.org/mirror.php?section=tutorials/mobile_ipsec/ on two fresh installs of pfsense and two systemrescuecds running as clients.  I've got a VPN tunnel (SAs, SADs and SPDs OK) established between the two pfsenses, but the traffic can only go from the dynamic site to the static site and not in reverse.

If I ping the static client from the dynamic client, I can see the ping echo requests arriving on the static client (tcpdump icmp), and I can see it trying to send replies.  I've set logging on the both firewalls, and I can see the ping reply arriving on the LAN interface of the static pfsense – but nothing is getting back to the dynamic client.  Pinging from the static client goes nowhere.

Also, when the static side times out the VPN connection, it refuses to allow the dynamic side to reestablish it (without me rebooting it).  The dynamic side says 'none message must be encrypted' in the ipsec.log.

Sorry for changing the subject, but it seems to be closer to a working solution.

@jimp:

That isn't a bug. The time zone will never take full effect system-wide until you reboot.

No problem jimp

Cheers

Hi Jimp,

i got it to work with Pfsense 1.2.3. After some debugging we corrected Phase 2 remote network settings.

Tunnel is up and working like a charm.

cya

:CLOSED

Thanks for the replies.

I'm guessing that the PSK is used for authentication only?

So, for example, once identity has been verified, the VPN 'security' would be identical if I was using RSA keys?

Thanks

Oh well, thanks for the effort jimp - very much appreciated.

thx for reply

my environment is in  vmware. i started four virtual server. the two is pfsense, another two is client.  the network of pfsense is bridged and customed .

i found it have a tunnel device named by enc0.
my config is follow:
VPN: IPsec: Edit tunnel

Mode Tunnel tunnel
Interface  WAN
DPD interval  seconds
Local subnet Type:    LAN subnet
Remote subnet  192.168.2.0/ 24
Remote gateway  10.48.255.252

Phase 1 proposal (Authentication)
Negotiation mode  main

My identifier  My IP address 
Encryption algorithm  AES-256
Must match the setting chosen on the remote side. 
Hash algorithm  SHA1
Must match the setting chosen on the remote side. 
DH key group 2
1 = 768 bit, 2 = 1024 bit, 5 = 1536 bit
Must match the setting chosen on the remote side. 
Lifetime  28800 seconds
Authentication method  Pre-shared key
Must match the setting chosen on the remote side.
Pre-Shared Key  xxxxxxx

Phase 2 proposal (SA/Key Exchange)
Protocol  ESP
ESP is encryption, AH is authentication only 
Encryption algorithms 
AES-256

Hint: use 3DES for best compatibility or if you have a hardware crypto accelerator card. Blowfish is usually the fastest in software encryption. 
Hash algorithms  SHA1

PFS key group  2
1 = 768 bit, 2 = 1024 bit, 5 = 1536 bit
Lifetime  seconds

other server:
VPN: IPsec: Edit tunnel

Mode Tunnel tunnel
Interface  WAN
DPD interval  seconds
Local subnet Type:    LAN subnet
Remote subnet  192.168.0.0/ 24
Remote gateway  10.48.255.251

Phase 1 and Phase 2 as same as the first host.

There is no real error in that log. There is also no connection attempt.

If you try to ping 192.168.2.104 from 192.168.0.55 (or vice versa) then it will try to initiate the tunnel.

Thanks for replies.
The problem is definitely related to MTU size and PPPoE connection. As in other offices we've got ADSL/SDSL lines with PPPoA connection and these work fine. I track this down by using ping command:
ping -f -l 1472 192.168.6.10
I end up with MTU size 1370. I think that will do for me by now. Anyway I'll try to check with my ISP to change the connection type.
Thanks again.

That's not so surprising given the speeds you're working with. VPN encryption is quite CPU-intensive.

You might also try CAST 128.

I dont see why not.
With such a big amount of connections RAM might be something to look into.
You will have to increase the default statetable size of 10'000 to something bigger.
Estimated you need 1kb of RAM for each connection.
With 2GB of RAM you can safely set the table to 1'000'000 ~ 1'500'000

CPU wise the number of connections has a smaller impact than how much bandwidth you want to push.
What are you expecting?

Well how is it that I can ping well over ethernet's 1500 MTU with a strongSWAN–strongSWAN IPSec tunnel?

seank@mob-sean:/work/workspaceCDT/FreeEMS/freeems-vanilla$ ping -s 8000 192.168.20.1
PING 192.168.20.1 (192.168.20.1) 8000(8028) bytes of data.
8008 bytes from 192.168.20.1: icmp_seq=1 ttl=63 time=58.1 ms
8008 bytes from 192.168.20.1: icmp_seq=2 ttl=63 time=44.3 ms
8008 bytes from 192.168.20.1: icmp_seq=3 ttl=63 time=30.9 ms
8008 bytes from 192.168.20.1: icmp_seq=4 ttl=63 time=31.1 ms
8008 bytes from 192.168.20.1: icmp_seq=5 ttl=63 time=28.6 ms
^C
--- 192.168.20.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 28.623/38.642/58.148/11.205 ms
seank@mob-sean:/work/workspaceCDT/FreeEMS/freeems-vanilla$ ping -s 8000 192.168.5.1
PING 192.168.5.1 (192.168.5.1) 8000(8028) bytes of data.
^C
--- 192.168.5.1 ping statistics ---
19 packets transmitted, 0 received, 100% packet loss, time 18142ms
?
Thx!
Sean

Not right from the CLI out-of-the-box, but if you look at the code in the IPsec pages and vpn.inc you might be able to hack something together. You'd have to disable it in the config, and then trigger a reload of the tunnel.

Any updates to this? I'm about to go back to my Linux/StrongSWAN based firewall.