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.

Ok… You're in an exception and this is not a security hole.
If you use only "any" as source, it could be a security hole but not with authentication.

BTW, good news your tunnel is working.

Same here. Would love to know what it means, even if it is benign.

I think a second tunnel is the only way to make this work.  also, 2.0 now supports multiple P2 tunnels.

Roy…

I believe the phase 1 lifetime should be larger than the phase 2 lifetime.  also, have you tried "Prefer old IPsec SAs" under "System: Advanced functions" ?

Roy…

IPSEC being set up will handle the routing properly between the two protected subnets.

I have a similar setup and am having the exact same problem…anyone out there have suggestions?

Ok, just tried it with a 1.2.3 Release box and I get the same story!