@Legal_Brick_527

With two VPN clients running on the same pfSense ?
I didn't really insist when testing (things start to behave very bad).
I'm sure that a first VPN client can used as the 'gateway' for a second VPN client on the same device, but you probably have to set them up the old way : manual config file creation and all that. That's not possible on pfSense.
I hope to be wrong of course.

What was possible :
Setting up a pfSense VPN client to 'some' VPN-ISP, routing all outgoing traffic over this connection, that's classic and works fine.
Then I activated a VPN client on my NAS, used 'another' VPN-ISP, and that connected also "just fine".
Now, I had a tunnel over a tunnel.
As I was using some web https sites to test, I actually had a a tunnel in a tunnel in a tunnel.

Btw : you go beyond what is needed to protect the launch codes of the nukes .... are you sure you need this protection ?

@negeji8010 yeah I hear yeah.. oh btw IT make this nonsense work.. Yeah we didn't bother to ask you if we "could" do such a thing - just make it work!

To make it work.. You will need to nat them, and will need different natting devices.. The "cheapest" way to do it is find some small little router.. Some little travel router or soho router going to be the easy cheapest solution. Sure you could do it as vm, etc. But that is going to cost more for sure.. Unless you have something laying around to use as the host were you could run multiple natting something - wouldn't have to be pfsense doing the natting.

If you go the soho or travel router I would make sure it runs some 3rd party firmware (openwrt for example) vs native like linksys or netgear router OS.. Maybe tiny router from Mikrotik, they have something like the hex lite for like $40 that can be powered via poe, etc.

But can they connect to the pfSense GUI or ping it's local IP address?

Try checking the NAT type in each game on your Xbox, like in DayZ or Fallout. Sometimes the game shows a different NAT type than the Xbox settings. If it's showing strict or moderate NAT, that could be the problem.

@SteveITS said in NAT 1:1 configuration in HA-CARP mode:

For your IP alias I think /32 is wrong:

@viragomann said in NAT 1:1 configuration in HA-CARP mode:

So there is something wrong with this IP or the CARP VIP, which you should troubleshoot.
Check the logs for hints.

Hooking up the IP alias on the CARP VIP is necessary for proper failover. If you just set it on the interface it can never failover to the secondary.

Thank you both for your help!!!

I've set up a new carp just for this type of 1:1 NAT situation and I'm doing a port forward.

I found the issue I changed the OPT1 name and it would not change in the config.xml so it does not bind to the new name, I set it back to OPT1 after seeing that the config.xml did not recognize this as selected for upnp section of the code and it worked.

It is like the name change messed up somehow

@Djkáťo

The one and only question that answers your question while answering me : do you have a working Internet connection ?
If yes, then nearly all is fine, and you can stop looking, as you've already mentioned what your current situation is : its doesn't break your internet access if your WAN IP is a RFC1918.
But you can probably forget about NATting so you can make internal (on the pfSense LANs) devices accessible from the Internet, as you have no access to the ISP equipment to do so.

If your "TP-Link Archer VR300" is truly working as a modem, its just converting POTS VDL signals to "Ethernet" signals and it doesn't do routing , firewalling etc. Its not the "TP-Link Archer VR300" that has a WAN, and a DHCP server that gives you the "10.101.37.22" pfSense WAN IP : this "10.101.37.22" comes from way up, somewhere from the ISP.

Why they do so ? There is the classic $$$ rule : they have no more free routable IPs left as IPv4 free available stock has been sold out meany year ago, and what's left has a huge price tag. Its seen before ; you want a real routable IPv4 ? You $$$ or €€€.

@Shan-lapierre said in Monitor NAT rules:

And infact my NAT rule was created whit "Pass" flag and pf doesn't created any fw rule.

I'm still looking for a usage of that "Pass" case ^^

Normally, a NAT rule translates traffic coming (initiated) somewhere on 'the WAN' (the Internet) and the address (WAN IP) (and port) has to be mapped == translated (a,d port) to a LAN addresses, so it can reach this device.
This needs of course a WAN 'firewall' rules, as by default nothing can enter the WAN - everything is blocked by default.
A NAT rule without an accompanying firewall rule .... won't work, as traffic will never reach the NAT rule, as traffic can not enter into the WAN interface.

