@iulianh Just add them as virtual ips: https://docs.netgate.com/pfsense/en/latest/firewall/virtual-ip-addresses.html

@amartinelli Yes, best practice for a VPN with the purpose of maintain a remote network is to establish a site-to-site VPN on pfSense. This gives you access to pfSense itself and to devices behind it as well. In your Secomea example the device connects to their server, which acts as a relay then. You can do the same with your own VPN server. But this requires that your server has a public IP naturally. The setup of a site-to-site OpenVPN is well described in the pfSense docs: OpenVPN Site-to-Site Configuration Example with SSL/TLS. Or you can also setup a Wireguard with pre-shared keys: WireGuard.

@keylevel There is nothing you can do on your pfSense at all. Even if you do a sort of translation, pfSense would have to route the traffic to 192.168.1.0/24, which it has two gateways for. Hence routing is not possible. The address translation hast to occur on one of the remote sites. So pfSense would see another subnet and could route traffic to it properly.

@natethegreat21 Closing this out and opening a new topic.

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]

@viragomann I did some further testing and found that it was pfBlockerNG which was causing the issue. I'll have a look at my settings in it later today. Thanks for your help

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.