Routing

Hei Renede,

WebAdmin automatically builds routes between the subnets defined on its interfaces, so no static routes should be necessary.  You would need a firewall rule like '{192.168.25.0/24} -> Any -> {10.0.10.0/24} : Allow' to enable devices on eth0 to connect to devices on eth1.  This doesn't apply to pings - refer to #2 in Rulz (last updated 2019-04-17).

"I can ping the 10.0.10.88 but then it stops." - what stops?

Cheers - Bob

Good question.

Okay so there's a few approaches here and let me start by saying I'm not implying mine isn't the onlynor is it necessarily the best.

First off, the simplest method here is to have all the subnet masks the same. So lets say your 192.168.25.0 and your 10.0.10.0 both used a /24 or 255.255.255.0 subnet mask.

All that is required here is to open up netbios/wins and dns ports in both directions. you can easily do this by making a rule with "Windows Networking (NETBIOS) group in both directions.

Second, assuming you either don't want to or can't change the subnet mask. This is a little more tricky because you need routing between the different subnets. I've encountered this in my office network in wanting to support my clients; often I will have equipment that I cannot change IP on such as a windows or samba domain controller. Here's a rundown of my setup and how I've applied the fix I came up with.

My LAN subnets

(services)

subnet 10.1.1.0/26

range 10.1.1.1->10.1.1.62

(internal)

subnet 10.1.1.64/26

range 10.1.1.65->10.1.1.126

(repairs aka lab)

subnet 10.1.1.128/26

range 10.1.1.129->190

(wifi, guests...etc.)

subnet 10.1.1.192/26

range 10.1.1.193->10.1.1.254

So, as mentioned above, if I want my desktop in my internal subnet to access a server in my services subnet such as a NAS for file sharing I would just open "Windows Networking (NETBIOS) in both directions and you're good to go.

Now the fun begins... Say you have a system you can't change the IP for that you plug into 10.0.10.0 that isn't on the same subnet as in my lab OR the whole 10.0.10 isn't on the same subnet which is the case for the OP. You can use your UTM to translate from one subnet to the other by giving the UTM a virtual address on the end network. This means your workstation trying to access from 10.0.10.XYZ with appear to come from 10.0.10.XYZ instead of its actual assigned address on the 192.168.25.0 network.

To do this you must complete the following tasks:

Give the UTM a virtual IP on 10.0.10.0 (lets say .2)

Create a host definition for your workstation to have an IP on the 10.0.10.0 network (lets say .3)

Create a DNAT rule for traffic from your workstation (or entire LAN) on the side you're coming from and going to your 10.0.10.XYZ host (or entire LAN) to be translated to the IP you created for our workstation(.3)

So now traffic from host 192.168.25.101 (for example) will talk to hosts on 10.0.10.0 using 10.0.10.3.

Open the firewall for the specific traffic(don't be lazy and do an any/any). If it's file sharing open using the group mentioned. If it's configuring a UTM open 4444...etc. Whatever you need.

The last key task here is that you must enable proxy arp on the interface of the UTM that is on the end network. In this case that would be the 10.0.10.0 network.

I use this often to preconfig a UTM I've sold before delivering it. That way the IP scheme doesn't require any changes when I get on site. Same applies to any gear I bring into my lab network that requires access to install files / backup resources or even remote desktop in whatever direction I want. This also totally isolates any infected systems I bring into my network and allows me to test stuff. I usually have a windows host sitting in there that I can use as a guinea pig.