Yes, you can use a CARP address as the IPSec endpoint. There is an option to sync IPSec configuration in the XMLRPC Sync options on the HA Sync page.

Hello, I reconfigured the VPN with different encrypt algorithm and hash and it worked. Topic can be closed.

Excellent, "Don't pull routes" is NOT checked, so I think we'll be good to go. Thank you!

I've finally done it. @Derelict Thank You! I've actually managed to find a few ways to make it work. Learned a lot in the process. Best solution I found was: Add Phase2 tunnel between site A and B like this: site A (10.11.40.0/24) <-> site B (10.200.200.0/24) Modify Phase2 tunnel between site B and C and use NAT on it: site B (10.11.0.0/16 -NAT-Address-> 10.100.100.1) <-> site C (10.200.200.0/24). No configuration change was required on site C which wasn't an option anyway :-) Remove Outbound NAT rule @ site B that hid traffic to site C under single IP address (10.100.100.1). This rule is no longer required because source address translation is now handled by Phase2 tunnel configuration itself. Remove 10.100.100.0/24 network from site B. I no longer need this network because Phase2 B <-> C now matches my primary local subnets. Final config to summarize it for anyone with similar problem (access site C from site A via site B). LAN addresses are as follows: site A - 10.11.40.1/24 site B - 10.11.20.1/24 site C - 10.200.200.1/24 site C will accept traffic only from address 10.100.100.1 Phase 2 A <-> B Tunnel_1: 10.11.40.0/24 <-> 10.11.20.0/24 Tunnel_2: 10.11.40.0/24 <-> 10.200.200.0/24 Phase 2 B <-> C Tunnel_1: 10.11.0.0/16 -NAT-Address-> 10.100.100.1 <-> 10.200.200.0/24 Correct me if I'm wrong but my conclusion is that pfSense will not send traffic to IPsec tunnel if this traffic does not originate from network matching configured Phase2 networks even if You configure Outbound NAT for non-P2-matching subnet and translate it to match configured P2. Maybe it is obvious to some people but it wasn't for me. Before pfSense I've used Vyatta/VyOS and P2 source network evaluation took place AFTER outbound NAT was performed. Other solutions I've tested and they worked (sort of): To original configuration add Phase2 between site A (10.11.40.0/24 -NAT-Address-> 10.100.100.2) and site B (10.200.200.0/24). This way traffic coming from site A matched site's B local network used in Phase 2 tunnel between B and C. Split site's B network into 2 as @Derelict suggested: a. Split site's B subnet (10.100.100.0/24) into two (10.100.100.0/25 and 10.100.100.128/25) b. Add Virtual IP Alias for LAN @ site A (10.100.100.129/25) c. Create Phase2 between site A (10.100.100.128/25) and site B (10.200.200.0/24) d. For the servers that are located @ site A and need to access site C, I've assigned addresses from 10.100.100.128/25 subnet and created static route for subnet 10.200.200.0/24 with gw 10.100.100.129. This way servers from site A will "show up" at site B with addresses that match 10.100.100.0/24 P2 between site B and C. Other variant of 2nd solution is to use routed IPsec between A and B. Haven't actually tested routed IPsec with splitting the network but I'm positive it would work. Tested routed IPsec without splitting the 10.100.100.0/24 subnet but it didn't work. Created OpenVPN server (p2p) between A and B. It also didn't work without splitting the 10.100.100.0/24 subnet. However it did work with splitting the network like in previous solutions. Solution number 2 config for complete picture: LAN addresses are as follows: site A - 10.11.40.1/24, 10.100.100.129/25 site B - 10.11.20.1/24, 10.100.100.1/25 site C - 10.200.200.1/24 Phase 2 A <-> B Tunnel_1: 10.11.40.0/24 <-> 10.11.20.0/24 Tunnel_2: 10.100.100.128/25 <-> 10.200.200.0/24 No NAT in these tunnels. Servers @ site A that need to access site C have addresses assigned from 10.100.100.129/25 subnet and static route to 10.200.200.0/24 using 10.100.100.129 as gateway. Phase 2 B <-> C Tunnel_1: 10.100.100.0/24 <-> 10.200.200.0/24 NAT Outbound @ site B: Interface (IPsec), Source (10.100.100.0/24), Destination (10.200.200.0/24), NAT Address (10.100.100.1) Servers @ site B that need to access site C have addresses assigned from 10.100.100.0/25 subnet and static route to 10.200.200.0/24 using 10.100.100.1 as gateway. Note: This Outbound NAT @ site B is not required in order for this to work but it's requirement from our Customer who controls site C to "show up" at their end only as 10.100.100.1. Hope it will be useful to somebody :-)

