Reconciling Top-down Rule Processing
-
I understand that rules are processed on a top down basis so that the first matching rule is processed and subsequent rules are ignored. If that is the case then I cannot reconcile why the first rule and the last rule of the following rule set are both being observed.
The first rule definitely allows my 192.168.10.135 machine to ping hosts on the 192.168.50.0/28 subnet. Similarly the last rule definitely allows my 192.168.10.135 machine to open web pages hosted on the 192.168.50.0/28 subnet. With both rules enabled I have both pinging and open web page capability. Disable one of the rules and the respective capability is lost.
I do not understand how the observance of both these rules can occur if the top down to the first match principle applies.
-
@brucexling
ICMP is a protocol
TCP is a protocolThe ICMP rule would not match a TCP packet , and it will drop further down for evaluation.
Since there's no explicit deny's (except the "invisible" at bottom)
Packages not matching the current line will just drop down to the next line
/Bingo
-
Got it. Many thanks.
-
@brucexling I might be confused here and I don't know your network layout, but what are you actually using these outbound NAT rules for? Do your voip phones only respond to traffic from their own subnet or something unusual like that? Otherwise I'm not understanding the need to NAT that traffic like that.
-
My network looks like this at present:
I have a second router on the voip vlan which is supporting a low latency cellular WAN for my phones. This arrangement gives much better voip performance compared to when I had everything on the one LAN. I realise that it would be more secure to use the spare OPT on the pfSense box for the cellular WAN, but this is what I have at the moment. The icmp rule in the settings above was only for testing purposes while I am getting my head around rule processing. The last rule for tcp (which I normally have at the top of the list) allows me to administer the ATA and the MR3020 from my admin machine on the default LAN at 192.168.10.135. I am sure that many things could be done to improve this network, but this is where I am up to with my work-in-progress. I would welcome any suggestions to improve what I have.
-
@brucexling I'm still not getting why you need to use outbound NAT rules at all just to get from LAN to VLAN_50. The default Allow All to Any rule should let LAN clients go anywhere. You use outbound NAT to control the source address and ports. Just going from LAN to VLAN_50 shouldn't require anything extra. Are you perhaps mixing up firewall rules and outbound NAT rules?
-
Yeah with @KOM - why are you natting outbound to your voip vlan? Why would you think you should source nat here?
-
I’ll be the first to concede that I’m still floundering when it comes to rules. I’ve now clipped out all rules that seem to me to be extraneous to the issue being tested by me. The Outbound NAT Rules, the firewall Rules for LAN and the firewall Rules for Voip_50 are now as follows.
With this rule set I can access the devices on Voip_50 from my admin machine at 192.168.10.135. If I disable the first rule in the Outbound NAT rules I then lose the access. I can only plead that I stumbled upon settings that did work. It would be really good if you could suggest how I could get it all working with sensible settings.
-
@brucexling I think I see what's happening. Because your phones are using the OpenWRT router as their default gateway, then normal traffic from your LAN would be replied to out the OpenWRT router. That traffic can't be routed back to your LAN using that router. Using outbound NAT tricks the phones into thinking the LAN traffic coming from pfSense is within its own subnet and so it replies back to pfSense, which relays it back to your LAN client. That's valid and will work but there are a few other ways to do it.
-
Yup, I would say it's exactly that. The phones have no route back to the LAN subnet without that OBN rule.
Steve
-
@kom said in Reconciling Top-down Rule Processing:
That's valid and will work but there are a few other ways to do it.
@stephenw10 said in Reconciling Top-down Rule Processing:
Yup, I would say it's exactly that.
I am very pleased to have this NAT method somewhat endorsed. I was becoming nervous that I had created something that was going to turn around and bite me. I was not concerned about the additional NATting because it would only be used to occasionally admin into the ATA and MR3020 router. The normal operation of the phone system carried on oblivious to anything else on the LAN/VLANS. In fact I can cut the power to the pfSense box without any effect on the phone system. Kom, I am interested in your comment that “there are a few other ways to do it”. Without going into too much detail I would be keen to know the directions these other ways might take. Thank you to everyone for your encouragement.
-
@brucexling Other ways to do it would involve setting up the OpenWRT router as another gateway for pfSense, and you could use policy routing to force only the voip traffic out that gateway, but that would stop your phones if pfSense was rebooted or down. You seem happy with what you have so go with that config.
-
Yup, that.
Or have a transport subnet between the two routers with static routes over it so each has a route to the subnets on the other. That could be a separate VLAN between them.
'Two routers, one subnet' is almost always a bad idea. You can work around it with outbound NAT rules like that but it's much cleaner to avoid it.
Steve
