@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. [image: 1670056555355-9b2fcfee-c934-445d-b725-d7da11b2337f-image-resized.png] [image: 1670056599435-66f43f6c-9d85-4177-a228-fc0e29157020-image-resized.png] [image: 1670056514929-784a3a56-3edb-423f-a98d-d4694c7c0e68-image-resized.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 [image: 1667860975020-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: [image: 1652360612067-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.