@Gertjan mmm you have a point, it would be a loop over and over again.
Essentially, the DNS I need this to go via is 104.223.91.194 or it's secondary of 104.223.91.210.

Under DNS Resolver, Network Interfaces is listed as ALL, therefore unbound would resolve from 192.168.14.1. I have attempted to only allow a resolver from localhost, it's a 50/50 if a website will resolve when selected only on localhost.

@johnpoz
I see. Thanks for your help as well! Appreciated.

After some packet capture, I located a typo in my NAT / Port Forward table. All working as expected now.

@KOM Your link is really helpful

Somehow I suspect that that answer was some spam-bot as it isn't related to anything written here. But

when I connect with it I can't use my local network

That would just be a simple OVPN configuration mistake. If that's still a problem - just ask in another topic and we'll deal with it then ;)

Why and the F would you think that would work... It still has its 10.200.40.x interface..

If you want this to work while the box still has a 10.200 interface then you have to SOURCE nat it at pfsense.. Period, end of story..

Or you have to talk to it on its 10.200 interface..

Ok, solved
Due to the test environment, my client MYINTERALLINUXSERVER was set to wrong getaway.

Solved the problem. I had a mail server on the same machine listening to port 443 for who knows what reason.
Thanks a lot

@ivanupsons said in 1:1 NAT failing.:

I tested the public IP on the internet switch and it works. I can browse when I configure it on my laptop.
I have done "Diagnostics > Ping and ping out to, say, 8.8.8.8 using that VIP as a source address" but no response. 100% packet loss.

Maybe your ISP gear doesn't like multiple IP addresses on a single MAC address or something stupid/silly like that.

Packet capture and see what is really going on. See what ARP traffic there is, etc.

@dragoangel said in 1:1 NAT failing.:

P.S. yours x.x.x.141/28 is overlapping your assigned WAN IP x.x.x.142 - "good job".

Nothing wrong with the addresses chosen based on what we have been shown.

69.63.67.129 - 69.63.67.142 are available for use in 69.63.67.128/28.

The only thing we have not been shown that I can see is which of those addresses the ISP's gateway is using. .129 would not surprise me.

@digitalcomposer glad to hear 👍

What your VMs doing on WAN? What a point have in 2019 Windows XP? FYI: in this year Windows 7 going to be off from support. Stop and move to fresh OS, especially this is VM, hell...

Firstly you say they on nat, then on wan. For me its looks like you even doesn't know what you have. How anybody will help you then? Stop NAT all to internet, ESPECIALLY WindowsXP, you will hurt yourself. Configure OpenVPN and connect both VMs to one private network, and share what you want between them.

After rereading this and reviewing /tmp/rules.debug, it seemed I had the NAT reflection enabled on these rules and those generated reflection rules is what was matching unexpectedly and why it was always matching the top rule in the list. Once I disabled NAT reflection on these specific rules, everything started working as expected.

The OpenVPN server your ubuntu is connecting to is probably sending a default route def1 to the client so reply traffic to the connection attempts is going out the client's VPN connection.

If so it's not a pfSense problem that can be fixed there, it's an OpenVPN client connection and routing table problem on the ubuntu machine. You could probably use outbound NAT on the inside interface to make connections to the zoneminder server appear to that machine to be coming from the pfSense interface address. Replies would then be same-subnet so the route back would work.

Look at the routing table on the ubuntu machine when the VPN is connected and when it isn't. I believe netstat -rn should work there.

What you are saying makes perfect sense. I don't know why I didn't figure this out earlier. Thank you very much for your help!

Wait... so you made two posts about the same problem but with different data?

I don’t get it...

Jeff

Thanks,PF1-LAN is 192.168.200.25,LAN--PF2 is 192.168.200.17.
The problem is the same. !
PF1:
1.jpg

I now have a SYN packet passing through the NAT rule to the LAN NIC. I am NATting to a Windows VM in Azure. I added Wireshark to that VM. The SYN packet never reaches the VM.
Also, I can ping the LAN NIC from the VM (I added a firewall rule), and I can ping the VM from the pfSense server using an SSH connection.
On the Azure VM network security group, I have opened access to anything from the Azure local vnet.
On the Azure VM, I have disabled the Windows Firewall.
On the pfSense LAN NIC, I have added a firewall rule to allow all TCP traffic.

So it looks like the packets to be NATted are being blocked on the way out of the LAN NIC.
Any ideas? anyone?

The issue is resolved by removing this rule.
I don’t understand where it came from

4.png