Just to answer my own question: I abandoned the plan to do this via IPsec. I now used OpenVPN and it works: define site-to-site connections to your offices and a roadwarrior setup for your mobile devices.

Iam not 100% sure how your setup are configured but you must be close if you can ping stuff.

Try play with the iperf between ipsec client and lan pc and see how that works out. Maybe its an MTU fragmentation issue you are seeing and clamping the ipsec packets to something like 1450 with MSS clamping in the ipsec advanced tab could help.

Use the firewall and ipsec log and try to figure out why packets are not showing up in the package capture.

PS Just tested with my example setup and a http web server on the lan pc. And the client can without problem load it.

I'm resurrecting this old thread because we've stumbled upon an identical situation (i.e. we need to NAT traffic from OpenVPN clients directed to a remote IPSec network).

As far as I can tell nothing has changed up to and including pfSense 2.4.x: can anyone confirm that it still is not possible in any way to NAT traffic coming in from OpenVPN clients with destination on a remote IPSec network?

(please do note that I cannot add another IPSec P2 to IPSec for the OpenVPN subnet)

thank you all.

All,

After much playing around, this was a Windows 10 VPN client configuration issue.

In Settings -> Network & Internet -> VPN, click on the VPN connection, then click on Advanced Settings and change VPN Proxy Settings from "automatic" to "none"

Hopefully this helps some other folks.

Thanks.

James

NM, added a floating firewall rule from LAN to remote network and added to tp-of-list and working fine now.

Thanks

Known issue:

https://redmine.pfsense.org/issues/8003

https://redmine.pfsense.org/issues/7856

https://redmine.pfsense.org/issues/6335

Found it in /etc/pfSense-rc.

Oh, that's too bad. At least there's that yet to give me hope. 🤕

Thanks!

I ended up manually editing /cf/conf/config.xml to achieve what I want, just copied the relative code and changed the ikeid in phase 1 and 2 and uniqid in phase 2 , after that I was able to use the  pfsense GUI again.
I now can connect from android, windows, and apple devices using different authentication methods.

https://forum.pfsense.org/index.php?topic=138987.msg761370#msg761370

@dobler:

I figured it out. In my case it was a vpn configuration issue. Make sure in phase 2 that you use 0.0.0.0/0 for local network if you want to access traffic outside.

Just want to say I found this thread on Google and after searching for like 2 hours this is what fixed my problem.

@NogBadTheBad:

Just had a play you can bind iperf to an ip address via the console using -B

[2.4.1-RELEASE][admin@pfSense-vm1.localdomain]/root: iperf -B 10.0.1.1 -c 10.0.2.1
–----------------------------------------------------------
Client connecting to 10.0.2.1, TCP port 5001
Binding to local address 10.0.1.1
TCP window size: 64.2 KByte (default)

[  3] local 10.0.1.1 port 2344 connected with 10.0.2.1 port 5001
[ ID] Interval      Transfer    Bandwidth
[  3]  0.0-10.0 sec  152 MBytes  127 Mbits/sec
[2.4.1-RELEASE][admin@pfSense-vm1.localdomain]/root:

[2.4.1-RELEASE][admin@pfSense-vm2.localdomain]/root: iperf -B 10.0.2.1 -s
–----------------------------------------------------------
Server listening on TCP port 5001
Binding to local address 10.0.2.1
TCP window size: 63.7 KByte (default)

[  4] local 10.0.2.1 port 5001 connected with 10.0.1.1 port 2344
[ ID] Interval      Transfer    Bandwidth
[  4]  0.0-10.0 sec  152 MBytes  127 Mbits/sec

I get "Can't assign requested address" if I try that.

Really this is not a IPsec VPN problem, VPN Itself working good because I see ICMP packets travels from one interface side to other interface side at the end of tunnel.

Yesterdat I'll figured it out because when I added NAT portfowarding rule on IPsec  and virtual IP om MODEM interface for ICMP, then after commit I glad to see ping travel back on my admin pc station.
ICMP packets roadmap like below:
from 192.168.2.236 ping to 192.168.0.1 > echo request routed at  192.168.2.1 (pfSense gateway) under VPN tunnel.
from remote pfSense router  VPN enpoint  the echo request route to 192.168.0.1 but for a kind of  behavior  I dont'know the port fowarding nat rule translate ICMP ECHO request from 192.168.2.236 to 192.168.0.99 at the MODEM interface.

Packets ICMP ECHO request now will end to 192.168.0.1. and it will reply correctly sending ICMP ECHO reply back to 192.168.0.99.
So at this point pfSense router I guess made auto rule for NAT  back the ICMP ECHO reply  to my admin station 192.168.2.236 previously triggered by NAT portfowarding.

This works only with ICMP traffic type, TCP traffic not work ame as I described. I just decided to write new thread under NAT forum section for sekking to figure out enough about NAT LAN TO LAN translation for IP address, I guess to do with 1:! NAT But I'm not fully understand how it works at this time.
https://forum.pfsense.org/index.php?topic=139240.0
A side note, I unable to dump, (packet capture) the ICMP traffic under MODEM interace + NAT portfowarding rule. simply  all left blank!! this is very strange for my opinion.

@barnettd:

I thought it might be a cache or browser issue, but its the same in IE, Chrome, and Firefox. Anyone else experiencing this?

Confirmed. -> https://forum.pfsense.org/index.php?topic=139163.0

It is quite a complex thing to do if you are not used to IT.  Have you followed the L2TP instructions in the PFSense Book?  If you buy that or can get it for free with your hardware, then try that first.  The full instructions are in it, apart from a single crucial step which is undocumented, and that is to allow your network to accept PING.  https://forum.pfsense.org/index.php?topic=1933.0