Port Forward to LAN with multiple subnets

[Slixor]

Here is my current configuration in Azure:

pfSense VM
WAN (hn0): 10.1.0.68
LAN (hn1): 10.1.0.36

Virtual Networks
Hub:
TrustedSubnet 10.1.0.32/27
UntrustedSubnet 10.1.0.64/27
Prod_Front:
BackSubnet 10.2.0.0/24
Prod_Back:
BackSubnet 10.3.0.0/24

I have change the default LAN rule from "LAN net" to 10.0.0.0/12 to account for the additional subnets. I have also changed Outbound NAT to manual, deleted all rules and set the following:
127.0.0.0/8 * * * WAN
10.1.0.32/27 * * * WAN
10.2.0.0/24 * * * WAN
10.3.0.0/24 * * * WAN

With this setup, all machines are able to get to the internet, regardless of subnet.

For port forwarding, I have setup two test VMs:
TrustedTest: 10.1.0.39
FrontTest: 10.2.0.4

I then set up a port forward rule:
WAN TCP * * WAN 3389 10.1.0.39 3389

This worked and I was able to use a public IP of the firewall to RDP into TrustedTest.

The problem: When changing the port forward rule to 10.2.0.4 instead of 10.1.0.39, I cannot RDP in. However, I can see in the firewall log that the request has been recieved and passed.

I believe I have an issue with routing that I cannot wrap my head around.

Here are two packet traces (195.11.x.x being my PCs public IP):
Working RDP with port forward to 10.1.0.39: https://pastebin.com/tfcpPi7k
Non-Working RDP with port forward to 10.2.0.4: https://pastebin.com/NpbLcGQV

Is anyone able to assist me where I going wrong? I feel like it will be a simple fix...

[viragomann]

So the VM at 10.2.0.4 doesn't responed to the the RDP packets. I guess it blocks it by its own firewall.

If the device is able to reach other hosts in the Internet there shouldn't be a routing problem.

[Slixor]

Hi Viragonmann,

Both servers are running identical configs, with windows firewall disabled for testing

[viragomann]

If you sniff the traffic on the Prod_Front interface, where the destination device is connected to and you can see the outgoing packets, but nothing comes back, so obviously the device does not respond.
If the pfSense interface IP is the default gateway on that device and it doesn't block it, you should see responses as well.

[Slixor]

@viragomann I think you are on to something.

The initial packet traces I linked where on the WAN interface. If I set the packet capture to LAN, my working RDP to 10.1.0.39 displays data BUT if I do 10.2.0.4 I see no traffic at all on the LAN side.

What this tells me, is that the port forward / NAT rule isn't translating 10.2.0.4 onto the LAN interface. This is because 10.2.0.4 is not in the 10.1.0.32/27 subnet, but 10.1.0.39 is.

This subnet difference original caused me problems with traffice going OUT to the internet (10.2.0.4 couldn't access web). I fixed this with my Outgoing NAT rules I specified in my orignal post.

My guess is I need to setup a static route, or a gateway, to handle the traffic coming IN from the internet, so it knows where to send packets for 10.2.0.4.

This is why I saw the RDP trafficed as allowed in the firewall log, but it never reached the server.

I'll have a play now with the routes to see if I can work anything out, but in the meantime, if anyone has ideas please let me know

[Slixor]

Sorted!!

route add -net 10.2.0.0/24 10.1.0.33

Ran this via SSH in order to add the 10.2.0.0/24 network to the LAN gateways routing table.

HOWEVER, this does not persist on reboot. To work around this, I have added it as a shellcmd (one for each subnet).

If anyone knows a "better" way of doing this, please let me know.

[viragomann]

Better to add a separate virtual interface for each network segment to pfSense. So each device uses pfSense as gateway and the traffic is routed well.

[DarlingCod]

If you sniff the traffic on the Prod_Front interface, where the destination device is connected to and you can see the outgoing packets, PrepaidCardStatus but nothing comes back, so obviously the device does not respond.