Check Dead Peer Detection. If you put 30 seconds the failed Remote peer will be deleted and a new Phase 1 negotiation will start.

It's still BETA (BETA5 actually) and there are a couple of issues that some people hit in the last few weeks that are problematic.

I'd say it's worth trying as a proof of concept but I would hesitate to put a current snapshot into production as-is for the moment.

Yes.

Roy…

Looks like it may have to wait for 2.1.

That is correct the PFSense box is the gateway for the LAN

Config was PFSense Box
NIC1 WAN1 – VPN to Public Network
NIC2 WAN2 -- Load Balance to WAN1
NIC3 LAN -- Internal Network

Yes I was able to see the packets on the LAN side but they always tried to go out the WAN1 interface not the IPSec tunnel - I have added a 2nd PFSense Box now and it's working as expected

New Config

Original Box
NIC1 = WAN1 (/28 Network Public)
NIC2 = WAN2 (/28 Network Public)
NIC3 = VPN Link (/30 Network Public)
NIC4 = LAN (/24 Network Internal)

2nd Box
NIC1 = WAN1 / VPN Public (/28 Network Public)
NIC2 = VPN Link to 1st Server (/30 Network Public)

Now when I send traffic to that subnet I added a rule to send all traffic out VPNGW on the 1st router and it's passing it to the VPN box (2nd router) then passing along to the VPN Subnet as expected

Thanks a mil SeventhSon, sorted my problem :) cant believe i missed it :P

@Blind:

The cisco ASA does the PAT/NAT necessary for the tunnel, I just need the pfsense to firect traffic to the tunnel for the clients.

But if your pfSense isn't doing NAT then all the hosts behind it will count towards that client limit as they'll be visible.

@Blind:

I have not setup the IPsec tunnel on the pfsense box so Im not understanding why my thread was moved here.

Because your post made it sound like you've set up an IPsec tunnel between the Cisco and the pfSense. I think it's time for a diagram so we know exactly what your setup is.

@Blind:

As I understand the IPsec implementation on pfsense does not support my config as IP ranges on either side of the tunnel match.

The ASA is working perfectly with the static routes added that I mentioned in my previous post, so the tunnel setup is fine, I just need to go through the pfsense as gateway to trick the ASA into allowing more than 10 clients to go through it.

From where? How is the pfSense host connected to the Cisco? How are the clients connected to the pfSense host?

@jimp:

If you connect with ssh, you can do a tcpdump on enc0, which is the IPsec interface, so you can see what traffic is or isn't hitting the tunnel.

tcpdump on enc0 is not showing the rtp packets at all on either side (capturing on the incoming/outgoing interface does show them as well as the ones that make it from local->remote)

No clue why it is not capturing the rtp packets that I know are getting through. (SIP packets are being captured fine).

Am just doing a tcpdump -ienc0 -wtcpdump.cap
….. =o\

@spiritbreaker:

Hi,

u would suggest this solution:

Internet <=> { ADSL Router in Bridge Mode } <=> [Public IP via PPPoE] PFSense [192.168.2.254] <=> LAN 192.168.2.0/24

Create dyndns account if u have dynamic ip. Then its easy to get VPN to work, either Ipsec based or Openvpn.

Cya

I agree with spiritbreaker. This is the most desired setup. Also.. Ive done this with a MikroTek routerboard as well as a PFsense system without issue. You will however have to make your PFsense system be your PPP authenticator (your modem will act more like a cable modem/dumb device) Ive got a very basic tutorial here that documents how to do this with a routerOS based device. It should at least get you started.
http://www.fusionnetwork.us/index.php/articles/general-tutorials/qwest-net-static-ip-transparent-bridging-routerboard-solved/

-E

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.