@thomaspsimon I guess, you're using a policy-based IPSec tunnel. If so this is not going to work, unless you route the whole upstream traffic from the branch over the VPN, which might not be desirable. It would be doable with any other VPN solution, however, which gives you real routing capability.

Big thanks @viragomann Your BINAT insight was the missing puzzle piece, tunnel’s up, traffic’s flowing, and packets are happy. Much appreciated!

@enthu19 thank you so much, that worked! I learnt something new :) Thank you again enthu19!!!

@Bob-Dig if I use cloudflared docker container then I can get to the sites no issue so not sure why it isn't working normally okay thanks will poke around more

@Gertjan said in PORT FORWARDING NOT WORKING AFTER UPGRADE TO BETA 25.03: Anyway, very soon we can ditch IPv4 and Natting and things become easy for everybody Yeah soon ;) they have been saying that for 20+ years already.. Soon ;)

@SteveITS Yes, by "lockout" I mean exactly that. Couldn't access the web interface, connect through SSH or even ping the machine until packet filtering was manually disabled. At that time there weren't any firewall rules except for the anti-lockout rule which is present on the LAN interface by default if I remember correctly. It was only after everything finally worked as intended that I started creating my own firewall rules, and from then onwards everything's been working fine. :-) My best (and honestly a little uneducated...) guess would be that my self created interface mismatch prevented me from connecting to the pfSense machine. I suppose the lesson here is that taking shortcuts such as the one described here can't be relied on. No more trying to rename interfaces on pfSense / FreeBSD. On the bright side, no interfaces have gone down since performing a fresh installation and I sure gave it something to chew on. That's with the default RealTek kernel driver, by the way, the same one that kept acting up in the past and which prompted me to try the alternative v1.98 driver. For lack of a logical explanation I suppose we can call that a lucky coincidence.

@viragomann thanks a lot. From lan to wan works right. I must test how it works for some internal exposed services.

@SteveITS , Thank you! Small oversight between chair and keyboard. I see it now. -JB

@viragomann said in Outbound NAT over IPSEC tunnel not working: @shaunmccloud said in Outbound NAT over IPSEC tunnel not working: And the minute I add a P2 entry in my pfSense box for a remote network of 0.0.0.0/0, all network traffic but local dies. So I'd assume, that the traffic is routed over the VPN, but not out on WAN. But this is only the half of the battle. The traffic must be natted on the remote site If the Meraki doesn't masquerade your subnets there is no way to go out to the internet through it. I decided to cheat, and throw a virtual pfSense box in the data center to connect to. I'll see how that works tomorrow.

@TheCalvinator glad to hear finally sorted. Thanks.

@viragomann Morning my friend, some news about topic?

@Yasir Yeah, well unfortunately that's the way it's implemented so unless you can push for and get an update/improvement of the implementation, a script is the only other solution.

@viragomann Thank you very much. you helped me understand very good whats going on. Moreover i managed to to make it wotk bu adding an snat outbound rule to the openvpn interface. thanks again.

@Zak-McKracken If the issue is suspected to be with the external IP and the Ricoh firmware, then it might be worth trying siproxd.

@viragomann Thanks. going to do some reading up on this before I kills my pfselnse.