Thanks CMB, that was what I was thinking I might have to do - works great, thanks :)

I can confirm that issue with SHA1 and our Watchguard XTM for a Site-to-Site VPN ??? Crazy to me is that another box running pfSense version 1.2.3 is working perfectly since a long time using SHA1 and same settings (except PSK and WAN stuff of course). It appears as the tunnel is up-n-running but in fact to traffic is going through. My solution is so far changing to MD5 instead on both, Phase 1and 2. After that every thing is OK immediately. :o Would like to see this can be fixed some how as I don't know if i'm missing a security option or anything alike.

it's works for me too but what is this floating rule ? thanks

@pingulino: @jimp: As I said though, there are some bugs in the detection process for that button, it doesn't take IP aliases or subnets other than lan into account. So unless the local Phase 2 includes the LAN subnet, there is no connect button. Does this mean I can not use IPSec for my OPT network? That would be disastrous! Infact I am not able to make opt1 working with ipsec. Have you made it working?

Its Work :) I postet on a other Forum from Germany and its work like this: http://www.administrator.de/Pfsense_L2TP_over_IPSec.html Now i want a Certificate Methode(mutual rsa + xauth) with L2TP over IPSec. Anyone can help?

Call me silly but I do not understand could anyone be more precise

Hey thanks for taking the time to reply.. I'll try that out and go from there.. thanks again…

Thanks for the reply.. You are correct.. it works 100%

thanks so much! :) @jimp: That should work fine, what that warning means is that you can't have IPsec and OpenVPN between the same two locations carrying the same two subnets. So you can't have: Site A: x.x.1.0/24 Site B: x.x.2.0/24 And have IPsec between x.x.1.0/24 <-> x.x.2.0/24 and OpenVPN between x.x.1.0/24 <-> x.x.2.0/24 - identical networks.

Without seeing your exact config it's hard to speculate. Generally speaking, that error means your Phase 2 definitions do not line up. For that kind of setup, you end up with something like: IPsec A<->B 192.168.200.0/24 <-> 10.10.0.0/24 192.168.200.0/24 <-> 10.20.0.0/24 IPsec B<->C 10.10.0.0/24 <-> 10.20.0.0/24 192.168.200.0/24 <-> 10.20.0.0/24

It is still not possible, and may have to be pushed back yet again for 2.2 I added a note to http://doc.pfsense.org/index.php/L2TP_VPN_Settings and included a link to the redmine ticket.

They should have been removed, yes, when that tunnel was deleted or disabled. That commit (which should be in 2.0.1) should have ensured that they were cleaned out if all tunnels were removed, but I don't see how it would leave them in there if the tunnel were removed.

Looks like you may be trying to do like a couple other of us are at: http://forum.pfsense.org/index.php/topic,48952.0.html

I just realized I dont get any internet connection. It connects to pfsense and stops there. I tried dns servers and what not. nothing. Im home atm and getting internet, so that means traffic from the vpn isnt passing through. i dont know where to even begin looking to fix this.

L2TP/IPsec isn't available (yet), check http://redmine.pfsense.org/issues/475

@opti2k4: In case someone gets into trouble like me… problematic was secret  that contained speical characters !" :( >:( >:( >:( >:( >:( >:( >:( >:( >:( >:( Ah not the first time we've heard that with other products. That's a bug in Peplink, not on our side, we support every character, symbol, etc. in shared keys. One of my production VPNs runs with every letter, number and symbol in the key just to prove that always works, as people tend to not believe the problem is actually in the commercial box they paid big bucks for and not on our side.

Looks fine at a glance. If the logs in this thread are all you're getting with that config, then you're not sending any traffic from 10.0.1.0/24 to 172.16.0.0/21 (at least that's getting to the firewall), as it would attempt to negotiate if you were.

Not uncommon with Cisco, it's relatively easy to configure them in such a way that they use a different policy when initiating than what they accept as a responder. Setting the phase 1 proposal checking to "obey" on the pfSense side generally will work around it, or alternatively fix the Cisco.

@abonstu: wow… thats awesome - thanks for taking the time to document those screens! i've actually got two pfsense routers in different locations: the first has a /29 frame route resulting in a config practically identical to your example - this connection is working perfectly the second router only has a single public IP address and this is where i am tearing my hair out - i cant seem to get the VPN up - the Amazon tunnel status just says PHASE_2_SUCCESS im sure its a routing issue but i cant see where im going wrong. the ipsec config is just using my WAN interface i shouldnt need a gateway or static route as my WAN is the only gateway i have, the tunnel subnet (169.*) should just go straight out the default gateway (right? :-/) any ideas on what im missing here? naturally ive tried all sorts of things, including manually configuring a static route anyway but i cant seem to get connected. That make two of us, I think this is the same Binding issue. I gave up now and recommended to terminated on Cisco Router.