Prefer older IPsec SAs was ticked for me, however i unticked it last night and it stayed up overnight.. which is rare.

If the IPCop side drops out (which it does quite regularly), then a new SA would be issued? So having that option checked meant pfSense was using an outdated SA?

thx supernetting works!

@jimp:

You got that last racoon error (address already in use) most likely because racoon was already running and needed to be killed first.

However this may be the real issue:

2011-01-05 11:27:21: DEBUG: getsainfo params: loc='10.1.1.5/30' rmt='172.26.0.0/24' peer='y.y.y.y' client='y.y.y.y' id=0 2011-01-05 11:27:21: DEBUG: evaluating sainfo: loc='192.168.168.0/24', rmt='10.1.1.6/30', peer='ANY', id=0 2011-01-05 11:27:21: DEBUG: check and compare ids : valu mismatch (IPv4_subnet) 2011-01-05 11:27:21: DEBUG: cmpid target: '10.1.1.5/30' 2011-01-05 11:27:21: DEBUG: cmpid source: '192.168.168.0/24'

The phase 2 subnets do not match between the peers

Normally the phase 2 subnets are mirrors of each other, such as:

Site A:

sainfo address 192.168.254.0/24 any address 192.168.10.0/24 any {         encryption_algorithm 3des;         authentication_algorithm hmac_sha1;         compression_algorithm deflate;         lifetime time 3600 secs; }

Site B:

sainfo address 192.168.10.0/24 any address 192.168.254.0/24 any {         encryption_algorithm 3des;         authentication_algorithm hmac_sha1;         compression_algorithm deflate;         lifetime time 3600 secs; }

IPsec tunnels have no address themselves.

Wow! This fixed it for me. Outstanding my friend. I was working under the understanding that ipsec tunnels had a 'gateway ip'. Everything is working now :)

If you search the forum there are many discussions about pfSense, IPsec, and iPhone. Not sure about the Nokia though.

Thanks jimp :)

Frankly at this point I'd be popping your favourite packet sniffer on the various links and seeing what's going on at the network layer. That'll tell you exactly how far the packets are getting, and possibly why they're not getting back.

After more investigation, it does indeed work properly doing what I suggested above.

I also noticed in the newer builds that when raccoon is started it binds to all interfaces current IP addresses.  If I understand correctly, whatever interface that is set in the phase 1 setup, hidden firewall rules are automatically added to allow ports 500/4500 UDP for that interface.  So what I did was set WAN 1 in the phase 1 setup and then on WAN2 I manually opened 500/4500 UDP.  This also works.  What I would like to know is what is the "best" way to do this from a security and not getting broken on upgrades perspective.

The flaw is in the iptables implementation.

IPSEC originally uses UDP port P500 and ESP to establish a tunnel. unfortunately the current iptables version implemented in pfsense  is not aware of ESP packets and cannot NAT them. as a result only one connection can utilize them.

once pfsense supports NAT-T your problem will be solved as it encapsulated the ESP packets in a UDP packet and routes them on port 4500.

Apparently they found 2 bug in the cryptographic code. They don't know yet if those bug could be dangerous, but they will hopfully fix those bug  :)

it is working now… IKE service was not started from trace utility, when i started it the tunnel was enabled.

check the following link: http://rolfsa.blogspot.com/2009/07/basic-pfsense-to-pfsense-ipsec-tunnel.html

Still no luck. I am running 5.6.0.5-46o on the SW. The tunnel is active however no traffic is passed. Still getting dropped packets on the SW.

12/16/2010 11:55:15.256 Notice VPN IPSec IPSec (ESP) packet dropped xxx.xxx.xxx.xxx, 0, X1 xxx.xxx.xxx.xxx Inbound: SeqNum=1446931972, SPI=0x4D32000

When I hover over the log record I get 'Message id: 533 Legacy Category: Network Access'

Any luck on your end?

Jimp thanks for the update  ..can you point me where to get the snapshot ..thanks

Hi all!

I had the same situation in Windows XP!
Shrew said "Tunnel enabled" but not a single byte got through.  :(
I solved it by uninstalling shrew and reinstalling ist (v2.1.7).  :o
Obviously, the Vodafone Mobile Connect Software must be installed FIRST and second comes Shrew VPN, otherwise the Vodafone Software won't properly work with Shrew.
I think that I did it the other way round first…

Also, make sure to set the checkbox for the "Shrewsoft Lightweight Filter" VPN-Adapter in the properties of the UMTS Network Card.

Good Luck!  ;D

you actually have 2 issues:
1. encryption, one side is set to use CAST, the other AES
2. authentication hash, one side is set to yous sha, the other md5

you find this in the top two lines of code you pasted.

Hi,

would you share what configuration you used, I'm struggling with a 2800 at the moment?

Cheers!