Sorry to say it at this late stage, but this really illustrates the importance of taking a regular backup of your running config. Especially before making any changes.

The problem in ISP, thank you for suggestion.

Ok, i managed thanks to this article to have it work
https://forum.pfsense.org/index.php?topic=82732.msg453269#msg453269

I did miss the openvpn server service restart

I recap, hoping tohelp anyone else:

A) VPN tunnel (open VPN) up and Running (see on eof the tutorials)
B) BOX B (target side)
    1)  Interfaces, Add …. as in the article
    2)  RESTART the SERVICE
    3)  Remove any rules from the Firweall > OpenVPN
    4) Add a rule on OVPNC1 (the virtual adapter) with destination 192.168.99.1 (the internal IP) and the ports (if any specific)
C) BOX A (source side)
    1) Add a 1-1 NAT with IP_PUB_A <ip1>as public IP and 192.168.99.1 as the target
    2) Add a fireall rule (WAN) with target 192.168.99.1 to allow traffic
    3) In the OPenVPN tab add an allow all rule

et voila</ip1>

Yeah don't understand this sort of setup either, its always best to put the vpn connection at the actual edge, not forwarded to some box inside behind a nat.

But to answer your question directly, just forward ESP which protocol 50.  Don't you want 51 as well AH?

protocol50.png
protocol50.png_thumb

You might want to look at the reverse proxy package like HA.

Hi,

the best solution would be to set your router in bridge mode and let pfSense do the VPN termination. So the firewall can control all connections from outside itself.

I've neither a L2TP set up nor a double natting. So I am not able to share some experience with that.
However, if you want to solve it this way let us research…

Two elementary things will be necessary to get it work:

The VPN clients must know the route to the LAN network.

The firewall must allow this access.

For allowing access, you have to set up a firewall rule.
I assume, your pfSense WAN net is a /24 and the VPN pool uses the same whole subnet. It will be a good advice to reduce the VPN pool to a e.g. /27 or whatever you need, or just more better, to use a different subnet. So it will be easier to distinguish the VPN and internet traffic.
So you will have to add a rule to WAN interface to allow access from VPN subnet to your LAN network.
If VPN pool uses whole WAN subnet you have to add additional block rules with higher prio to prevent access from internet (192.168.91.254 in your case) and possibly other hosts on this subnet.

The other thing is the route at VPN client to the LAN behind pfSense.
If your client sets the VPN server as default gateway at establishing connection there should be no additional route required. Otherwise you have to set manually a route to LAN subnet using the pfSenses WAN IP.
As far as I know L2TP has no capability to push special routes from server side.

I just created an identical pfSense on VirtualBox and cloned the config on it. Everything works fine.

Here's the ifconfig of KVM setup:

ifconfig br0: flags=4163<up,broadcast,running,multicast>  mtu 1500         inet 192.168.7.2  netmask 255.255.255.0  broadcast 192.168.7.255         inet6 fe80::4ccb:a9ff:feb7:5617  prefixlen 64  scopeid 0x20         ether a0:88:69:0d:5c:41  txqueuelen 0  (Ethernet)         RX packets 2825  bytes 330247 (322.5 KiB)         RX errors 0  dropped 0  overruns 0  frame 0         TX packets 3339  bytes 802554 (783.7 KiB)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 enp2s0: flags=4163<up,broadcast,running,multicast>  mtu 1500         inet6 fe80::5ea1:75a3:7d46:befd  prefixlen 64  scopeid 0x20         ether 00:90:27:77:fb:02  txqueuelen 1000  (Ethernet)         RX packets 223027  bytes 20719723 (19.7 MiB)         RX errors 0  dropped 178  overruns 0  frame 0         TX packets 6747  bytes 2101069 (2.0 MiB)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 lo: flags=73<up,loopback,running>  mtu 65536         inet 127.0.0.1  netmask 255.0.0.0         inet6 ::1  prefixlen 128  scopeid 0x10 <host>loop  txqueuelen 0  (Local Loopback)         RX packets 12388  bytes 1341938 (1.2 MiB)         RX errors 0  dropped 0  overruns 0  frame 0         TX packets 12388  bytes 1341938 (1.2 MiB)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 macvtap0: flags=4163<up,broadcast,running,multicast>  mtu 1500         inet6 fe80::26f4:1e55:97a0:c0cb  prefixlen 64  scopeid 0x20         ether 00:90:27:77:fb:02  txqueuelen 500  (Ethernet)         RX packets 217268  bytes 20328935 (19.3 MiB)         RX errors 8919  dropped 8919  overruns 0  frame 0         TX packets 6620  bytes 2073711 (1.9 MiB)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 vnet0: flags=4163<up,broadcast,running,multicast>  mtu 1500         inet6 fe80::5d6b:398c:6b44:d602  prefixlen 64  scopeid 0x20         ether fe:54:00:6f:2e:15  txqueuelen 500  (Ethernet)         RX packets 4558  bytes 4062075 (3.8 MiB)         RX errors 0  dropped 0  overruns 0  frame 0         TX packets 4583  bytes 624983 (610.3 KiB)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 wlp1s0: flags=4163<up,broadcast,running,multicast>  mtu 1500         inet6 fe80::6e57:fe92:1321:1521  prefixlen 64  scopeid 0x20         ether a0:88:69:0d:5c:41  txqueuelen 1000  (Ethernet)         RX packets 6040  bytes 811010 (792.0 KiB)         RX errors 0  dropped 0  overruns 0  frame 0         TX packets 7038  bytes 4986969 (4.7 MiB)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0</up,broadcast,running,multicast></up,broadcast,running,multicast></up,broadcast,running,multicast></host></up,loopback,running></up,broadcast,running,multicast></up,broadcast,running,multicast>

