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