@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.

Then you have a problem at the remote end. Maybe it needs some firewallrules too? Also note that the devices that are establishing the tunnels usually can't use the tunnel itself unless you add a fake static route. Retry from clients behind the vpn endpoints.

ok so i will forget about making a request ;D i belive i can live without isakmpd…i will see.

We do create rules for IPSEC behind the scenes. In the past you only had to add those rules manually if you were running ipsec on VIPs like CARP but I think we nowadays even create rules for those since you now can specify the CARP IPs as endpoints in the tunnelconfiguration.

Oh, ehm … i change the PFS option to 2 and now the tunnel is up and running again. I'm wondering how the tunnel works first with this option set to off ... Greets, Sannny