hi jim, yes, 2.0 always latest snapshot, but i don't believe it has something to do with 2.0 especially, therefore i didn't post it there over.. i have tried to do mss clamping on vpn traffic (tried a few adjustments) around 1300 bytes. i tried before a few settings on wan's mtu around 1500 and mss clamping on wan around 1300-1350, letting space for around 150 bytes of overhead. but i don't know really if my thinking is right.. still, when i adjust the mtu of the ipsec client it does establish the connection and traffic passes through it. on the same line with i.e. osx or iphone client, it fails with logs posted above, even tried connecting through umts, no way. windows & linux clients working fine. tried to adjust clients lan interfaces mtu too, but that didn't helped neither, and seems to be bad practice.. i don't even know, if i'm talking absolute rubbish here, so given that, thank you for bearing with me.. ROOKIE AT WORK.

this warning  just means that random numbers are generated trough software and not trough a i.e. vpn-accelerator-card. but i don't think it has anything to do with your dropped tunnels, like XIII said, post your config and ipsec-logs…

try changing negotiation mode to aggressive.

IPsec doesn't route in that way, unless you're talking about IPsec in transport mode with something else like GRE on top. You'd have to setup IPsec with a remote network of 0.0.0.0/0 in order to direct all traffic to go through the tunnel. It's been discussed before, search the forum and doc wiki for more info.

@franken: Can you please provide a link please :) http://www.lobotomo.com/products/IPSecuritas/howto/m0n0wall%20HOWTO.pdf

If you were using pfSense 2.0 beta you might be able to do something with IPsec in transport mode + a GRE tunnel riding across that, but I haven't set that up before. IIRC, the ASA should support that (but you'd have to check on that first)

@jimp: And pfSense is the gateway for the workstation you are pinging from? What if you try to ping from the web interface (Diagnostics > Ping) with the LAN interface selected? Yes is the gateway. ipconfig : Konfiguracja IP systemu Windows Karta Ethernet Połączenie lokalne: Sufiks DNS konkretnego połączenia : local   Adres IPv6 połączenia lokalnego . : fe80::140c:40e9:35df:1d6%13   Adres IPv4. . . . . . . . . . . . . : 192.168.1.140   Maska podsieci. . . . . . . . . . : 255.255.255.0   Brama domyślna. . . . . . . . . . : 192.168.1.254  !!! ping result is in txt file ping-from-webgui.txt

i had some similar behavior recently…. i found the rule going from one vpn lan to another needs to have the gateway set to "default" otherwise i can ping from pfsense but not from a host.

i previously had 1.2.3-rc1 connecting to a 2.0 box. after upgrading the old version to 2.0 I now get a consistent 50kbytes/sec which is a slight improvement but no where near where it could be. i setup the same versions in an ESXi box. the ESXi system housed 2 pfsense gateways  (including the one doing 50kbytes/sec) and a third system which servered as the vpn client system: real host <-> pfsense A <- vpn -> pfsense B <-> virtual host the real and virtual host can send/receive 5mbytes/sec to eachother… pfsense A is the same system doing 50kbytes/sec with my other host so it's not the config, infact it's a default config. i don't change any phase 1/2 options except the PSK. i'm going to blame this on QoS going on on the shared network connecting to pfsense A which is beyond my control. from the virtual testing and the lack of other people complaining about IPsec, I would hazard a guess that pfsense ipsec is pretty fast.

hi, i make this with dyndns ip. I put my dyndns client in a lan machine, and i use loadbalancer in pfsense to load balance the webaccess of this lan machine. if wan1 up then webaccess use wan1 else wan2. so my dyndns ip is the UP ip. then i use this dyndns ip to create my vpn. pf1.dyndns.org <–----- vpn -----> pf2 when my first wan is down my dyndns ip is update by my lan machine to my wan2 ip,  and  so the pf2 come from my wan2 to re UP my vpn channel. hope that 's help !

It would probably work on 2.0 since you can do IPsec and L2TP together there, but there aren't yet any instructions for doing L2TP/IPsec so it would take a bit of trial and error to get going.

If the subnet is specified as the remote subnet for the IPsec tunnel, it should already be using the tunnel. That said, IPsec doesn't route in the traditional sense. If traffic matches the tunnel definition, it's just grabbed and put on the tunnel.

Cool thanks got it all working.

For now this is the workaround: 'Prefer old IPsec SAs' enabled lifetime on phase2 60 seconds Regards, Andrea.

Everything is blocked by default. If you want to allow access in across the tunnel, you need rules on the tunnel interface.

Hi, there is only a tunnel between Site A 172.16.1.0/24 and site B (lan) 172.16.2.0/24! ping failed because of missing tunnel. Ipsec is not routed. U need to add parallel tunnel on both sites for Network 10.5.1.0. Site A 10.5.1.0/24 (lan) <–-> site B (lan) 172.16.2.0/24 If u want to route VPN traffic use OpenVPN. you cant access networks over a vpn from pfsense itself by default, it looks like thats what you are doing. Yes, thats caused by Freebsd ipsec implementation. u need to set source ip (interface) or u need to define a static route. Remember Lan ip must match tunneldefinition to work. ping -S <lan ip=""></lan> cya

OK - finally got it working… First - I had no "generate_policy" command Then - I had various firewall issues on the pfSense end (it would make sense to have some indication that the IPsec connection will be pointless until explicitly openned) Then - I had firewall issues on the other end Then - I had routing issues on the other end (masquerading got done before IPsec got a look in) My head hurts. I'm going for a lie down.