thanks Hoba. I had searched the forum, the advice is having parallel tunnel with unique identifier. 1. In the IPSec Tunnel setting, in phase 1, i choose identifier as My IP address and in pre-shared secret, i put in the entry identifier - IP of the box at remote site and the shared secret. In order to have unique identifier as mention, i will not use My IP address? Sorry I am a bit blur in this Identifier setting. 2. If the tunnel i pair up with a checkpoint firewall, so at the checkpoint side i will need to create multiple tunnel also? In check point i did not see any setting for identified? how i can make the tunnel unique?

okay, I solved it: its an issue with remote subnet. When you get same errors check the net that is given to you. If you dont have an IP- Calculator by hand: go http://jodies.de/ipcalc scroll down and check cheers :) stefan

IPSEC filtering is a new feature of 1.2. 1.0.1 was always passing all incoming IPSEC traffic. If you upgrade from an old version we'll installa pass any rule at IPSEC so things will work the way they did like with 1.0.1. However, if you do a fresh install of 1.2 this rule is not present which means everything incoming through a tunnel will be blocked by default. Just create a rule at firewall>rules, IPSEC to allow the desired traffic.

Behavior is different with pfSense-1.2-BETA-1-Embedded-128-MB.img.gz, but still has difficulties. No problem without the Hi/Fn card. With the card, the behavior is complicated and, unfortunately, inconsistent. The data here represents approximately 15 power-cycle iterations. Sometimes racoon is restarted. Not entirely clear about the timing. Consistently racoon and a working tunnel is available immediately after the console message Configuring IPsec VPN... done appears. However, sometimes racoon is restarted a second time. It is not clear under what circumstances but 3 times (out of 15) the console never finished loading. Twice the last message on the console was: Starting /usr/local/etc/rc.d/*.sh...done. Once it got a little further but still hung at: Bootup complete FreeBSD/i386 (staff1.vineyardtransit.com) (console) *** Welcome to pfSense 1.2-BETA-1-embedded on staff1 *** Once the console finished loading; but shortly after it was done, racoon was restarted. Another time racoon restarted almost 5 minutes after boot was 'complete.' At all 5 of these occasions racoon reports that it received a signal 15 and a few seconds later it is restarted.  Prior to this second start-up the IPSec tunnel is fine.  After this second start-up phase 2 negotiation fails even tho a phase 1 SA is achieved. As before, if I stop/start racoon manually (ssh works fine), all is well. Since the Generating RRD Graphs section takes almost 4 minutes to load, this means that the IPSec is established and working for an appreciable period before it breaks. Interestingly, without the Hi/Fn card, racoon is still restarted; however, it works when it comes back up. Sorry this report is so chaotic.

This depends on the other vpn-router, not pfSense. I can't say anything about that as I don't know what device you are using there. You have to find a way to transfer the shown configuration on that device or it won't work.

Ok, now Im really lost. I did my setup with the help of this tutorial two or three times now and I do not see any differences between the tutorial and my two machines. Only difference is that my static machine has two interfaces with WAN being the dynamic interface with PPPoE and OPT1 being the static interface like I wrote in my other thread where I was told to update my static box to the latest snapshot because of IPSec on OPT1 not being possible.

@mnsmani: … Apr 20 09:48:52 racoon: INFO: 192.168.2.99[500] used as isakmp port (fd=17) … Apr 20 09:48:52 racoon: INFO: 121.247.124.90[500] used as isakmp port (fd=19) … also, as is damn strange enough, I see that this conf connects from one side, and does not connect from other side. but I could not reproduce that scenario myself :( Is one of the peers behind another NAT with it's WAN in a private IP-Space? Seems to be the case from the logs. In that case you most likely will only be able to connect from the end behind the NAT to the other end as the NAT is preventing one end to be reached from the internet directly. I would try to get the both pfSense to real WAN IPs with nothing but transparent equipement (like modems) in front of them.

Ahh, I somehow expected an new iso image and was looking for it on the downloads page  ;D But OK, I downloaded the snapshot and am looking for how to install it, I guess its done via General -> Firmware? Ah, someone on IRC mentioned google for this and now the snapshot is installed. Now waiting for someone to appear at the other office for a test :)

Ok i think that the biggest problem was between the keyboard and the monitor ;D ;D and when i said the internet portion was a linksys router i ment that i had the Wans  of the pfsense connected to the Lans of the linksys router. it was in the test lab when i just said enough, and grew a set i installed it live on on the field and Boom i was up and running like a CHAMP no more chumps Also the documentation for this setup rocks now that i got my stuff together. Great Product Chase

No, the one mentioned here: http://pfsense.blogspot.com/2007/01/102-beta-period-will-start-soon-5-9s.html

I actually solved the problem. Had the wrong range on the subnet  ::)

It might be the timeout value as well. Saturate your link and then from a shell try this: ping -t1 $monitor_ip Then slowly crank -t1 up by 1 and attempt again: ping -t2 $monitor_ip Keep cranking up the timeout until you find a decent sweet spot and if it is not too invasive we might be able to change this easily.  Modifying SLBD to keep track of all previous ping counts is a fair amount of work since this is written in C.

You mention problems between 2 endpoints explicitly? Maybe investigate if there are line issues or if something is special about these endpoints (like running another firmware at their end or whatever).

the only reason I'm aware of that people were wanting to use gif devices is for filtering, now filtering is possible by default with enc(4) in current snapshots.

Hi, I've the same problem, but using the 03-15-2007 Snapshot. It seems like it works well only the first time (or after a reboot) when there is no SA… I'll do some more test... bye Z

ok… looks like "vpn goes down" problem was fixed. the server has been up for more then 24 hours now. but i still can't ftp to remote sites over vpn. pcanywhere (and file transfer) works fine, i can ssh and scp to remote pc's and they can ftp to my office, but i cant ftp to them. does anybody know how to fix this? tnx p.s. this _If you want to connect to a FTP server you need to add this workaround to your LAN tab. Proto Source Port Destination Port Gateway TCP LAN net * 127.0.0.1 1 - 65535 * Now the packets are forwarded correctly and you can connect to an FTP server._ is not helping. ok… ftp problem was fixed too  8) as they say "if nothing works read the manual"  ;D ::)

Something like this could be done between sites that only run pfSense systems if some code was written for this kind of dead peer detection. Multiwan IPSEC is working with the latest changes in the snapshots, it just doesn'T detect failure or does failover.