The best thing to do would be to figure out why it's disconnecting and correct that. The logs would be helpful with that. Failing that, you can use the ipsec up and ipsec down command on 2.4.x to up/down single tunnels, for reference look at how it's done when clicking the buttons on on status_ipsec.php https://github.com/pfsense/pfsense/blob/RELENG_2_4_4/src/usr/local/www/status_ipsec.php#L54 On 2.5.0 it's similar but there it uses swanctl --initiate and swanctl --terminate

@coreybrett PF uses an enc0 interface to filter all ipsec traffic. (classic ipsec tunnel, VTI). em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM> ether 08:00:27:7e:d9:81 hwaddr 08:00:27:7e:d9:81 inet6 fe80::a00:27ff:fe7e:d981%em1 prefixlen 64 scopeid 0x2 inet 10.3.100.1 netmask 0xffffff00 broadcast 10.3.100.255 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex>) status: active enc0: flags=41<UP,RUNNING> metric 0 mtu 1536 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> groups: enc Therefore, all filtering rules are created on the IPSEC tab ( including for VTI).

@AceStrider1 said in Foward all public IP traffic to a remote server via IPsec: 10.30.10.31 Hello To solve this problem, I would recommend that you use a routed connection type. For example, OpenVpn, GRE over IPSEC or VTI. Then it will be possible to redirect all traffic coming on 64.64.64.26 to the server 10.30.10.31. It is necessary to use NAT OUTBOUND on the tunnel interface because otherwise the traffic from 10.30.10.31 will return through 32.32.32.32. This is a feature of the PF implementation ( the reply-to function does not work on virtual interfaces) Here is an example of traffic forwarding and using outgoing NAT ( Linux Iptables) through a GRE tunnel. 37.XXX.YYY.ZZZ = 64.64.64.25 192.168.1.230 = 10.30.10.31 10.10.100.2 = internal ip address of the GRE interface. prerouting = port forwarding postrouting = NAT OUTBOUND *nat :PREROUTING ACCEPT [0:0] -A PREROUTING -d 37.XXX.YYY.ZZZ -p tcp -m multiport --destination-port 25,465,587,993 -j DNAT --to-destination 192.168.1.230 :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A POSTROUTING -o tun100 -p tcp -m multiport --destination-port 25,465,587,993 -d 192.168.1.230 -j SNAT --to-source 10.10.100.2

Issue resolved, It seems that AES-256 doesn't translate NAT/BINAT with DH-Group 2 I changed the DH-Group to 14 and the issue solved.

Encountered the same error messages and symptoms. I had misconfigured the PFS on one of the Phase 2 connections. Setting both to the same option resolved the issue.

What I want to do is to remove the requirement for my PC at home to have to connect manually as a client when I want to access my work's VPN. Doing so without having (written) permission to do so from your company or institution would most certainly breaking several guidelines or compliance rules. And I can tell you that network/security/IT guys wouldn't be very happy with you if they would find out, that you simply hooked your full home network into their corporate network. You simply don't. Had to do that 15y ago for a CEO. He nearly wiped out his company network by his son running amok on his private network that he forced us to hook into the corporate one. Simply no.

It is a pretty old post but would like to add what I did recently (not perfect but working to some level) feedback would be nice to make it perfect. What I did is mentioned below. ON LOCAL SIDE: Create a gateway group on the Pfsense i.e GW1_GW2 change priority to Tier 1 & Tier 2 respectively. Assume Tier 1 GW IP is 10.10.10.10 Assume Tier 2 GW IP is 20.20.20.20 Local Subnet: 172.16.0.0/24 Create Phase1 & Assign GW1_GW2 Gateway as Interface to IPSec GW1_10.10.10.10 (Primary-Alive) GW2_20.20.20.20 (Secondary-idle) Add Phase 2 Local Subnet --> 172.16.0.0/24 <--- Remote Subnet : 192.168.0.0/24 ON Remote Side: Configure Two tunnels Phase1 for 10.10.10.10 --> Phase2 Local Subnet: 192.168.0.0/24 <-- Remote Subnet 172.16.0.0/24 (Primary-Alive) Phase1 for 20.20.20.20 --> Phase2 Local Subnet: 192.168.0.0/24 <-- Remote Subnet 172.16.0.0/24 (Secondary-idle) Now the tunnel will establish using Tier1 IP as Peer IP, if the Tier1 Connection is down, it'll establish using Tier2 IP. I have tested this scenario, it works fine, it Failover to Tier 2 IP but when the Tier2 IP is also down OR the Tier1 IP is back online then it won't switch back to Tier1 IP. to force change I have to restart IPSec Service. is there any way to Force IPSec Service reload upon disconnection?

@Konstanti Thank you Konstani. The problem is resolved with -Enable Replay Detection checked -Enable Perfect Forward Secrecy checked -Auto-Negociated checked

I finally got it to work, roughly these are the settings ( I know they are the least secure - but they work) P1: 3des,md5, dh 2 P2:3des,md5.dh2,esp aggressive yes DPD: yes monitor MUST be used. autokey ike advanced: check vpn monitor+optimized+rekey set proxy-id to class C networks

@awebster Hello! Thanks for the input! I've checked the Phase 2 configuration and they are using a lifetime of 3600, as per AWS configuration file. ! #2: IPSec Configuration ! ! The IPSec transform set defines the encryption, authentication, and IPSec ! mode parameters. ! Category "VPN" connections in the GovCloud region have a minimum requirement of AES128, SHA2, and DH Group 14. ! Please note, you may use these additionally supported IPSec parameters for encryption like AES256 and other DH groups like 2, 5, 14-18, 22, 23, and 24. ! Higher parameters are only available for VPNs of category "VPN," and not for "VPN-Classic". Expand the VPN configuration clicking in "+" and then create a new Phase2 entry as follows: ***a. Disabled :uncheck b. Mode : Tunnel c. Local Network : Type: LAN subnet Address : ! Enter your local network CIDR in the Address tab d. Remote Network : Type : Network Address : ! Enter your remote network CIDR in the Address tab e. Description : Amazon-IPSec-vpnxxx Phase 2 proposal (SA/Key Exchange) a. Protocol : ESP b. Encryption algorithms :aes128 c. Hash algorithms : hmac-sha1-96 d. PFS key group : 2 e. Lifetime : 3600 seconds***

Hi I have the same question. Did you get any solution for this problem? Stefan

@jimp You were exactly right, the issue was on remote end. Thank you very much for your help, it's good to have such experts like you here. Good luck you to you. SOLVED!

@gchialli said in Phase 2 : "invalid HASH_V1 payload length" error: I apologize for replying to this old topic, but I'm having the same issue I think. I'm on 2.4.4-p1. I have already bumped the max_ikev1_exchanges value to 50, but the errors keep happening, and the tunnel restarts every 2 minutes. @cukal Have you been able to find a solution for this? Thank you Hello, Just wanted to update the forum that my issue got resolved. It was caused by one proxy-id configured with the wrong prefix-length on the other side. Thanks

What is in Diagnostics > States matching ICMP before you start a new ping attempt? Have you tried killing/resetting states between tests? There is nothing special about ICMP vs TCP or UDP in the rules. They are all treated equally when it comes to evaluating the ruleset. You may also need to look at the detailed output from pfctl -vvss for the ICMP states matching your ping and compare them with the related info in pfctl -vvsr to see which rule(s) allowed the state to be created.