Hi Konstanti6 and anyone else reading this. I setup a test environment to test VPN functionality between two pfSense instances. Works so nicely and easily, and I just cannot get sophos to play along nicely. Instead of providing more logs (as requested) I am going to ask sophos support to help out. In case of a clear and reproducable solution, I will post it here. For now I just wanted to say: kuddos to pfsense, that seems SO easy to setup a site-to-site vpn with. And thanks for the response Konstanti6.

@posto587 said in IPsec Site-To-Site pfSense <-> Securepoint: May 17 12:54:33 charon 07[IKE] <con5000|86410> received NO_PROPOSAL_CHOSEN notify error May 17 12:54:33 charon 07[CFG] <con5000|86410> configured proposals: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048 The other side is rejecting the tunnel transform proposal You are asking for: AES_CBC_128 SHA256 PFS Group 14 They will have to tell you why they are rejecting that.

I've double checked the firewall rules on both desktops, and everything is set right. If you can ping the LAN address at the other end then the tunnel is up and working. Use packet captures. Ping something on the LAN on the other side and pcap there. Do you see the traffic leaving that interface? Is there a reply? If not find out why not. Compare with a capture to the same host from the local pfSense's LAN interface. This problem is almost always 1 of two things: The default gateway on the target host is not the VPN firewall. It seems you have eliminated this since the host can ping the far side's LAN interface address so that leaves... The software firewall (think windows firewall) on the target host is not allowing connections to the target host from the foreign subnet. It could be some other local security software on the host breaking things too.

@murphster_matt What's funny about this is that I had the same problem when trying to set up a different phone, and I'd completely forgotten about this solution until you posted your comment! Thanks for reminding me!

@sugarpeter Not a clue sorry, I don’t use google authenticator.

@jimp said in DH Group 31 (curve25519) supported?: Probably wants a feature request at https://redmine.pfsense.org Alright that shouldn't be a problem :) Coming up!

Issue resolved! Believe it or not it was a f****** reboot that solved it... Probably the firewall still had some old caches or something still in it's memory...

@highc said in IPSec VPN to OpenWrt Strongswan Travel Router: Thanks for trying to help me. I tried to do what you said, i.e. setup a new site-to-site config in pfSense Look at the file on the PFSense side /var/etc/ipsec/ipsec.conf This is an example of what settings should be on the Openwrt router . These settings should mirror the settings on the PFSense (left/right) https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/configuring-a-site-to-site-ipsec-vpn.html https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/routing-internet-traffic-through-a-site-to-site-ipsec-vpn.html For example , my file ipsec.conf (CentOS server, site-to-site connection) conn es_ru_pfsense_rsa keyexchange=ikev2 authby=pubkey fragmentation = yes ikelifetime=28800s ike = aes256-sha256-modp2048,aes-sha256-modp2048! esp = aes256-sha256-modp2048,aes192-sha256-modp2048,aes128-sha256-modp2048,aes128gcm16-sha256-modp2048,aes128gcm64-sha256-modp2048! left=XX.XXX.XX.XX leftsubnet=0.0.0.0/0 leftcert=strongswan_rsa.pem leftca="C=ES, O=M, CN=e.m.org" leftid=@strongswan.m.org leftfirewall=yes lefthostaccess=no right=YY.YY.YY.YYY rightid=@pfsense.m.org rightsubnet=192.168.55.32/27 auto=add

Again, there are numerous threads around the forum already covering this in detail.