Yeah like @michmoor is mentioning, I'd double check the config on both sides for Phase 1 and 2 and be sure they are identical.

If that still doesn't work then I'd dig deeper on the deleting SA issue mentioned by @Konstanti

Might also be worth checking to be sure the Fortigate is fully updated so there isn't a chance for some old bug.

Tried to create a 1:1 NAT, but still not working

@mcury It was a missing firewall rule - now working fine.

@ethan-103
You can do this with BINAT for sure, but this requires a policy-based tunnel.

With VTI you can configure a NAT 1:1 to achieve this.

For example 10.0.20.0/24 would nat to site A 172.16.5.0/24 ( 10.0.20.100 = 172.16.5.100)

For this example you have to add a NAT 1:1 rule to the VTI interface at A, where the "External subnet IP" is 10.0.20.0 and the "Internal IP" is type Network > 172.16.5.0/24.

Update: Wifi calling seems to work with no outbound nat rules other than the default enabled, however I can only get it to actually use it when I put the phone in a faraday cage that blocks cell, or airplane mode. I don't know if this is something specific with my carrier, or my Pixel 8 pro software. I did test with and s21 and it didn't use it until I did the airplane mode and enable wifi thing. Not sure if it is preferring LTE instead of wifi because of how strong our LTE is in our area, or if this is a cause of a misconfigured fire wall. Still having a bit of a head scratcher at this one, especially because I went into settings and told it to prefer wifi over LTE, but who knows.

@Dimitriy46 the P2 needs to exist on both ends, and you may have that. I would also try to include the entire /24 in a single P2 and see what happens. I have a connection with an ASA where they have multiple P2 for the same subnet, but I just have a /24 and it figures it out.

@Bot
That's nothing that could be effected by pfSense or the VPN. It might rather be that the destination server is blocking access from outside of the local subnet.

@user1089082098 If u can, send me a message and we see if we can help u.

Confirmed this is fixed in 23.09.1-RELEASE

As a follow-up, here is how I got it working.

I am using OpenLDAP and FreeRADIUS on FreeBSD 14. I'm not documenting here how to get LDAP authentication working with FreeRADIUS, I'm presuming that is already done. Additionally, my LDAP schema has all users under the name

ou=people, ou=domain, ou=com

and groups in

ou=groups, ou=domain, ou=com

I do not have memberof enabled. I'm using MSCHAPv2 authentication in pfsense's RADIUS configuration.

In /usr/local/etc/raddb/mods-enabled/ldap use these settings in the "group" section

base_dn = "${..base_dn}" filter = '(objectClass=posixGroup)' scope = 'sub' name_attribute = cn membership_filter = "(memberUid=%{%{Stripped-User-Name}:-%{User-Name}})" cacheable_name = 'yes'

In /usr/local/etc/raddb/sites-available/default add this in the "post-auth" section

update reply { Class += "%{exec:/bin/sh /usr/local/etc/raddb/ldap_fix.sh %{control:LDAP-Group[*]}}" }

The exec module is used. Ensure that in /usr/local/etc/raddb/mods-available/exec, "wait" is set to "yes"

wait = yes

Finally, I used tr to convert the comma-delimited list of groups in "%{control:LDAP-Group[*]}" to semi-colon delimited. The file /usr/local/etc/raddb/ldap_fix.sh looks like this

#!/bin/sh # # turn comma-delimited list of groups into semi-colon delimited list of groups # echo "${1}" | tr "," ";"

Using the pfsense authentication tester (Diagnostics > Authentication ) I can now see the list of groups users are a member of. Note that the groups need to also be present in pfsense (System > User Manager).

Confirmed this is fixed in 23.09.1-RELEASE