and of a much cleaner, and - more importantly - working VirtualBox setup:

# ifconfig br0: flags=4163<up,broadcast,running,multicast>mtu 1500         inet 192.168.7.2  netmask 255.255.255.0  broadcast 192.168.7.255         inet6 fe80::a288:69ff:fe0d:5c41  prefixlen 64  scopeid 0x20         ether a0:88:69:0d:5c:41  txqueuelen 0  (Ethernet)         RX packets 4999  bytes 1686341 (1.6 MiB)         RX errors 0  dropped 0  overruns 0  frame 0         TX packets 9269  bytes 2203282 (2.1 MiB)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 enp2s0: flags=4163<up,broadcast,running,multicast>mtu 1500         inet 192.168.11.13  netmask 255.255.255.0  broadcast 192.168.11.255         inet6 fe80::201:2eff:fe4e:4b99  prefixlen 64  scopeid 0x20         ether 00:01:2e:4e:4b:99  txqueuelen 1000  (Ethernet)         RX packets 175668  bytes 58689989 (55.9 MiB)         RX errors 0  dropped 35  overruns 0  frame 0         TX packets 33594  bytes 2862399 (2.7 MiB)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 lo: flags=73<up,loopback,running>mtu 65536         inet 127.0.0.1  netmask 255.0.0.0         inet6 ::1  prefixlen 128  scopeid 0x10 <host>loop  txqueuelen 0  (Local Loopback)         RX packets 44600  bytes 11957420 (11.4 MiB)         RX errors 0  dropped 0  overruns 0  frame 0         TX packets 44600  bytes 11957420 (11.4 MiB)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 wlp1s0: flags=4163<up,broadcast,running,multicast>mtu 1500         inet6 fe80::a288:69ff:fe0d:5c41  prefixlen 64  scopeid 0x20         ether a0:88:69:0d:5c:41  txqueuelen 1000  (Ethernet)         RX packets 4400  bytes 1698452 (1.6 MiB)         RX errors 0  dropped 0  overruns 0  frame 0         TX packets 8264  bytes 2315002 (2.2 MiB)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0</up,broadcast,running,multicast></host></up,loopback,running></up,broadcast,running,multicast></up,broadcast,running,multicast>

So it looks like KVM is not suitable for hosting pfSense VM if host machine is required have access to the internet. It is a shame as I was hoping for KVM to be not just working, but a superior solution.

Can someone move this thread to Virtualization?

After some more testing it seems the NIC was somehow damaged during the hardware upgrade. Even though it worked fine in the old machine, by the time it was in the new one it had broken.
Replacing the NIC with a new one has completely resolved the issue and link speed does not need to be set manually anymore either.

Thanks for your thoughts and support! It is greatly appreciated.

agreed, or pointed to this article. https://doc.pfsense.org/index.php/FTP_without_a_Proxy

No, this thing is NOT managed via shell. Backup the configuration, read the config.xml and have fun with mass adding there. Reimport when done.

@Bigzaj:

I'm trying to do something similar with a DDNS service.  I have one domain I want to redirect to multiple internal IP based on port.

You already have your own thread.

The server's sending the SYN ACK in response, the question is why doesn't it get to the client. Does it leave WAN?

@Derelict:

I thought NAT took precedence over services listening on the firewall.

It does, that's not relevant here.

Port forwards rewrite the destination. Outbound NAT rewrites the source. Disable outbound NAT if you don't want it to NAT, or set it to hybrid or manual mode and configure your rules accordingly if you don't want all NAT disabled.

I've got the exact same problem, only 1 subnet through the IPSEC-tunnel, and trying to use a 1:1 NAT to reach resources on a different subnet.

Anyone know if this is possible? I think the main problem that it is not working, is that the source of traffic from the 'other side' is not a subnet-interface, but the IPSEC-interface. In het NAT-rule you can't select the IPSEC-interface, so the traffic is never matched against this 1:1-rule.

Maybe i've "found" the solution. It's looks wired but it works.

I've made these steps:
1. System>Advanced>Firewall/NAT>Set "NAT Reflection Mode" from "disable" to "NAT + Proxy"
2. Save ( i've tried again with this option without success )
3. Step Back to "disable" and everything start working

I'm actually astonished  :o

I'm going to remove the unused Virtual IPs.

Thanks Everyone. I appreciate your help.

What exactly in the linked howto does NOT work for you? Ya know, noone here will make the protocol NAT friendly…

on your interface "WAN"  "block private networks" is checked.  you are using a private network subnet there, so un-check that.