Hello,
i have a OPNSense Box with 5 Interfaces. To keep it simple i will break it down to 3 Interfaces.
1.) LAN
2.) DMZ
3.) WAN
Like: https://i.stack.imgur.com/aFNLH.jpg
My goal is to allow traffic from the DMZ to the Internet.
How do i do that?
On the IRC Channel, i was told to:
- allow in DMZ Interface to any
- block in the DMZ Interface to LAN
=> which does work, but on a large Setup is dangerous and it gets complicated as hell. For example:
- if you add an IPSec Tunnel, you need to remeber to block it actively on the DMZ Interface
- if you add a route, you need to remeber to block it actively on the DMZ Interface
- if you add a interface or network, you need to remeber to block it actively on the DMZ Interface
Whats the right approach on this?
Thanks,
Mario
Hi,
One approach is to use policy based routing. Specify a WAN gateway in the "allow DMZ to any" firewall rule. This overrides the routing table and makes sure that anything coming in on the DMZ interface gets sent straight to the WAN. So you don't need additional block rules.
I would also be interested in better solutions, but so far this is how I do it for "Internet only" LANs (like DMZ and guest networks).
Cheers
Maurice
I would suggest creating an Alias:
Name: RFC1918
Type: Network(s)
Description: Private Networks
Content: 192.168.0.0/16,172.16.0.0/12,10.0.0.0/8
Now in your DMZ firewall rules, create a new Rule:
Action: BLOCK
Protocol: IPv4 *
Source: DMZ
Port: *
Destination: RFC1918
and add that before your "allow in DMZ Interface to any". Therefore any traffic to other private networks (your LAN interface and any future interfaces that are private networks) will be blocked, only "public" IPs are allowed.
You might need to add new rules to allow DNS and NTP (for example) before the RFC1918 rule.
Hope this helps a bit ;D
Thanks Maurice and Simser.
Can´t OPNSense not do it properly due to *BSD/pf or because its just not implemented in the GUI?
Hmm, what do you consider as "properly"?
@Simser, I would strongly recommend against this. It only works for legacy IPv4. And even then it doesn't work if you use public addresses internally. And there are probably other scenarios where it won't work.
@mohnewald, I think it's not a technical issue but a philosophical one. What would "do it properly" mean in your opinion?
Cheers
Maurice
i mean, in iptables you can match by IP and Interface like:
iptables -A FORWARD -i eth1 -s 192.168.1.0/24 -o eth2 -j ACCEPT
eth0 = LAN
eth1 = DMZ
eth2 = WAN
Which will make sure, that the traffic can not take a diffrent "route". This makes it more specific and easy to handle.
You can have a rule
Allow ANY !Alias_for_your_LANs
or
Block ANY Alias_for_your_LANs
and have an Alias for all the networks to be blocked (Alias_for_your_LANs).
@Maurice: You are right of course, I guess it depends on your scenario. With mine (only IPv4 and no internal usage of public IPs), this works. But I am interested to look deeper into your solution, might be useful elsewhere ;)
@mohnewald: Thanks for clarification.
@mohnewald, I'm not aware of a way to specify both a source interface as well as a destination interface in a single firewall rule in OPNsense. Not sure where that limitation comes from, not an expert on PF. I think you can create floating rules which match packets going out of specific interfaces. But I haven't tried this and am not sure if it actually would reduce complexity.
@chemlud, that's the way I did it before switching to PBR. Works, too, but like mohnewald said: You mustn't forget to include all your locally attached networks, routed networks, tunneled networks, ... to the "private networks" alias (and keep that list up to date). It's a blacklist approach ("allow all destinations but ..."). A whitelist approach ("allow no destinations but WAN interface / WAN gateway") is generally considered more secure. The nice thing about using PBR for "Internet only" networks is that adding additional private networks doesn't require special attention to block access to them.
@Simser, agreed that this approach might work for smaller legacy networks and I didn't mean to say that you, personally, shouldn't use it. Just wanted to clarify that recommending "just block RFC1918 and you're secure" as a generic solution is dangerous.
Does one of the Core Members know why it`s not possible to specify both a source interface as well as a destination interface in a single firewall rule in OPNsense?
Quote from: mohnewald on July 19, 2019, 09:08:02 AM
Does one of the Core Members know why it`s not possible to specify both a source interface as well as a destination interface in a single firewall rule in OPNsense?
One of the core members just created a feature request to at least allow "outbound" firewall rules without having to use floating rules: https://github.com/opnsense/core/issues/3594
Coincidence? ;)
[Edit]
He also answered your question there:
Quotepf doesn't support in / out interfaces per rule
[/Edit]