We need more info… What do the filter logs say? Any blocked packets? From the machine you are trying to do the https session try a telnet ROUTER_IP 443 (Windows) or telnet ROUTER_IP:443 (Unix/Linux). Do you get a connect? Have you checked both firewalls? Ruleset? What are your rules?

There are numerous howto in pfSense's doc wiki, it's pretty straightforward and in my opinion you're better of using OpenVPN, one particular URL of interest to you is –> http://doc.pfsense.org/index.php/VPN_Capability_OpenVPN

You can't NAT on IPsec tunnels like that with pfSense. There was a bounty to add that feature (http://forum.pfsense.org/index.php/topic,14650.0.html) but it was withdrawn before it could be completed. You'd have to renumber their network to 192.168.10.x to make it work.

Does anyone have any ideas? I do not want to go back to that old netscreen if this is a simple fix! Thank you!

No, you can't route traffic quite the same way with IPsec as you can with OpenVPN. With mobile tunnels this is a little more relaxed, but you still need to specify these subnets for the tunnel on the client side. If these networks are not locally reachable by pfSense you will also need to add manual NAT rules which will NAT the traffic from your mobile client IP(s) out the pfSense WAN. This is a little better in 2.0 where you can specify to send a list of accessible networks to the IPsec client, but you still can't specify arbitrary subnets.

After reviewing my previous input, I glanced over the pfSense Definitive Guide and found this: "Static routes will not route traffic over an IPsec connection, never configure static routes for any IPsec traffic except in the case of traffic initiated from pfSense itself." And that "The only option if the subnets are not contiguous is to create parallel IPsec tunnels, 1 for each subnet." The quoted info above can be found in section 13.4.3 (Routing multiple subnets over IPsec) of the Definitve Guide. That said, cosolidating your existing class A and C subnets seems to be the only solution.

:) work fine.. tnks I ping only ip dhcp on remote network, and i dont ping de fixed ip…

FIXED.. I really should have thought of this sooner but untill I saw the packet was addressed wrong it never clicked in my head. The problem was I run VMware Workstation for devlopment. The NAT driver was playing havoc. I still don't really understand what was happening, but the VirtualNIC assigned to NAT just so happen to be 192.168.190.1. So I'm guessing somehow it was changing the source/destination of the packets meant for my 192.168.10.10 interface. Figured I'd update this incase anyone ever pulls their hair out like I was.

In that other thread, Ermal seems to imply that it is mainly up to racoon (part of ipsec-tools) to handle this, but it will take some C coding to get it done. I don't understand the source of ipsec-tools well enough to comment further (and not for lack of trying, I've tried editing/patching their source for other reasons before and it wasn't a fun experience, mainly due to my lack of C knowledge.)

I did not find the solution for the error but, it was not a problem to stablish the tunnel. VPN IPSEC works even with this error on logs. Even I found a way to communicate a LINKSYS WRV210 with pfsense, here is the detailed conf: http://sites.google.com/site/sinindex/networking/integracionipsecentrepfsenseylinksyswrv210 Thanks all for the help.

Personally, I've not seen polling ever help on an ALIX. I haven't tried a Hifn card though. I think cmb said he was able to get >30Mbit of IPsec on ALIX with 3DES (and DES, AES, and AES 256) I don't think he had polling enabled when he did the tests, but I'm not 100% sure on that.

Create a static route for the endpoint of the tunnel with as gateway the WAN you want to use. example: WAN1: 10.0.1.2/24 Gateway 10.0.1.1/24 WAN2: 10.0.2.2/24 Gateway 10.0.2.1/24 Endpoint1: 192.168.1.1 Endpoint2: 192.168.2.1 For traffic to endpoint1 on WAN1 you dont have to do anything special. For traffic to endpoint2 on WAN2 you have to create a static route for: 192.168.2.1/32 to 10.0.2.1

@fabioc: Seems like rekeyforcevpn.inc is no longer available, could anyone kindly post it somewhere else? Because it did nothing but generate a broken configuration, so it was removed. It's also not needed.

Widows is using the same ports. In the logs on pf sense, I can see 4500 and 500 being passed to the windows box. Basically, what this comes down to, can the pf sense pass-through IPSEC/L2PT vpn requests. It seems it will do IPSEC/L2PT no issue at all, but when i want to use a pre-shared key, it dies. Its possible this could be because of NAT-T? I am not very good at this stuff, but I am trying. Thanks for your quick reply. -Shane