I'm not saying other types of NAT exit, they do.

From what I've read :

receive traffic to my firewall on a specific port from a specific public IP.

Everything is working (so the external traffic reaches me on an endpoint inside my network that is listening on that specific port).

your use the classic method, and you need a auto generated firewall rule on the WAN interface.

@viragomann I'm using "Any" as port config for accessing the GUI via WAN. Indeed, I need to state a specific port so I can access more than one interface via WAN. Thanks for reminding me of that!

@viragomann
It is policy-based tunnel (Tunnel IPv4).

Phase2 is working (status connected).

Status->SystemLogs->IPSEc has no corresponding entries.

But you said " and the subnet is not routed through the tunnel": This is exactly the problem - how to do this? As there are no thus options in the IPSec tunnel settings ("NAT/BINAT translation" should not be the corresponding option.)

@stephenw10

I agree 100%. the E2140 will not.

Just a little update there were several other issue other than the CPU.

The Netgear R6220 under powered - disabled Traffic Meter and every thing else, but Access Control, DHCP, port forwarding and WIFI. The RealTek NIC;s conflict with drivers and version(s), just downloaded updated driver package and replaced drivers.

After fixing those items I decided to pull the trigger and move this setup to the i7 NUC, just unplugged the hard disk and plugged it into the i7 NUC, ran the installer but select recover previous configuration from the menu, the followed the installation prompts.

Everything came back configured except the NIC;s just reassigned and set the ip address and bang done.

I am now hitting 1.1 GBPS on downloads and 940 MBPS on uploads. CPU utilization is between 2 - 5% on average and never peaks above 6%. Still using the Netgear but that is another can of woms I will tackle later (too much configuration) need to document and test the document that it is correct as I have allot of Home Smart Devices (i.e cameras, smart plugs, door bells, door locks, etc,,,,) they were a nightmare to setup and get working, do not want to repeat that.

But thank you for replying, as I am I noob with pFsense I can offer little help but if you have question for me just ask I will try my best to answer

DarkKnight

@pdwalkerhk said in NAT Reflection on a multiwan system - need help debugging my problem getting it to work.:

is there any way to debug why the traffic from the local lan to the public ip of the port forwarded ports is not going through?

Sniff the traffic with the packet capture tool on the LAN.

does that reflection firewall rule look correct for my situation?

I would expect it to work.

the default route for the LAN traffic is a gateway group composed of the 4 lan connections. Could this be causing a problem, preventing the nat reflection from working?

You may mean an interface group. This is not a problem, however, ensure that a rule on LAN allows the traffic from LAN IP to LAN destination IP.
The rule must not be a policy routing rule (gateway (group) stated)!

could I use the / Diagnostics / Packet Capture / somehow to find out what is or is not happening?

Yes. You should see packets from the source IP to the public going to pfSense and packets leaving with source = LAN IP and local destination IP.

@johnpoz said in Port Forward does not work..:

But completely agree with you - in my multiple statements that nat reflection is an abomination

That's the way I know you. 😊

As I mentioned, I didn't read all posts and I missed the reason for doing NAT reflection.

@JonathanLee I block DNS over HTTPS to the firewall using unbound because I have unbound running DoT. My solution to the Nintendo griping about DNS was to route it out to 1.0.0.2. I was also having issues with unbound using the ephemeral ports I was using, interrupting my sensitive codel games so had change localhost's NAT outbound.

@johnpoz said in Virtual IP subnet cannot connect to internet:

@BlueSun said in Virtual IP subnet cannot connect to internet:

There's an Automatic NAT Rule, which I don't see

You said your outbound rules were auto and it was added, I was just adding that screen for completeness

Well, I set the outbound NAT rules to Automatic, but for some odd reason it didn't create the rules you have in your screenshot, so I had to add them manually.

d60a6317-0b25-4106-b407-971b002cdac0-image.png

