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

@michmoor I personally never used pfblocking because of DoH DoT and HTTPS3 QUIC. It was changing every 3 months with ways around DNS based filtering. I use to work with government clearances so I have a target on my back for anything at home. It was so bad one year I couldn't get through a single Netflix film without getting hit with denial of service attacks. I found a solution.

I use the SG-2100 internal wifi card for the Nintendo switch on a separate unfiltered WiFi. And all my my university stuff and home NAS sits on the RJ45 based external AP with a different subnet.

Screenshot_20231112-183556.png

Screenshot_20231112-183608.png

With AppID and the full text rules I could see the Nintendo switch doing Curl all the time on my network, now it can do it all day on a separate subnet and never see my firewalles LAN.

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

No ideas or suggestions?

pfSense will only allow access from the WAN side by default if there is only one interfaces assigned. As soon as you assign two of more interfaces all connections to WAN are blocked by default and you need to add WAN firewall rules to allow them.

@bob-dig
yes destination is internet.

So this is why I get the NAT3 on the ps4 right?
in short, because the vlan's gateway is not exposed to internet but is behind the wan.. right?

sorry what you mean with If the destination is at your place then number 3
another vlan or the lan?

thanks again

So the P2 will effectively end up being (in my example) 10.200.10.0/24 to 10.100.10.0/24.
Each side 'hides' it;s local 10.10.10.0/24 subnet behind another, same sized, subnet. You could use any unused subnet for that I just chose 10.100.10.0 and 10.200.10.0.

So on each side that would be the Binat address.

https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/phase-2-nat.html

However if you do not need access between the two subnets dircetly but only from the pfSense_1 OpenVPN subnet this becomes easier. You only need to BiNAT on the pfSense_2 side like:

Screenshot from 2022-05-12 14-02-05.png

On the pfSense_1 side the P2 would be just be 172.10.10.0/24 to 10.100.10.0/24

To access the remote side VPN clients would need to use the equivalent NAT address.

Steve

@viragomann
Thanks !
Went with the port forward + outbound option, NAT is working finally.

For anyone else finding this thread. I've found the solution.

Create a port forwarding rule

INTERFACE: WG0
PORT: 44158
DESTINATION: WG0
DEST PORT: 44158
REDIRECT TARGET IP: MINER IP
REDIRECT PORT: 44158

Then everything works as expected.

@jasonharper Could you send me an example print please?

@johnpoz Yup it was an issue with the box. Thanks!

@viragomann

Thank you for your reply.

The lan interface gateway is empty and the NAT is set in 'Manual Outbound NAT rule generation'.
In any case I found the problem, there was a NAT rule configured to a network interface group with the LAN interface included.

Avevo controllato many time NAT configuration! 🤦

Thank you very much!

@shaungehring This sounds similar to an arp cache issue we had. We could not connect, ping it, then all was good. The network team did something to the arp cache on a switch to resolve it. I do not have details as it was many years ago.
Maybe that will get you in the right direction.

@anthoinn Problem resolved just need to put correct subnets on server side

VPN is much better way to access your resources from remote for sure ;)

If they are different interfaces and not switch ports - then no there is no way to put them on the same network without bridging them.

But the only reason you need for them to be on the same network is broadcast traffic.. They could be on different networks and still access everything on the other network. Just create any any rules.

Do these devices use some broadcast/multicast discovery or protocol that is required that they are required to be on the same network..

If want to leverage your ports for individual devices - ok... But why do you need to bridge them.. Just use 192.168.1/24 on 1 and 192.168.2/24 on 2.. And use an any any rule - there you go these devices can talk to each other for anything other than broadcast traffic.

Bridge is only going to complex up the config, and more overhead for what? Are you doing something that requires broadcast to work? Then get a switch... Really the only time it makes sense to leverage a bridge is media conversion...

Or I had something that required the devices to be in the same broadcast domain, ie the same L2 network.. But I also wanted to be able to firewall between them for some stuff. In that case you would use a bridge (transparent firewall) and be able to do such a thing. But just wanting to leverage the ports on your pfsense box.. I don't see the point of trying to bridge them?

My understanding from the breeze over I did of that article linked to - is you could send it to different servers based on name - but you need to use the proxycommand from your ssh client.. Which seems like more work then just using a different local domain or IP ;) and not bouncing off the proxy.

That could come in handy if all your clients that wanted to talk to different ssh servers were outside your network vs doing a reflection connection from the local netework.

@viragomann i will try that, thanks :)

Hi @chpalmer,
You were right; the problem was an incorrect gateway configuration on the webserver.

Thanks again!

@viragomann Ok i got it working.
It took some cleaning up after previous attempts and I wouldn't make it work if it wasn't for you info.
Thanks

After another round of extensive troubleshooting, it turned out that everything I had done on the pfSense side was correct all along.
The 1:1 NAT with static Outbound NAT rules were working perfectly fine.

One thing I did not mention in my initial post, was the fact that I am also using DNS Resolver in my DMZ.
This is done so that any softphone clients using my guest WiFi network, will be able to resolve the IP address of my PBX to the internal IP, rather than the external.
While the PBX itself was configured with static IP address and using public name servers, it would somehow still resolve the PBX name to the internal IP, rather than the public IP.
I don't know if there is a bug in the OS where FreePBX is running on, or a configuration error or something else. This is still a mystery to me, which I am trying to figure out.

In the time it took to fix this critical bug, I was able to:

Set up and thoroughly test out OPNsense in a staging environment Find viable replacements for all the pfSense plugins and features I was using Weigh the pros and cons of switching to OPNsense Realize that open source pfSense has become a second class citizen Provision a new production firewall with OPNsense Manually copy the configuration from pfSense to the new OPNsense box Retire my pfSense box and switch permanently to OPNsense

@jimp Thanks for posting this. This is exactly my problem with my pfSense Plus. I have two WANs with my default one being GCNAT. My secondary WAN has a static IP which is used for inbound connections which need entry to my network.

I didn't have any problems with 2.4.5p1. I can only make it work now if I change my default gateway to my static IP WAN. This connection is very slow compared to my other WAN. Hopefully they come up with a workaround soon.

Somebody please?