Performance depends on the CPU that it has available.

Stability would be more up to the Sonicwall sides than pfSense.

We've had people running 300+ tunnels on pfSense before without issue (I believe they were almost entirely Draytek routers on the other side). It's not a problem with pfSense in general, but might be with your specific implementation.

L2TP+IPsec is not officially supported yet. It will be supported in 2.2.

I have made it work for Android before on 2.1.x but I don't recall the specifics. I think I at least edited out that input validation you hit.

Hi
Seem to remember that i had this issue the first time i used Pfsense.
Resolved by changing Phase 1 proposal, Negotiation mode to Main
And Policy Generation to Unique
Enable DPD

I also noticed that you are using 3g connection, in Australia the providers commonly do not provide a routable IP on 3g connections, you must request an additional feature to get a routable IP.
If the IP of the 3g device is not routable i have found the IPsec does not work properly.

Hope this helps.

regards
markl

@rooty:

My IPSEC vpn  tunnel is not active if there is no traffic , is this normal?

Is there a way to keep it active without needing the traffic?

thanks in advance

its normal,

Here you go:

Internet Protocol Security (IPSec) uses IP protocol 50 for Encapsulated Security Protocol (ESP), IP protocol 51 for Authentication Header (AH), and UDP port 500 for IKE Phase 1 negotiation and Phase 2 negotiations. UDP ports 500 and 4500 are used, if NAT-T is used for IKE Phase 1 negotiation and Phase 2 negotiations

but I'd recommend you remove those ciscos and use pfsense as the gateway,

Hi,

Since I'm dealing with a similar problem I'm digging through the forum.

AFAIK, your problem could be solved as cmb suggests in this post: https://forum.pfsense.org/index.php?topic=79057.0

You need additional phase2 settings on both tunnels:

Local            Remote 192.168.0.1 <--> 192.168.2.1             <--> 192.168.1.1

and then

Local            Remote 192.168.1.1 <--> 192.168.2.1             <--> 192.168.0.1

Test the settings and take my advice with a grain of salt.

Cheers,
– Enrico

This is not about VPNs, not even pfSense or Samba, but basic Windows networking. On an NT style domain, PDC discovery is made through NetBIOS requests. So it will work "right away" only within the same subnet. For it to work on other subnets (no matter how they are connected), you need to set up Samba also as a WINS server and point all clients to it on their WINS configuration.

Regards!

IPsec failover needs dynamic DNS, so you set the local interface as a gateway group, and on the remote host you set the destination to the dynamic DNS host you have tied to the gateway group. Of course, you need to be able to specify a resolvable host instead of an IP on the other side, and also make sure that you don't have issues with cached DNS responses and stuff alike (no idea how Juniper handles this).

For example, I have implemented failover IPsec between pfSense and MikroTik routers by setting a script on the MikroTiks that resolves the dynamic DNS entry every minute and updates its IPsec config whenever necessary (pretty much what pfSense does behind the scenes).

Regards!

I'm wondering if this is a bug.  My phase 2 configuration works when phase 1 is PSK+XAuth.  The same phase 2 definition does not work when I change phase 1 to RSA+XAuth.  I can see phase 1 complete successfully and my user authenticates, but phase 2 fails with…

Jul 23 22:00:35 racoon: [Self]: INFO: respond new phase 2 negotiation: hh.hh.hh.hh[4500]<=>cc.cc.cc.cc[33593]
Jul 23 22:00:35 racoon: ERROR: failed to get sainfo.
Jul 23 22:00:35 racoon: ERROR: failed to get sainfo.
Jul 23 22:00:35 racoon: [[i]cc.cc.cc.cc] ERROR: failed to pre-process ph2 packet [Check Phase 2 settings, networks] (side: 1, status: 1).

If the phase 2 works with a psk phase 1, shouldn't it also work with an rsa phase 1?

Firewall rules for IPsec tunnel?
Routing issue?

Can you access any other resources (fileserver via smb etc.) through the S2S tunnel?

On a whim, I changed Policy Generation and Proposal Checking to Default and Encryption to Blowfish on both sides.  Tunnel's now showing up, but traffic's not routing.  I have an IPSec F/W rule allowing any/any on both F/Ws.  If I'm not mistaken, the Local Network and Remote Network fields on the IPSec Phase 2 configuration create a routing table so that if I try to access addresses on Site B from Site A (and my pfSense is my default gateway), it knows to route the traffic through the tunnel, right?  Should I expect to be able to reach my pfSense on Site B from Site A using the IP address of the LAN Interface?  I can when I VPN client to site, but not site to site.

Thoughts?

HA within the VMs is always better than hypervisor-level HA, where you can cluster anything inside the VM it's best. Hypervisor-level HA most always reacts slower for failover (in pfSense scenarios at least), and it does nothing for you with upgrades or other maintenance needs within the VM. Most people don't bother with any kind of HA on the VMs for pfSense, they just setup their environment as such that the primary and secondary firewalls are always on different physical hosts.

To clarify a bit - generally people do have the VMs set to start on another host if their host dies, one might consider that a form of "HA", I was more referring to features in certain hypervisors where the VM can run simultaneously on two physical hosts and quickly pick up if one host fails. That level of HA is a waste of hardware resources in most all cases IMO.

@cmb:

It's odd because of the way it has to work. It has to match pre-NAT for the traffic to hit the portion of the kernel that's processing the IPsec. But the NAT portion is the only thing you're presenting on the P2 to the remote end. So it has both, hits pre-NAT, gets NATed, gets sent out.

You don't need or want NAT in this case though, just add another phase 2 on both ends matching the tunnel network source.

I'm lazy, so I do want to NAT. :)

The remote end has a box terminating the tunnel, but it is not the default route.  So if I wanted to use the OpenVPN block without NAT, I'd have to do another round of static route wrangling to get the return traffic pointed at the remote IPSEC gateway instead of the default internet gateway.