@viragomann Sorry for the delayed response.
I sorted the issue, but I digress.
I was trying to access the WAN1 address and was checking if port forward was working from a network which by default was given to another physical firewall which blocks access.
I tried testing the WAN1 port forward using another outside network, and it works fine.
I should have troubleshooted this quite early. But hey, I'm glad it's sorted.
Thanks for helping out, everything you told is accurate and helped me figure this issue out.

Now I have allowed VLAN access from WAN2 (physical firewall) to WAN1 (virtual firewall) and I am able to access port forward from LAN of WAN2.

Cheers!

@khensu said in Same Device in two Subnets:

But somehow a lot of people probably dont even know what a IP Address is and just want it to magically work.

Agree - grandma beth, not saying the discovery is not useful.. What I am saying - what do you think that discovery discovers - the IP.. Just let the user put it in!!

Other solution is when you want to use those devices, just put your phone/tablet on that vlan - change to that ssid. I'm not a fan of setting up vlans, and then just breaking that boundary by sending multicast across that boundary.. ;)

Or setup avahi - I have gone over it a few times myself on how to troubleshoot it. Let me see if can dig up last time..

https://forum.netgate.com/post/1016923

here is troubleshooting it
https://forum.netgate.com/topic/166642/mdns-struggles/11

@pfsensor666
The server addresses the response packets back the the client IP, which is 10.0.2.6.
So the server will direct the response to his default gateway, FW2.
To instruct FW2 to direct the packet destined for 10.0.2.6 to FW1 you need a static route, otherwise it will send the packet even to its default gateway.

Instead of a static route you can also masquerade the traffic on FW1 by an outbound NAT rule. Which means the source IP in request packets gets replaced by the firewalls interface IP.
But doing this, the server will see the access coming from 162.168.1.1 instead of the real clients IP.

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

9b2fcfee-c934-445d-b725-d7da11b2337f-image.png

66f43f6c-9d85-4177-a228-fc0e29157020-image.png

784a3a56-3edb-423f-a98d-d4694c7c0e68-image.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.

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

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