If you use a dynamic DNS hostname it does work properly - I use this personally and I know people using it with dozens/hundreds of tunnels. It works great.

However the title of the thread said "without DNS" so that's how I replied.

You can't really tell that except from reading the full log.

If you look at the output of setkey -D you can see when the phase 1 entry was created, but if that was ever re-negotiated then you'd only see the latest entry there. (Or perhaps an occasional older one in some cases)

My bad. Thank you for answering.

Nobody has ever asked for esp-null to my knowledge, so it's probably lack of demand (and hence lack of funding or submitted code).

The use cases for it are pretty rare as well.

I'm going to go ahead and give this topic a little nudge in hopes that someone can shed some light. I've also found a couple of posts like this:

http://forum.pfsense.org/index.php/topic,29152.msg151679.html#msg151679

where someone was trying to use AH, and the workaround they came up with was to use ESP.

I'd really like to use AH, as in the eventual implementation one end of the tunnel will be a low powered device that I'd prefer to not saddle with a bunch of encryption, and in this application confidentiality is not as important as authentication and integrity.

Hi.

Thank you very much for your help.

I have created the tunnel and everything seems to be okay until it stops working with no reason.
Having a look at other threads of this forum, it seems to get back to work when the racoon service is restarted.

In other posts it is suggested to check the option "System -> Advanced -> Miscellaneous -> Prefer older IPsec SAs" but in the end I have to reboot racoon service.

Any help appreciated

Thank you very much.

This is very similar to my problem, our situation and logs look almost identical.

http://forum.pfsense.org/index.php/topic,40285.0.html

Easy test would be to make a different certificate from a completely different CA and see if you can still get in with that.

Oki i have solved it and IT was NOT IPsec problem.

IT was all down to that i HAD NOT set a GW on my access point that i was using to ping test.

I am now going to go an kick my self a bit, but anyway i have hardened my IPsec skills  :P  ;D

Then i dont know

NAT-T would be the way to go there, if you can. Otherwise you're almost guaranteed some kind of breakage.

Note you also need to forward back the entire ESP protocol, not just udp/500 (and udp/4500 for NAT-T)

I can confirm that the problem WAS NOT my config or PF but in fact it was the data centre config and not managed by me.

Not nearly enough information there.

Is this 1.2.3 or 2.0? Is this i386 or amd64? What kind of hardware is it? (ifconfig -a would help)

I found that it doesn't matter. I have 7 pfsense routers all working perfectly now. I found that I needed to uncheck the 'Prefer Old IPsec SAs'.

In some places pptp, l2tp and ipsec is blocked via firewall rules, openvpn is quite hard to block, unless you block https also. Only my 2 cents

Try this….

http://confoundedtech.blogspot.com/2011/08/android-nexus-one-ipsec-psk-vpn-with.html

After a few days of testing I can say I have it running reliably now, too. I can connect with my iPad, iPhone and with the built in Cisco IPSec client in OS X with the setup found in the previously mentioned post (http://forum.pfsense.org/index.php/topic,24752.msg130558/topicseen.html#msg130558)

As my effort to contribute for this to become a wiki entry, here are the two screenshots of the firewall rules I needed to get traffic flowing after I succeeded in connectiong via IPSec:

The first screenshot is a floating rule, passing all traffic from the ipsec interface to my lan interface (which happens to be a bridge of two interfaces, so it is called LANBRIDGE, but you might wanna just use your default "LAN" interface).

The second screenshot is the firewall rule in the ipsec tab of the firewall. I think it gets created by default, but if not, then set it up as I did, it works :)