got it. turned out to be AVG internet security firewall. thanks for your time guys.

Thanks. I tried that before posting and it made by VPN unaccessible. After giving it another go and rebooting everything in between it's worked though.  ;D

some snippets of the the contents of the ipsec logs would probably be helpful to diagnose

i was seeing the same problem you mention where later connections would fail to pass traffic, and i could temporarily work around the issue by disabling IPSEC and then re-enabling IPSEC on the pfsense and then reconnecting the client…the problem would eventually return

setting the policy generation to "unique" was the longer term fix for me, and i see you have that set but you have some other settings configured non-typical (if there is such a thing for ipsec ;) )

anyway, you might try rebuilding your connection following this
http://dekapitein.vorkbaard.nl/tech-1/how-to-set-up-ipsec-tunneling-in-pfsense-2-0-release-for-road-warriors

with the exception of configuring the policy generation setting to unique instead of default as is depicted in the howto

that is how i have things setup currently and havent seen the issue return

"mobile client" can mean alot of different things, but if you are talking about the most common mobile user scenario (windows laptop making a remote connection), thanyou might want to take a look at these

for the 1.x era
http://doc.pfsense.org/index.php/IPsec_Road_Warrior/Mobile_Client_How-To

for the 2.x
http://dekapitein.vorkbaard.nl/tech-1/how-to-set-up-ipsec-tunneling-in-pfsense-2-0-release-for-road-warriors

if you end up using the 2.x setup article, you will probably need to configure the Phase 1 Policy Generation differently than depicted in that article (pick "unique" instead of "default" to avoid issues with subsequent connections). the firewall settings are easy to miss in that article as well so make sure to read carefully over that part.

i was having problems with 2.0 and 2.1 for shrew ipsec clients where the initial connection would work fine, later subsequent connections would seem to connect but would fail to pass data

i tried disabling NAT-T and DPD as suggested elsewhere in this forum, but the ultimate fix was to setup the pfsense and shrew client per typical "road warrior" configs

e.g. http://dekapitein.vorkbaard.nl/tech-1/how-to-set-up-ipsec-tunneling-in-pfsense-2-0-release-for-road-warriors

with the EXCEPTION of setting the P1 Proposal Generation to "Unique" instead of "Default"

[that setting change is noted in the redmine link mentioned in this thread, but its in a slightly different context of multiple clients coming from the same nat network]

anyway, since making that change, i havent seen the problem where later reconnects fail, and no need to disable NAT-T and DPD

maybe that setting will work for you

on the pfsense side, try setting the P1 Policy Generation to "unique"

As you read elsewhere, a second Phase 2 on each leg is needed. Here is an example:

Hub:
IPsec A
h.h.h.h/24 -> a.a.a.a/24
b.b.b.b/24 -> a.a.a.a/24

IPsec B
h.h.h.h/24 -> b.b.b.b/24
a.a.a.a/24 -> b.b.b.b/24

Site A IPsec
a.a.a.a/24 -> h.h.h.h/24
a.a.a.a/24 -> b.b.b.b/24

Site B IPsec
b.b.b.b/24 -> h.h.h.h/24
b.b.b.b/24 -> a.a.a.a/24

And so on. Add a phase 2 for each possible set of traffic src/dst network pairs.

hi,

there is a rule to allow traffic from the LAN behind the checkpoint to the PFsense server.
it worked until i've started the vpn.

Yep, under Linux one has the option of L2TP+IPsec by using openl2tp (http://www.openl2tp.org/) with racoon or StrongSWAN/OpenSWAN (note: the latter exhibit some bug which was fixed with a commit to the 3.2-rc5 linux kernel).

StrongSWAN offers IKEv2 and has been ported to FreeBSD, but with certain limitations, see http://wiki.strongswan.org/projects/strongswan/wiki/FreeBSD

Limitations
Due to the lack of policy based routes, virtual IPs can not be used (client-side).
The kernel-pfroute interface lacks some final tweaks to fully support MOBIKE.

Guys this is the response i was after.

OVH Failover IPs are protected against UDP attacks, this disturbs some VPN and other UDP protocols.
You can buy unprotected IP from your OVH Manager, search 'IP for UDP' or something, close to your "IP Failover" Icon.
I tried on my own kimsufi, but I don't have enabled the "professional use", then I cannot try it

ok, I committed a fix to skip that part of the code if there are no p2's.

ok cool, Thanks.

Strangely enough, it was only a lifetime mismatch for phase 1.
So finally we're connected, all is fine!

Now this is interesting!
I'm starting a new thread about this character problem, it might be useful.

@gordslater:

If this happens from only one machine, I've had a faulty NICs (both onboard and PCI/PCI-X) give me SSH broken pipes and strange problems when I ran  ncurses commands,  top  or a command like  ls -al  with significant return data, yet simple on-liners with no output worked just fine. Drove me crazy each time.

My SSH sessions stay up indefinitely over the VPN otherwise, no problems

Yeah stuff like that can drive any one crazy.

Regarding my problem got solve a couple of days ago. It was the problem from the third party
they had some bad hardware installed that messed things up.
Now I have everything working perfectly :)
thanks PFSENSE :D

@cmb:

The IPsec rules control what traffic is permitted inbound from the VPN, it's always required if you want to permit any traffic in over the VPN.

Thank you.  That helped.  I was perplexed as my VPN pfSense <–-> IPCop* was working from the pfSense network to the IPCop network.  (And that is the direction of most traffic) But when I checked the network from IPcop to pfSense it was was not working.

I added some IPSec firewall rules in pfSense and things started working fine!

Thanks again.

I found out with the tipps on  http://doc.pfsense.org/index.php/IPsec_Troubleshooting

it worked as a charm!

if u need some help about that give me more details about your issues…

pufff as it's in front of me - thanks a lot!
can you remove this thread again as it was just my stupidity? :)

cheers
josh