Will do. Thanks!

In that case you might check other common routing issues:

Ensure the pfSense host is the default gateway for internal machines Ensure that both sides are using unique, non-overlapping subnets Ensure that client PCs have proper subnet masks set Ensure there are no client-level firewalls preventing traffic from outside their subnet.

You may need to try packet captures on several different legs of the tunnel (LAN on each end, the enc0 interface on each end) to see if the traffic is hitting pfSense, if it's making it into the tunnel, coming out the other end, and getting passed on to the clients

thats a bad config. you are using PFS GP2 on the pfbox but in the sonicwall you dont have it checked it use it. check that box on the sonicwall and it will come alive

Kyle

Very good! That fixed my problem, 3 days now without a drop. pF on 2D3's is the only way to go lol 45 tunnels and not a single flaw now.

I thought that folders automatically should be visisble in explorer. When i connected networkunit with
automatic reconnect they became visible under my computer. I gave them a "unitletter" which i renamed and put on desktop.
I think the speed is better in the tunnel than over internet.

Now i got all function i wanted and shall go further with mobile connection!

Thanks to Jimp from the other thread, I was able to see why it was not working.  To fix, I had to change the Outbound NAT on the main side to Manual.  Then I created a new Outbound NAT rule that included the subnet from the Austin network (10.20.2.0).  Basically, I just created a copy of the default rule and changed the Source network.

Once I made this change, Voila!  Traffic from the remote side started heading out to the Internet.  Now all traffic flows thru the Main site.  It makes perfect sense why I needed to make this change, it just took a slap in the head from Jimp to point me in the right direction. :)

I have Bold 9000.
First go to Options->Security Options-> VPN and create VPN connection.
Name=ChooseAName
Gateway type="CheckPoint".
Concentrator IP address=your pfSense WAN IP
Username=does not matter
User password=put your shared secret here
IP address and Subnet mask: try to put here network range you are trying to reach (it's network behind pfSense)
All IKE and IPSec parameters to be configured to match your pfSense settings.
Save this VPN-connection.

Go to Options->Security Options->WiFi Connections and configure your WiFi connection. In VPN part of this connection entered in VPN config (ChooseAName).
That is it. First connect to WiFi, then in Options->Security Options->VPN you can activate/deactivate VPN (which is ipsec tunnel).

Just to be clear, it sounds like this:

Site A:

WAN Subnet is public, PPPoE LAN Subnet is 192.168.2.x

Site B:

WAN Subnet is private, 192.168.1.x LAN Subnet is also 192.168.1.x

Is that right? If so, that won't work. The LAN and WAN subnets must be different at Site B, and that may be part of your problem.

However, if the tunnel comes up OK, you may just be missing the firewall rules for IPsec. Go to Firewall > Rules, IPsec tab on both sites and add an allow all rule (or allow whatever you like) - be sure the protocol on the rule is 'any' and not TCP or else you can't ping over the tunnel.

jimp,  no problem on changing Chris' phone number.  It was the one he had listed on his website.

http://chrisbuechler.com/index.php?id=34

Roy…

@jimp:

There are mechanisms in place but IPsec has its quirks when working with different devices. Renegotiation is left up to the initiator, so depending on "who started it" (the tunnel) that is who needs to handle the renegotiation.

When dealing with non-pfSense devices I have often had to set "Prefer old IPsec SAs" under System > Advanced. Can you try to set that and see if there is a difference?

Thanks, I looked at what parameters I have access to configure, and found an IKE sysvar called rekey_passive, and the description says "When an IPSec or IKE SA expires, the original initiator usually initiates a rekeying negotiation. This sysvar is intended for use when interfacing with an IKE implementation that cannot initiate rekeying. For IKE v1 only."

That sounds like what you are referring to, and  IKE v1 is the "old IPSec SAs"?

I will play with that!  Thanks for the hint!

Today im in the process of rebuilding my -now-secondary- system that was running as our Primary with 1.2.3. Its VPN1401 card was working properly running 1.2.x so ill let you know if it appears to work as expected when running 1.2.3. If nothing else it would be nice to know if the vpn1401 card is the problem with the other box or if it might be something else with the other box. Ill report back later with results.

Thanks!
-E

@jimp:

It's less about the number of tunnels and more about throughput. What kind of bandwidth are you dealing with?

Odds are you'll end up saturating the PCI bus of that accelerator card at reasonable speeds. Those cards are meant to offload the task on lower-end hardware, in the several hundred MHz range, nowhere near what you have.

I'd run tests without the card installed and see if you still have trouble.

Are you using IPsec or OpenVPN?

If FreeBSD supports that crypto chip, it should be used automatically by IPsec, but there isn't a real good test for that.

For OpenVPN, you can test with and without the cryptodev settings, and also with OpenSSL at the CLI:

See here:
http://doc.pfsense.org/index.php/Are_cryptographic_accelerators_supported

If you are just seeing the "cryptosoft0" line, however, that is not an accelerator.

I am now trying a Sonicwall on the remote side and it's doing the same thing, so something is amuck on the head end.  The Sonicwall has a special checkbox to tunnel all traffic over the VPN, including Internet traffic.  It creates the appropriate 0.0.0.0/0.0.0.0 match over the VPN so everything is definitely going over it, but I'm not getting an Internet (only internal) connectivity.  At this point, I don't believe it was a pfSense issue.

That isn't really an error, per se, but a warning. It is normal if you are using Aggressive mode, if I recall correctly.

Your problem is likely elsewhere, not with that message.

You should be pinging from a computer connected LAN A to computer connected to LAN B (or vice versa) not from one pfSense box to another.

This time including IPSEC configs

Pfsense 1.3 imbedded

Phase 1 Proposal
negotiation > main
identifier > My IP address
enc alg > AES-256
hash alg > SHA1
DH grp > 1
DPD
Lifetime 1800
Auth Method > RSA Sig
cert > present
Key > present

Phase 2 Proposal
Protocol > ESP
Encr alg > AES-256
Hash Alg > SHA1
PFS Key Grp > 2
Lifetime 1800

IPSecuritas

Phase1
Life > 1800
DH Grp > 768 (1)
Enc > AES 256
Auth > SHA-1
Exch > Main
Proposal Check > Obey
Nonce Size > 16

Phase 2
LIfetime > 1800
PFS Grp > 1024 (2)
Encrp > AES 256 AES 192 AES 128
Auth > HMAC SHA-1

ID

Local > Cert
Remote > Address

Auth Method : Certificates

switch to site-site OpenVPN and I think you will see your VPN problems disappear.   I love IPSec but I haven't found it to be reliable unless both ends have a static IP.  site-site OpenVPN has been rock solid with one end static and the other end dynamic.

Roy…

:-[ OK… I figured it out. I'm glad I didn't waste anyone else's time with this (I hope). The SonicWall apparently has hidden associated NAT rules that are added when a new VPN is created. The NAT rule I made seemed to mess things up. I just deleted that and most seems to work now.