haven' tried it. thing is if I enable IPSec VPN and keep trying, the users cant use IPsec clients. so i have to do it out of ours. if it is up n running, they don't need IPsec clients. cheers

What do you have on your Phase1 proposal checking?  If it's 'default' or 'strict' try changing it to 'obey'. From man racoon.conf(5): proposal_check level     specifies the action of lifetime length and PFS of the phase 2 selection on the responder side. The default level is strict If the level is; obey         the responder will obey the initiator anytime.     strict         If the responder's length is longer than the initiator's one, the responder uses the initiator's one. Otherwise it rejects the proposal. If PFS is not required by the responder, the responder will obey the proposal. If PFS is required by both sides and if the responder's group is not equal to the initiator's one, then the responder will reject the proposal.     claim         If the responder's length is longer than the initiator's one, the responder will use the initiator's one. If the responder's length is shorter than the initiator's one, the responder uses its own length AND sends a RESPONDER-LIFETIME notify message to an initiator in the case of lifetime. About PFS, this directive is same as strict     exact         If the initiator's length is not equal to the responder's one, the responder will reject the proposal. If PFS is required by both sides and if the responder's group is not equal to the initiator's one, then the responder will reject the proposal. The way I interpreted this for my troubleshooting was that if 'default/strict' are in force and the remote end reboots, the local end will ignore then incoming IKE until it own key lifetime expires.  Whether that's right or not, it worked for me and the Cisco ASA I was having as spat with!

