Apply a rule to an specific outbound interface
-
I'm using the pfsense WebGUI to learn how it works, and just as title says, I was wondering how can I add a rule where the outgoing interface can be specified.
I mean, I want to add an interface rule in LAN that permits sending echo-requests over Internet through the WAN interface. The problem is that I don't know how to specify the outgoing interface, and therefore, LAN net is allowed to ping everyone in the network.Should I just block echo-request packages addressed to the rest of the networks other than WAN, or there is a fancier way?
-
@full-malito said in Apply a rule to an specific outbound interface:
I'm using the pfsense WebGUI to learn how it works, and just as title says, I was wondering how can I add a rule where the outgoing interface can be specified.
I mean, I want to add an interface rule in LAN that permits sending echo-requests over Internet through the WAN interface. The problem is that I don't know how to specify the outgoing interface, and therefore, LAN net is allowed to ping everyone in the network.Should I just block echo-request packages addressed to the rest of the networks other than WAN, or there is a fancier way?
Yeah, pfSense does not have provisions for specifying destination interfaces in rules - well not intirely.
There are built in groups called “Interfacename Network”, and they contain all the addresses behind an interface - you can use those as a destination and solve your need - EXCEPT for WAN - Unfortunately there is no such builtin group for WAN (Because it has the default gateway).
I have often wondered why they do not make a built in “WAN network” which in essense is a “!Internal Interfaces networks” group. But there are likely some issues with this line of thinking that I’m missing. @stephenw10 Do you know why?I try to avoid using “ANY” as destination on all my rules, so for internet access rules I do the following:
1: Create an alias with all the internal networks. Ususally I just make it contain all RFC1918 (Private networks for IPv4).
2: For Rules that should only give Internet Access, the destination is the inverse of that AliasGroup (!Alias - NOT Alias)This works well for IPv4. It gets a LOT more complicated for IPv6 - In fact IPv6 is just a nightmare Firewall wise because of privacy addressing, dynamic/shifting delegated prefixes and what not….
-
@full-malito said in Apply a rule to an specific outbound interface:
LAN net is allowed to ping everyone in the network
LAN devices pinging each other don't go through the router anyway.
You can do things like:
block ICMP from LAN to VLAN5
allow ICMP from LAN to any@keyser There is actually a "WAN Net" network alias which is the subnet of the WAN interface. Any higher level alias might get messy/confusing, for instance, if one interface had public IPs is that "not internal"? What if WAN2 existed, or was called DMZ not WAN2?
-
@full-malito said in Apply a rule to an specific outbound interface:
The problem is that I don't know how to specify the outgoing interface
Basically you can do this with floating rules. You can assign floatings to any interface, as well to multiple, and you can state the traffic direction it should be applied to.
You have to check the Quick option to make the rule applied before interface rules.Ordinary interface rule are applied to inbound connections only.
However, together with an RFC1918 alias as suggested by @keyser you are able control any traffic you can think of.
In your case for blocking pings to the internet, add a block rule to LAN for ICMP protocol and enter the alias at destination together with invert checked. So this rule blocks any destination, but networks in the RFC1918 alias. -
@steveits I just realised my own post is “ambigious” at best.
I have somehow lately convinced myself that the built-in “Interface networks” aliases also contained any subnets routed to a gateway behind a downlevel router on the same interface.
That is not the case. They ONLY contain the actual IP Subnet the Interface IP Address is a member of.
It made a lot of sense to me as rules using those built-in groups would need no updating if routing internals is changed. But I was wrong… I guess that’s why so many people use ANY in a lot of pfSense rules (I HATE the use of ANY because it creates a LOT of security holes as the network grows.)
I accept that my mistaken understanding of the group equates it to ANY when used as a souce restriction.
But my mistaken understanding makes destination use of the alias MUCH more adaptive to routing changes - without making the collosal catastophic opening that ANY would mean. -
@steveits Thanks for the advice, it worked.