@kiokoman Thank You, I now see what I may have done. Sincerely Thanks

Bull's-eye. The answer I was looking for. Thank you @viragomann very much

@Ivan007 Welcome to one of the "benefits" of NAT. When you set up port forwarding on your firewall and have a public address on the WAN side, the traffic from the web site can reach your firewall, where port forwarding is used to send it to a specific computer. When the ISP puts NAT ahead of your firewall, there is no way for you to configure port forwarding on it, so there's no route to your firewall. NAT is a hack to get around the IPv4 address shortage and it breaks somethings Port forwarding is a way around one of the things it breaks, that is transparency along the entire path. With ISPs NAT you can longer work around it. This is why the world MUST move to IPv6 as soon as possible. The more NAT is used, the more things break. Already with VoIP and some games it is necessary to use STUN servers, to get past NAT. I don't know that those will still work behind ISP & customer NAT combined.

@superprick said in multiple virtual ips port forward strange lan behavior (solved): dig curl both fail You might benefit from showing your work there.

@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!