@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.

and in 2.1.4 i am sure. Although I would like to see the pfsense side config you guys are using to compare with what I have

There is some gear out there that can do L2TP on its own for tunneling only. If the protocol run over L2TP is already encrypted, it's not a huge deal. On 2.2 to get L2TP+IPsec you setup L2TP and IPsec together using both options individually.

It looks like it is working now; had to turn off NAT on the IPSec interface because of the double NATting.  Failed to mention that client is running 2.2-Alpha an host is 2.1.4.  2.2 has a V1 or V2 option for IKE.  I was using V2 it needs to be V1.  Also, the IPSec widget on 2.2 does not report the tunnel up, when it is.  Even when the tunnels are up neither end shows a route in the routing table.

The only setting on pfSense is the NAT address entry. People have used many:1 (e.g. LAN/24 -> NAT/32 ) for connecting to other gear before, including large vendors and systems such as Verizon/AT&T for cell network backend connections. If that doesn't work with the Juniper settings, there may be something else that needs set on the Juniper side. Otherwise, try using a /24 for the NAT address/network and not a many:1 type NAT setup.