You can't. Snort sits between the physical NIC and the kernel network stack before the firewall engine. So, when you run Snort (or Suricata for that matter) on the WAN, it only sees local traffic after NAT has been applied for outbound traffic, and before NAT is undone for inbound traffic. Here are two diagrams that show how the IDS/IPS packages are plumbed into the network. This is an operating system thing and not anything the packages can alter.

ids-ips-network-flow-legacy-mode.png

ids-ips-network-flow-ips-mode.png

This is why I have been recommending for the last few years that users put the IDS/IPS on internal interfaces. You should do the same. There is no point in having it on the WAN. IDS/IPS is not for protecting the firewall. It's for protecting the hosts behind the firewall. If you need IDS/IPS for your firewall itself, then you really need a new firewall 😀.

Running it on the LAN would eliminate your issue of NAT hiding local IP addresses. When running on the LAN, all traffic going to or coming from local hosts would have to pass through the IDS/IPS.

And one last note. Without MITM breaking of encryption, IDS/IPS on the firewall is severely limited in what it can accomplish these days because nearly 100% of network traffic is encrypted. The IDS/IPS can't peer into any of the payloads for SSL traffic. That means zero payload inspection of HTTPS, DoT, DoH, SMTPS, IMAPS, and POP3S for starters. That's nearly all of the web traffic, potentially all of the DNS traffic (if you use DoT), and pretty much all email traffic bypassing inspection. Intrusion Detection is rapidly becoming something best done on the local destination host itself and not on intermediate network devices.

@luanks01 said in configurar acesso remoto:

Tentei com e sem https e sem a porta também

Mostre como ficou a sua regra, pode ser que seu provedor não permita conexões na porta 443 de entrada, o que é muito comum em planos residenciais. Inclusive outras portas também são bloqueadas.

Caso esse seja o caso, tente alterar a sua porta dessa forma:

62b92a87-263b-4e08-910d-6bad7892887a-image.png

No campo TCP port, ponha uma porta alta qualquer, como por exemplo 4443, depois altere a regra que você criou anteriormente para permitir conexões na porta que você escolheu, no exemplo aqui desse post seria a 4443.

Lembrando que agora a gerência do firewall será nessa nova porta.

@emc

This issue has been fixed. NAT is working. It was a firewall issue in the PBX. I've whitelisted the IPs on the PBX's firewall and it works. Thank you everyone for your help.

@karl047 Hab die Frage von Beginn an verstanden, kann sie aber auch nicht beantworten, da kein Pro. Vermutlich wird ICMP für IPv6 irgendwie anders behandelt.

@viragomann Awesome answer! I really appreciate you taking the time and attention to detail, to go through and answer each question. Very helpful!

Had thought of and actually made groups after posting, but the time limit for editing had run out when I tried to do so. Makes sense.

Q6: Apologize, I wasn't clear, I meant referencing the picture. Source any and inverted on LAN address. Should have specified.

Q2: What's been interesting in practice, is although all are on the same rule redirected to 127.0.0.1, some worked and redirected to 127.0.0.1 and others redirected to the static ip on the interface. Therefore those did not work with the firewall wall pass rule specifically for port 53 to 127.0.0.1. I.e. No DNS until 127.0.0.1 was changed to xyz interface address in the pass rule.

Prior to changing the pass rule, the interface static IP could be seen in the firewall logs as -p 53 blocked (from a lower separate block rule to 'this firewall') on many of the interfaces, so had to change the pass rule from single host/alias --> 127.0.0.1 to xyz 'address'. Then once change to just the xyz interface address, dns resumed and all worked again. No changes to the lower block rule.

Any ideas as to why the explicit redirect to 127.0.0.1 would lead to that result on some interfaces, but others redirected specifically to the static ip of the interface? Anything to do with resolver functionality?

edit: When I went back and didn't have it as an inverted rule, but rather * (any) for destination, it redirected to 127.0.0.1 as expected. I'll not delete and leave the above though, for anyone that might experience the same with the inverted rule.

Thank you again for your time and great detailed answer above!