Hello @viragomann In fact it works! Thanks a whole lot for this tip!

This is apparently a well-enough known issue that Amprnet participants are distributing fixes among themselves: http://www.qsl.net/kb9mwr/wapr/tcpip/pfsense.html Thanks for sharing that link. Over four years later- This came across my desk today and that really came in handy.

Of course. Wouldn't feel right just leaving it hanging after you tried to help out. The ISP just got back to me a short while ago. One of the support techs had setup a reflector on the IP while troubleshooting and forgot to disable it. If anyone runs into an issue like this in the future and finds this thread, have the ISP check to make sure a tech hasn't messed with stuff like that.

@bob-dig might try wireguard for same scenario if openvpn approach not able to work

***** Solution ***** Okay, after reading through the pfsense documentation more thoroughly, and exercising some patience to let Cisco/Merkai establish the correct links, I have a working setup. As stated previously, pfsense randomizes ports for security/stability reasons. This is something that regular consumer-grade routers don't do, apparently. Per the pfsense documentation here: By default, pfSense software rewrites the source port on all outgoing connections except for UDP port 500 (IKE for IPsec VPN traffic). Some operating systems do a poor job of source port randomization, if they do it at all. This makes IP address spoofing easier and makes it possible to fingerprint hosts behind the firewall from their outbound traffic. Rewriting the source port eliminates these potential (but unlikely) security vulnerabilities. Outbound NAT rules, including the automatic rules, will show fa-random in the Static Port column on rules set to randomize the source port. Per Cisco documentation (and my IT team), I gleaned that the Meraki doesn't like the source ports to be changed. So to fix this, you need to create an outbound NAT rule for the Meraki device. Go to Firewall->NAT->Outbound. Select "Hybrid outbound NAT" as the mode. Create a new rule/mapping as follows... Interface: WAN Address family: IP4+6 Source: your internal subnet (I just targeted mine to the /32 that my Meraki is assigned) Source port: (blank) Destination: Any Dest port: (blank) Static Port: be sure to check this box! I suppose you can whittle this down to the specific Merkai ports (7351, 9350-9351), but this is a single-purpose VPN device and I just figured I'd avoid future problems by just setting this to any port. Same for the destination...you could probably set this to your company's Meraki IP, but again, this is a security device (router/firewall/VPN) that only talks to the Cisco cloud and to the VPN concentrator, so that should be unnecessary. Here is what the rule should look like. [image: 1668193157186-ea72fad1-5242-42ca-8fd7-22adfb57e02c-image.png] Again, my company uses Auto NAT traversal and has our Merakis in site-to site mode and this worked for me. If they used manual NAT traversal, then you'd probably have to set a couple of different rules mapping the home Meraki to the company concentrator.

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

@learn said in pfsense port forwarding/ WAN Default deny rule IPv4 (1000000103): remote access with 3389 port if this helps! No that doesn't help.. So setup a sniff on your pfsense wan for port 6060.. Packet capture under diag menu on pfsense. Now do the canyouseeme test.. Do you see the traffic in your sniff? If not then nothing you do on pfsense is going to get it to work. Again pfsense can not forward traffic it never sees..

@siteunfold In proxy mode, pfSense itself accesses the destination device. This overrides all other firewall rules. But since you say, you already have allowed any, this might not be the reason. Possibly you have floating block rules?

@plypo Since your doing this rfc1918 to rfc1918 you could do it without a port forward because you don't need a nat. But you would need to create a route on the 192.168 device. And then allow the traffic just on the wan interface via a rule, no nat or port forward needed. And you would have to setup a no nat outbound rule so that when devices on your 10 network are talking to your 192. network they don't nat.. I would never in a million years set it up like this.. I would turn your isp device into just a modem, turn off its wifi and get a real AP for my local wifi. And put everything behind pfsense. Worse case just turn off wifi on your isp device and just double nat, etc. But there are few different ways to skin this cat. One being your typical port forward scenario, the other is just setting up routes on your devices in 192.168 to point to pfsense wan IP to get to the 10 network. And allowing via wan firewall rules, and disable nat outbound on pfsense when talking to anything other than your 192.168.1.1 gateway.

@gertjan said in Port forwarding not working: Also : check if the "web server device" is actually accepting connection from other addresses (networks) as its own network. It could accept connection coming from everybody on the 192.168.10.x/24 network, and nothing else. This was the solution, thank you. Changing the "Wordpress Address (URL)" and "Site Address (URL)" fixed the problem.

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

@johnpoz Ahh I completley missed something last night in my half awake state. Ignore me all is fine now lol thanks for the assistance!!

@uglyxiaodi18 I presume that you want to connect from a LAN device to another LAN device, or a device on another LAN(OPTx). Why do you think or need to do this using the WAN IP ?? Btw : for many users, the WAN IP can change very often ... I can access several local (LAN based) devices from my LAN, using a local device on the same LAN, or another LAN, all behind pfSense. When I'm on the road, I can use the exact same host name, and connect to my device just fine. Never had to use "Pure NAT" or some like that. True, a simple classic NAT rule is needed for my IPv4 devices, so I can connect when I'm on the road.

@rsc The source ports in the NAT rules have to be "any". They are dynamic.

@keyser Thank you for the suggestion. I did not think about terminating the DOH on the router. I use HA in house, so again, thank you for that. I do not think that my chosen DOH application supports the proxy protocol.. But that is then a different problem.. HA would change the first.. Thank you.

@johnpoz said in Dual Lan Access Each Other: But if you want to access lan from lan2, then yeah you would need to allow rule, 445 tcp should do it.

@xavier8854 The destination in the NAT rule has to be the WAN IP. Setting the same for destination and redirection makes no sense at all. Also ensure that in the WAN interface settings „block private networks“ is unchecked. On the router you have to forward the traffic to pfSense WAN address.

@vergil655 said in NAT Issuses: is there any solution to this problem ? What problem? Please show what you did, and your sniff showing that nat is still happening, etc. If I disable nat for an IP, and then sniff I can see it sending traffic without natting it. Here I created a no nat for my pc pinging 8.8.8.8 [image: 1665833756532-nonat.jpg] If I now sniff on my wan for 8.8.8.8 icmp I see this. And see from states that no nat was done as well. [image: 1665833929969-states.jpg]

@mcraven Most likely that your ISP is using a private address to serve your system a CG-Nat IP. There is a known problem with the implemented version of miniupnp, that disallows the use of private ip's for upnp on the wan side. If you check your system logs, you should be able to find the error. Port forward manually or 1:1 Nat is a work around for now.