Yes I am.  Ok so I will change that to a local IP and test again.  Thank you for posting that information.

Solved

System > Advanced > Misc. > Enable MSS clamping on VPN traffic

The problem was already large RPC packets becoming too large as a result of IPsec encapsulation.  After reducing the WAN mtu and messing up all my connections, a colleague suggested I try this setting.  It works great with the default value of 1400.

Hopefully this helps someone.

That error is not your problem. That error is harmless. Mobile tunnels have no remote gateway, so that error isn't really saying anything significant. The system log is not where you should be looking, check the IPsec tab.

I will have to recreate everything to get a log dump. I guess what I mean when I said they do not contain anything decipherable to me is that through all my changes, I muddied the waters so much. I will post back when I have recreated the issue.

Good to hear

Is 192.168.190.x the LAN subnet of the PFsense or an additional network behind the PFsense?  You might need a rule on your LAN interface permitting ALL LAN subnets to any.  Also, if it is an additional network, you need a route on your PFsense to point 192.168.190.x out the local LAN interface.

Same questions would apply for the other side of the tunnel as well…

It is normal for it to try, yes, but if it's bound to the CARP interface the traffic won't normally ever make it out of the box, so it does nothing but fill the logs on the secondary with attempted connections.

System > User Manager, add a user, save, edit user, add xauth dialin permission.

Anybody have any thoughts on this?  I can certainly provide more information if needed.

This php may help you on it.

https://200.x.x.x:8443/diag_ipsec.php?act=connect&remoteid=10.0.16.0&source=172.28.1.1

To run it on shell, do with php -q

hi,

have you made progress on this topic?

thanks anyway :)

@podilarius:

Except for the DLink, it sounds ideal. Have you run memtest on the machine to make sure memory is good?

Hi Podilarius,

maybe the d-link is not an ideal choice - I agree No, I did not check the memory, nor the hard drive. It really sounds like a bug to me but I'll do the test one of those days.

@firl:

Anyone know if it is possible to have the pfsense box become an ipsec client for a username / password combo ( xauth ) to a cisco vpn server?

You can try to add cisco vpn client via pkg_add and configure it.

That's up to the Android version running on your phone and the modification that your cell phone provider has made to it.

My Droid X on Verizon running Gingerbread has Advanced IPsec VPN (I wrote that doc), but many others do not.

I'm not sure if any of the alternate firmwares like cyanogenmod include it or not, one would hope they do.

It finally works as I want to.  Know why people keep trying for days.  There are some key issues missing on faq / doc / tutorial.

PFSense mobile ipsec vpn setup is somewhat like server and client and it suggest using aggressive mode due to unknown client ip.  But some other doc said aggressive mode does some plaintext communication.  I cannot totally understand but my setting below works in main mode:

IPCop settings towards the tutorial server side.  It doesn't matter there is no separate setup page for mobile client and pre-shared keys.

PFSense setting as client.  PSK in tunnel phase 1 page, that is sufficient.

IPCop's ID example is @domain that is key difference with PFSense that can be user define.  However in PFSense putting @domain with define as dist.name simply cannot save settings.  Username is ok, but racoon/PFsense somewhat looking for IPs when in main mode.  So type define as non-IP is somewhat broken there.  It looks impossible to re-setup the IP/ID  every time as dynamic.  Finally comparing IPCop with PFSense - the ID can be user define like shared keys.  Fixed fake IP address there finally works.

Pluto/IPCop just send ID field no matter what's in it, but racoon needs IP-like string no matter type is defined in the setup page.

Some help on web says PFsense need another rules aloow * * for the IPSec tunnel and IPCop automatically fix the route table.  I try deleting that and it still works.