I have an update on this.  it seems that my remote subnet entry was /16, while the actual remote subnet was /22… the debugging on the cisco was way more helpful in determining the problem at the end of the day.  for those in a similar situation you will need to run the following on a PIX/ASA to see what you need. debug crypto isakmp THEN.  i got a ping ready on pfsene, to ping the inside address of the remote endpoint (after creating firewall rules) and did the following terminal monitor -execute ping on pfsense now. -after you see the Group = xxxx  entry in the logs and think you have what you need terminal no monitor this will keep it from scrolling off your buffer until you can figure our what it going on.

damned you are right, so blind I am. Thanks a lot Hoba, I was looking for somehting more difficult than it is…

Hello, The service is up and running after I setup the WAN interfaces. Was my mistake. It was for the first time when I had to setup a VPN. Noe I know what I did wrong!  ;) The VPN now is running. Thank you! Lucian

There are two pfSenses. This morning I succeed to configure the VPN. Was my mistake. I try to configure the VPN with both pfsenses on the same switch. I used a crossover LAN cable and everything is ok. I didn' had tho switches. Thank you  all of you for your help. This was my first time when I setup an IPSEC VPN. Lucian

@Stoney32: this is the syslog for pfsense racoon: ERROR: phase1 negotiation failed due to time up. f4a68900f9a99c27:42b5b53ba608ead3 racoon: ERROR: fatal INVALID-ID-INFORMATION notify messsage, phase1 should be deleted. racoon: INFO: received Vendor ID: CISCO-UNITY racoon: INFO: received Vendor ID: DPD racoon: INFO: received broken Microsoft ID: FRAGMENTATION racoon: INFO: received Vendor ID: RFC 3947 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02 racoon: INFO: begin Aggressive mode. racoon: [Unknown Gateway/Dynamic]: INFO: respond new phase 1 negotiation: 192.168.10.1[500]<=>192.168.10.254[500] Can you try that from a different WAN? Looks like you have some mtu issues there. Maybe try lowering the mtu at interfaces>wan at the box that your client is behind. You don't have to setup firewallrules for IPSEC to work. This is done behind the scenes when enabling IPSEC. However, you have to setup rules for traffic coming through the tunnel (firewall>rules, ipsec tab) but that'S the next step. This wouldn't prevent the tunnel from being established but block traffic that is coming though the tunnel once it is establiched.

Try a traceroute from your lan to the customers lan to see if the packets go through the tunnel. If you don't see the gateway of your ISP there it goes through the tunnel (diagnostics>states should show you that as well). Maybe your customer has his firewallrules not set up correctly and though the tunnel is established you are blocked at their end.

I woke up this morning (afternoon actually) after beating my head against the wall last night and tunnels were working… Turns out that raccoon crashed (there was a core dump in the root directory, which I didn't even think about and deleted), which most likely corrupted the IPSec state entries.  Normally rebooting would have fixed this, however since I had pfSync on, the two boxes just passed the bad entries back and forth... :) Had I thought to reset the state tables, it probably would have started working immediately.  Luckily the IPSec timer was only 6 hours so after sleeping all was good. Roy

(I know this is old, but it is exactly the problem I am having.) I am running pfSense 1.2.  Connecting to a Netgear fvs124.  The connection works perfectly until the SA times out.  Basically, the exact same problem that was described above.  A reboot of pfSense takes care of the problem. Any other suggestions?  (checked the firewall logs.  UDP 500 and ESP are getting through fine.) EDIT- Semi-resolved.  Turns out the problem is the netgear firewall.  Will be replacing it with pfSense on Satuday.  OpenVPN is far superior.

Thought so. Thanks for the input.

This is not enough information to even make a guess what'sw going wrong. Please provide what you tried to setup, maybe some screenshots from the webguis of both devices and logs.

I'll give this a shot!!!  Update…  That worked perfect! Awesome!!! @heiko: One Option You need for example two tunnels LAN –> LAN  --> with phase 1 = User FQDN => lan@ipsec.de (any fantasy FQDN) LAN --> DMZ --> with pahse 1 = User FQDN => dmz@ipsec.de (any fantasy FQDN) But, this runs for me not in the main mode only aggressive.... Greetings Heiko P.S. thx hoba

if you have a vista client, then you need the latest shrew beta version, the last stable didn´t run on vista and ends with a BSOD…. Greetings Heiko

the only difference with the new location was 1.2 release version.  I have just downgraded to 1.2 rc2 to get things rolling. tunnel is up and running  thanks for all the help, and I do apologize for switching it out. I needed to get it going.

thank you. Sorry  for asking stupid questions  :-[

Sorry, I don't understand. Can you rephrase or add more details?

Not sure which thread exactly you mean but that topic is covered multiple time like for example here: http://forum.pfsense.org/index.php/topic,8476.msg47573.html#msg47573 However I don't think that this has something to do with the issue we are seeing here.

i´d like some info on this, any progress? regards /F

this setup seems to work this way, i've redirected all requests getting to the 3com device to the pfsense on the WAN2, so everything works from my server al the rest is on the WAN, including the tunnel (the dhcp cable connection) again, thanks for all the help!! greets

ok… reinstalled.. working. installed squid.... working. installed imspector... working. dont know why but it is working. thanks to everyone for the help.

You can use the same identifiers at both ends but they have to be unique for each tunnel. Having them different at both ends for the same tunnel won't hurt, just set everything up correctly. I usually find it easier to have the same at both ends as this is easier to remember and less possibility to configure things wrong. I would just disable the IP-Identifier tunnels for now (there's a checkbox when you edit the tunnel) and set up the new ones from scratch. This way you can easily move back and forth between the one and the other config until you get things going. Once the parallel tunnel  setup works just delete the disabled IP-Identifier tunnels.