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.

Solved (I think). Turns out that not only do you have to add IPSec ports to the pfSense firewall, I had to add UDP 4500 to the AWS Security Group (AWS version of a firewall). The person who set up the Security Group had added UDP 500, but not 4500.

Yeah you almost certainly want tunnel mode there, not transport. It really depends on the mix of intended VPN clients but if I had to use IPsec instead of OpenVPN for some reason I would try to get IKEv2 working first.

@schulzie00 BINAT is not so hard. The only thing that you have to take into account is that, from the point of view of the remote site the remote net you have to supply is the one you have used in the binat field and not the original one onf the LAN interface, so your phase II configuration must use this later one and rules must apply with this. Apart from this take into consideration that there will not be any matching rules between local IP addresses (those in the LAN Net space) and binat addresses so the remote site clients would not be able to contact servers in the binat side unless you configure a NAT static translation too. Hope this helps.

Thanks for the help.

What is the solution please i have the same problem :/ ipsec_starter[35497]: configuration 'con1000' unrouted

@Mathews What do system logs show on both sides when this happens? Everything is okay on the other side? I recommend keep the default lifetimes 28800 for phase 1 and 3600 for phase 2. Does it bring up the tunnel if you ping again the remote side after 45 minutes? https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/configuring-a-site-to-site-ipsec-vpn.html Phase 1 lifetime: "The lifetime defines how often the connection will be rekeyed, in seconds. 28800 seconds is a good balance of frequent rekeying without being too aggressive." Phase 2 lifetime: "The lifetime for which the negotiated keys will be valid. One hour (3600) is a good setting. Do not set this to too high (e.g. more than about a day: 86400) as doing so will give people more time to crack the key. Don’t be over paranoid either; there is no need to set this to 20 minutes either."

@Daz22 Hi, you will need a RADIUS server and use the Framed-IP attribute and group the addresses by aliases. For a domain environment, see the answer in my thread. If you want just a simple setup, you can drop all the NPS/AD stuff there and install FreeRADIUS on the pfSense. If I remember correctly, the package allows to set IPs in the user properties.