If you specify a keep-alive IP that's in the remote subnet (inside the remote phase 2 network), it will bring up the tunnels automatically every time.

The connect button just sends a ping on the tunnel, nothing fancy.

Hi,
Can you take a SS of both of your configs or write them out here?
Sounds like its probably a subnet thing or possibly another problem.
Also.. Are there any errors in the logs under the Status->System Logs -> IPsec section?

-E

@submicron:

Great contribution!  Sticked for posterity and to encourage everyone who has IPSEC issues to immediately PM Eureka for help :D

Thanks Submicron I had no idea this got stickied until I came here to post my "update"  8)
Sorry if anyone has had any problems with this. I found a bug today with the "General" configuration page of the ShrewSoft VPN client (on a windows 7 system). It forced me to use a 255.255.255.254 netmask to get traffic across to the remote network. Ive updated the tutorial on the site to include the "working" netmask.

-E

Did you change the "interface" to be the CARP VIP? Or did you just change the Identifier?

I have now tested it by configuring the internal PCs to VPN into the internal network and routing all traffic through it.  Without ripping the pfSense firewall out and rebuilding it as a manual FreeBSD setup, I don't know how else to fix the problem.

Great info, thank you!  :)

Site 2 server with Public IP:

Mar 3 19:41:35 openvpn[56496]: event_wait : Interrupted system call (code=4)
Mar 3 19:41:35 openvpn[56496]: /usr/local/sbin/ovpn-linkdown ovpns1 1500 1560 10.0.8.1 10.0.8.2 init
Mar 3 19:41:35 openvpn[56496]: SIGTERM[hard,] received, process exiting
Mar 3 19:41:36 openvpn[45557]: OpenVPN testing-cee388313521 amd64-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] [MH] [PF_INET6] [IPv6 payload 20100307-1] built on Feb 22 2011
Mar 3 19:41:36 openvpn[45557]: [DEPRECATED FEATURE ENABLED: random-resolv] Resolving hostnames will use randomisation if more than one IP address is found
Mar 3 19:41:36 openvpn[45557]: NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
Mar 3 19:41:36 openvpn[45557]: TUN/TAP device /dev/tun1 opened
Mar 3 19:41:36 openvpn[45557]: do_ifconfig, tt->ipv6=0
Mar 3 19:41:36 openvpn[45557]: /sbin/ifconfig ovpns1 10.0.8.1 10.0.8.2 mtu 1500 netmask 255.255.255.255 up
Mar 3 19:41:36 openvpn[45557]: /usr/local/sbin/ovpn-linkup ovpns1 1500 1560 10.0.8.1 10.0.8.2 init
Mar 3 19:41:36 openvpn[46329]: UDPv4 link local (bound): [AF_INET]y.y.y.y:1194
Mar 3 19:41:36 openvpn[46329]: UDPv4 link remote: [undef]

I resolved the issue today. Just in case anyone else has this issue, my problem was solved with a simple BIOS update. I had always noticed a "CPU Microcode error" when booting the system, but I had never thought much about it. When I noticed that the microcode was used for TX/RX Checksum offloading, I decided to update the BIOS and try to resolve the "CPU Microcode error". This also gave me the added benefit of exposing all 4 cores to the OS, whereas only 2 processors had showed previously.

Just to follow-up on this…

Turns out, the internet link was 10M/768K instead of 4M/4M.  So, pfSense and the Cisco ASA were working exactly as they should worked.

Thanks again Jim for all the help/pointers...

In the kind of setup I mentioned, the tunnel would be up all the time exchanging ospf info with the far side making routing decisions. It wouldn't be offline.

I'm having the same issue.  Would love to know if anyone has made this work.

This isssue has been solved.  In the old router with Comcast I was doing double nating.  Having  a DMZ zone in the middle between their router and my pfSense.

Finally after level 2 Support called me back from Comcast DOCSIS 3.0 router does not support the double Natting.

Removed the DMZ zone in the middle and got true public IP address on teh WAN interface of pfSense and set bridge mode on the DOCSIS 3.0 Modem with Comcast and everything is happy happy now.

Moral of the story don't turn on NAT with comcast put thieir router in Bridge mode by during off NAT, DHCP and DMZ Zone.

Not the way you have your network laid out.  Honestly, re-working it really wouldn't be that painful.  You would either configure your router to pass traffic transparently, and then have your LAN interface on pfSense be 8.8.8.1/24 (I hope you're not actually using this network space on your LAN), or you could keep the network configuration basically the same and double-NAT on pfSense and your router.  Alternatively, you could advertise routes to the remote network using 8.8.8.5 as the gateway.

Each of these options has merits and drawbacks depending on the size of your network how things are set up inside it.

If you disable all packet filtering, you're turning pfSense into a straight router and it'll kill all your firewall rules.  Don't do this.

If you want to filter inside your IPSEC tunnel, create firewall rules on the ipsec tab at each end of the tunnel and filter what you want.  Remember that rules are evaluated by the interface which sees the traffic, meaning you're filtering on the receiving end of the tunnel.  If you want to stop traffic from ever making it to the tunnel, create the rules on the LAN interface with the destination network being your remote subnet.

bradenmcg,

Can you post how your PA2020 is configured for the pfSense tunnel?  I am trying to connect a PA2050 to a remote pfSense and keeping getting a timeout error.

Thanks,
Jeff

That won't work with normal routing. It doesn't handle that situation.

However you might be able to make it work if you run a routing protocol like OSPF on each node.