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.

@Neferites because ipsec is not Nat-t enabled on pfsense 1.2.3  try openvpn

Heres my working config: local subnet is the local subnet on the fw your on remote is the subnet you want to access at the other end for remote gateway put in a ddns identifier is my ip address, leave blank do a pre-shared key, must be the same on both fw's keep alive-set this to the fw at the other end all other options: set them the same at both ends

I assume what you are asking is if you can set it up behind the Linksys router and the Linksys router is being NATed. I have done this previously but the device was a Linksys router with VPN capabilities behind a DSL modem that was NATting the traffic. It worked but not reliably. I have used the same Linksys vpn router when not behind a NAT and it does work reliably. If you can manage the network I would suggest using your pfSense box for the main router and then turn off the routing capabilities of the Linksys router and just let it continue to be an access point.

Sure, just follow the suggestion on this page: http://doc.pfsense.org/index.php/Why_can%27t_I_query_SNMP,_use_syslog,_NTP,_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN%3F

Try using a different encryption method such as AES-128 which would be faster than 3DES. Are you also monitoring the CPU and such on the ASA? I wouldn't think that little of traffic would tax it though. It may also be the protocol you are using. Some things might be fast, such as http downloads, while others would be slow (SMBv1 windows shares).

There are two actual possible places to disable the ipsec service from starting  and I am sure there is a reason for this. The general one disables IPsec completely for all tunnels. The disable checkbox that you had checked in the config for the actual tunnels is to disable one tunnel while leaving others enabled.

Use 1.2.3 everywhere. Many of those issues have been solved over time.

It worked. I made the second IPsec Tunnel added some rules and works grate! Thank a lot.