Well I sorted it out myself, not perfect but better. I enabled MSS clamping on the IPSEC tunnel under Advanced and set it to 1300. That has made transfers from Windows servers work well and it keeps a steady 95Mbit/s transfer, but it also affected the Qnap NAS that now has a bursting traffic graph. I guess it´s fine as the Qnap still averages about 80Mbit/s. The MSS clamping was enabled previously with the default 1400 value and that worked a lot better for the Qnap. Anybody that could give me a hint on how to get them both to work properly over the tunnel? I´m also not sure I understand how this works. I could ping both the Win Server and Qnap over the IPSEC tunnel with ping -f -l 1472 x.x.x.x without getting fragmentation both ways. Why would I need to clamp the MSS all the way down to 1300 for the Windows server and not for the Qnap? What other overhead is there to subtract from 1472? I Still can ping with a 1472 lenght max before fragmentation  even now when the clamping is set to 1300, is that how it should be? I´m open for someone to educate me on how this works and how to properly calculate this. Thanks, Jesper

Whoooooo worked. OK so for posterity's (and googles) sake, the solution was evident in PFsense 2.1 (RC0+), in the PH2 properties of the IPsec tunnel under local network you can provide the LAN subnet, and the 'nat/binat' address being the external WANip. My only conclusion is that since the ipsec routes are kernel routes they don't get applied with outbound nat rules (which is what I was trying).

I have this occasionally too.. seems not to affect anything.

There is a whole bunch of documentation available here. Absolutely not apparent what your setup is, and frankly, this whole thing should be taken to Windows Azure Forums way before you start debugging pfSense stuff (basically until MS has determined this to be a BSD-specific issue at least.)

Great job! Once again thanks. (I think i found the patches applied https://github.com/pfsense/pfsense-tools/blob/master/pfPorts/ipsec-tools-0.8.1/files/ipsec-nat.diff)

@cakewipe: I have added my documentation to google docs so anyone can see it. Here is the link for pfSense Router settings https://docs.google.com/file/d/0B2zOOBoh3isOSmtYakVEc3ZNWDA/edit?usp=sharing Here is the link for Shrewsoft, Android, iOS Clients. https://docs.google.com/document/d/1Pl21sk7ckU6dSqgxtXu6iNIv8-60bv7AFFVUQwdJ_WE/edit?usp=sharing Please leave comments if this is helpful so I will know not to remove the documents from my share. Hello Cakewipe,     Thanx for your work here.  I am having a similar problem you had.  When the client connects, there is no route handed to the client according to ipconfig on the windows box. I see not route to that network on the pfsense box. So looking over your doc above it looks like you are still using the static route, is that true? Did you have to use PSK-Xauth?  It wouldn't work with just PSK? I looked over your doc

I have got this going now. But what confused me is the abscence of a start tunnel button. The pfsense system should be able to send a packet through the tunnel to start it.

http://doc.pfsense.org/index.php/Mobile_IPsec_on_2.0

That reads more like there is a problem with either the phase 1 or phase 2 config than the error I was talking about. The error I was concerned with did allow connections, it just didn't reliably reconnect in a timely manner after a short disconnect.

What does "do not go alone" mean? they don't try to initiate/connect automatically? They will if you fill in the "automatically connect" IP for each Phase 2. Or just make sure there is always some traffic trying to use the tunnel. It will come up when it is needed.

Haha you could be right. So after a lot of changing over the last few days I think i've found a fix.  I had tried setting the "Enable MSS clamping on VPN traffic" a few days ago but it didnt work using the default 1400 value. I've just changed it to 1370 on both pfsense boxes and its working!! Can some explain to be why 1370 worked and why 1400 wouldnt?  Is it just a case that a router between the two sites doesn't support a MTU of 1400? Thanks, Daniel

I was able to figure my issue out, turns out I had forgotten to create the firewall rules.. rookie mistake heh.

No one any idear?

This may be off base, but wouldn't this be transport mode and not tunnel?  Transport mode encrypts between public IP's, most commonly seen used when a machine floats on the Internet without a firewall but I would think could also connect to the "public" IP(s) of a firewall to simply encrypt information originating from there?  The traffic would flow out of the WAN interface but that's how it should be? @c3llc: All- So I have a client with an interesting issue.   They are using pfSense 2.0.1 to connect to a trading partner.   This partner requires the use of an IPSec encrypted tunnel using PUBLIC IP addresses. The protected networks happen to be the IP address of the WAN interface on our end and two addresses on their end (essentially a /31 network). We have the tunnel configured, and it shows as green in pfSense.   They report that the tunnel shows up on their end as well. The problem is that pings to either of the two IPs on their end are being routed out the WAN interface and not out the IPSec interface!   ??? Is there any way to fix this? We had this exact configuration working with a Cisco ASA5510, but that box has been retired in favor of the pfSense virtual machine. HELP!! Thanks in advance, Rick