@milonic Did you mean to use 10.1.1.1/24 for the VIP?

@senseivita Still no way to know why you are experiencing issues looking at that rule set. With the 1:1 in place you need to pass the desired inbound traffic to 10.7.0.229 and 10.16.0.35. Like I said, port forwards, by default, make this rule for you. 1:1 NAT does not.

Fix to Issue Issue was NAT was being applied to local LAN and remote LAN which need to be removed. This is automatically created with pfSense by default. Disabled NAT under Firewall>NAT> Outbound change to Manual Outbound NAT rule generation. (AON - Advanced Outbound NAT) Then select the NAT Rules to disable for Tunnel Interface for local LAN and remote LAN, then click on Toggle button to disable rules. Done

I have been doing a little more digging and the issues I am facing seams to be common with the 2.7.2 release. There's loots of threads over on redit so I'm convinced that SOMETHING has changed within this release because NOTHING about or with my setup has changed.

@viragomann Thanks a lot!

@louis2 said in 1:1 NAT reflection to replace splict DNS as solution to reach my own public servers from the LAN: However since DNS query's are more and more hidden in HTTPS, Split DNS solutions do not work any longer. So I need a different solution, which might simplify things as well. You should better care, that the local devices use your local DNS instead. Normally you can configure web browsers to not use DoH, but the system DNS resolver. And for the hard cores, there are lists with DoH servers in the internet, which you can use to block it. option: System > Advanced on the Firewall & NAT Enable automatic outbound NAT for Reflection I combination with some rules in "Firewall NAT1:1" This should also enable internal devices accessing your public IPs without additional NAT rules. But remember, this is only NAT as well. When a packet is arriving via the WAN, the WAN has a couple of rules to allow / to block / to NAT. When using NAT 1:1, you have to additionally configure the necessary firewall rules on WAN and on the internal interface. The NAT rules don't pass any traffic on their own.

@ddave421 Yes, this one. But this ist Just an additional IP on the NIC.

@viragomann Okay, it doesnt work. My setup. Firewall Site A: Openvpn remote net to 192.168.123.0/24 and 172.16.0.0/24 Firewall Site B: Openvpn local network 192.168.123.0/24 172.16.0.0/24 On the virtual IPs Ive added every NAT IP Address as /32 for example 10.123.1.23/32 The rules are from Site A 10.1.0.0/24 -> Site B 192.168.123.0/24 * Site A 10.1.0.0/24 -> Site C 172.16.0.0/24 * The Firewall Site B: have defined a Outgoing NAT for connections coming from 172.16.0.0/24 to 10.1.0.23 by using a NAT with the NAT IP 10.123.1.23 And a port forwarding in the other direction. Thats an example setup for one site with one ip. But is that connect ? I cant reach the site a from site c with this setup.

@aquinch Hello! Are you running the traceroute while shelled into your DS? I get flaky results running traceroute with the port option while shelled in. You could try a different host and run putty/telnet... telnet mail.synology.com 25 telnet mail.synology.com 587 ... John

@thewho Glad that you it working.

Nevermind, I guess. Looks like no one knows. In the meantime I figured out a different way as workaround.... hand editing the Backup NAT and Firewall rules and using Restore. Just export, copy your last rule from each, paste into a new one. Change the name, blank the associated GUID ID to nothing, change protocol to ipencap, blank the port in port reference. Save. Import NAT file. Import Firewall file. No reboot needed. Do a tcpdump -vvv -i tunl0 on your NAT'ted AMPR gateway you're trying to expose. If you did this right and AMPR portal is already sending traffic to your public IP, your NAT should kick in and ipencap should start flowing and registering on your terminal from tcpdump immediately. Good luck if youre on newer PFsense.. (2.7.2) looking into running AMPR gateway, and Google brought you to this post. Cheers Byron

This is how I set mine up. https://forum.netgate.com/topic/156453/pfsense-dns-redirect-to-local-dns-server?_=1671847956280

@heper Strictly seen you are right if you say that the rule order is less strict than I did suggest. If there are reasons to choose another rule order (e.g. performance), I use (partly) another order myself. Related to the difference in ^pfSence-rules^ and ^pf-rules^ at this moment I can only say that "pfctl -vvsr" shows that ^pfsense-rules^ are expanded to a lot more rules. Perhaps it is not as bad as I suggested in my example. No time to investigate that now. What ever, I am not there in the next few days. So I will scratch my head after that break.

@viragomann Thanks you it all works now. I was mistyping the ping address. It's time to go home.

@SteveITS after disabling the landline phone from my Internet router, the packet started to come :) Thank you very much for the hint :)

@viragomann I have created an isolated lab for this. Slightly different ranges. Source site = 172.16.43.0/24 Target site = 172.16.200.0/24 Isolated network on target side = 172.16.210.0/24 IPSEC Interface FW rules any/any on IPV4. Also enabled sloppy mode. No joy. [image: 1705511646876-4929c874-460c-4515-8f2c-aa337c71baac-image.png] I was tinkering with Outbound NAT rules for the interfaces to be able to route between each other which led to different results on a picture capture. Not sure if any specific outbound NAT would be required here: [image: 1705511599679-48f545fb-1a9d-4de9-853c-1d6257f94cc4-image.png] [image: 1705511610394-273b324f-1ed5-4c5f-9f3f-14e71c51df30-image.png]

@viragomann Thank you again. I assume that this also would explain why I did see some kind of traffic with the port sniffing. Apologies for the confusion, my ignorance with assuming masquerading certainly didn't help. Lesson learned!