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

Update, I Was never able to get this working properly, but Now that the 2.7.0 update has been released, once I updated, everything is working as expected. not sure if it was some sort of Hyper-V Driver issue, or some other bug that was fixed in this release.... just glad I can utilize my secondary internet connection better now. thanks for all the help!

@viragomann
that did work, anything else I can try?

solved by add a WAN_IGB0 interface and use it in NAT Outbound.

9b2fcfee-c934-445d-b725-d7da11b2337f-image.png

66f43f6c-9d85-4177-a228-fc0e29157020-image.png

784a3a56-3edb-423f-a98d-d4694c7c0e68-image.png

@modesty said in How to open UDP port 1883 to IoT Cayenne my devices:

My IoT device is connected to my LAN (WiFi) to 192.168.0.52 (static) and is sending packets to my Cayenne dashboard.

So allow the packets to the dashboard IP instead of the pfSense interface IP. At destination select single host and enter the dashboard IP.

@viragomann @jimp

LANRuleFailure.JPG

I modified the LAN rule to use aliases that were not subject to any security settings but passed traffic to the correct gateway. Then I copied the LAN rule, made it a block rule and changed the gateway to the gateway we don't want that traffic to exit on.
RESULT: Traffic still passes to the wrong gateway.

Then I switched the order of the rules. Traffic was unchanged. The packet captures still show the traffic flowing from LAN to W-mpls instead of being blocked or flowing to C-ens.

Nothing is logged for these connections. I think I found a bug.

@alexhen
You cannot schedule NAT rules.

You have scheduled the associated firewall rules though, but even if these rules are disabled, the NAT rules are still active and do what they meant to do and the first one wins.

Not really sure what to try to achieve with this idea. If you just have two internal servers listening on port 80 set up HAproxy. Doing so you can also let HAproxy do the lets encrypt stuff.
Also you can run a proxy on one of the backends themself.