Dhatz: With the tunnel saturated (currently pushing about 6 Mbps through it) I'm able to get an average of 79 ms which isn't too bad.  There are 14 hops between us and pinging outside the tunnel to the routers WAN IP gives me an average of 70 ms so the tunnel has little effect on my ping which is great. The remote site is using an Alix.2D13 (http://store.netgate.com/-P40.aspx) board.  And now that you mention it that site does say it comes with an OCF encryption accelerator.  I enabled the Crypto option as you suggest and ran the test again (mind that the tunnel is active so the results will be a little scewed) and got this: type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes md2                329.17k      708.05k      996.65k     1118.89k     1148.68k mdc2               549.04k      637.85k      659.26k      663.64k      655.26k md4               2289.13k     7854.97k    21920.32k    40305.54k    52503.86k md5               1753.12k     5772.70k    15143.99k    26220.17k    32645.97k hmac(md5)         2004.90k     6419.02k    16479.07k    26775.02k    33190.16k sha1              1475.25k     4074.76k     8455.58k    11490.71k    12844.19k rmd160            1468.63k     4096.69k     8569.98k    11790.03k    13403.30k rc4              22092.32k    26689.23k    27538.92k    27871.09k    27791.23k des cbc           5988.65k     6292.11k     6409.92k     6530.34k     6423.43k des ede3          2176.81k     2194.97k     2241.66k     2237.70k     2205.02k idea cbc             0.00         0.00         0.00         0.00         0.00 seed cbc             0.00         0.00         0.00         0.00         0.00 rc2 cbc           2854.43k     2940.76k     3002.53k     2941.11k     2999.06k rc5-32/12 cbc    16558.64k    19628.17k    20311.70k    20462.82k    20403.23k blowfish cbc      9999.56k    10856.40k    11422.71k    11376.40k    11248.24k cast cbc          8665.50k     9402.30k     9916.11k     9865.39k     9650.14k aes-128 cbc       5381.94k     5666.46k     5714.98k     5762.96k     5767.86k aes-192 cbc       4734.72k     4987.94k     4974.26k     5053.12k     5030.78k aes-256 cbc       4266.21k     4379.63k     4440.91k     4463.24k     4461.63k camellia-128 cbc     5725.98k     6261.62k     6313.85k     6278.99k     6223.47                  k camellia-192 cbc     4604.60k     4865.82k     4862.31k     4924.04k     4892.54                  k camellia-256 cbc     4502.63k     4857.29k     4870.93k     4862.82k     4926.56                  k sha256            1007.89k     2288.96k     3873.00k     4783.14k     5079.48k sha512             390.13k     1567.99k     2360.24k     3260.45k     3649.77k aes-128 ige       5449.03k     5863.30k     6074.94k     6049.77k     6101.76k aes-192 ige       4723.68k     5036.47k     5225.38k     5217.74k     5220.90k aes-256 ige       4214.93k     4501.45k     4583.63k     4629.43k     4645.62k                  sign    verify    sign/s verify/s rsa  512 bits 0.006918s 0.000674s    144.6   1484.0 rsa 1024 bits 0.031551s 0.001653s     31.7    605.0 rsa 2048 bits 0.179939s 0.004950s      5.6    202.0 rsa 4096 bits 1.113613s 0.016874s      0.9     59.3                  sign    verify    sign/s verify/s dsa  512 bits 0.005288s 0.006044s    189.1    165.5 dsa 1024 bits 0.014283s 0.016861s     70.0     59.3 dsa 2048 bits 0.045229s 0.053605s     22.1     18.7 I'm not sure I see much of an improvement, at least for that test.  Secondly, I switched over the tunnel to be as follows: IPSec Site-to-Site PH1: Auth:  Mutual PSK Neg: main Policy: Default Proposal: Default Enc: AES (128 bits) Hash: SHA1 DH: 2 PH 2: Proto: ESP Enc: AES (128 bits) Hash: SHA1 I'm not seeing much of a difference in the tunnel.  Is this the part in ADVANCED -> SYSTEM TUNABLES that I would change and if so what are some options that I should try?  Also, would I change this on both sides or just the remote side (As I have other VPNs to other sites as well that I don't want to effect yet)? net.inet.tcp.recvspace Maximum incoming/outgoing TCP datagram size (receive) default (65228) net.inet.tcp.sendspace Maximum incoming/outgoing TCP datagram size (send) default (65228) I really appreciate everyone's help and I'll do my best to provide the data you need to help me.  I hope this helps other in the future as well!

Possible but not likely, it would have to only block the ESP traffic in one direction. Kind of an odd behavior.

It's in the system log (Status > System Logs, or clog /var/log/system.log) If the line numbers do not match up, then it is likely an old error that hasn't been cleared.

Yes, the response to the other post is still valid. You can't predict/assign IPs to specific IPsec users. If you need that, OpenVPN would be a better choice.

Workaround! Just found due to another post that this is fixed by http://forum.pfsense.org/index.php/topic,57995.0.html Frustrating to say the least

@richardstubbs: Apply the "fudge" outlined here http://forum.pfsense.org/index.php/topic,57995.0.html Ah - that fixed my issue at http://forum.pfsense.org/index.php/topic,59343.0.html

I have solved my dilemma, just upgraded to 2.02.  Thanks everyone for reading.

@bellera: @redflag237: I tried adding a Gateway for 192.168.178.0/24 on 10.178.1.62. Ping is ok for this (Green in Dashboard). I tried to add a route for 192.168.178.0/24 with this Gateway, no success. Don't add gateways or routes. Just specify local & remote networks. When a tunnel is established, virtual interface acts similar to a physical interface. Add a rule for your LAN interface allowing (any) traffic to the remote network and using default gateway (pfSense should route it, you don't need policy routing here). Remember to put your rule first than others that could interfere it. Thank you so much. Tunnel is up and running. Unfortunately the Tunnel is only working between my Network specified in Phase 2 and the FritzBox network. There is no routing done on pfsense side. FritzBox is configured to accept the other subnets as source on the tunnel. How do i have to configure the Back-Route on FritzBox to get my routed subnets working? Does there have to be a virtual IP that can be used as Gateway for the tunnel? Maybe it is more useful to use NAT from Subnet X to VPN-enabled subnet on pfsense? Best regards, redflag237

I'm just the moderator for the Spanish sectior. I don't have access to doc.pfsense.org I'm sorry! Josep

Thanks guys. Problem solved. i just for found i made a mistake by doing TCP port forward in cisco router and follow the guide to using the udp in openvpn seting. any way, thank you.!!

I've tried all of those things, I don't think it's a windows SMB issue since it worked before the router change. I also enabled the no-df option which didn't make a difference either. It's just SMB as far as I can tell though, other protocols work fine. Edit: And it does work fine locally, just not over the ipsec vpn… Edit 2: face f*%king palm.... windows firewall. Somehow it was turned on again on the problem computers. I don't know how it got re-enabled, when, or why it worked on my old vpn. But I don't care anymore, I've been tearing my hair out for 2 days with this. Thanks for the help guys, guess it wasn't a pfsense issue. It was the only thing that changed on my network so I assumed it was.