[SOLVED]Firewall interface assignments in/out/local

[reno138]

Hello again all –

I keep running into things that

a) I just don’t understand well enough to get my head around

b) thing are happening that shouldn’t happen

c) a and b

My ignorance is definitely a contributing factor here, but I’m learning…

Since that’s out of the way, here’s what I’m running into today -

eth0 <- WAN interface with 3 public IPs
eth1(vif 18,19,20)

I made a simple firewall to apply to eth0, allowing some traffic to get to a mail server, and I’m 99% sure that the firewall config is good.
When i apply the firewall to eth0 “in”, I can no longer get to the internet from internal networks. It stopped all traffic from inside -> outside
When I assign it to “eth0 out” I’m able to access the internal mail server from outside, and ICMP is dropped as it should be.

So, firewall works when assigned to “eth0 out” as configured, assigned to “eth0 in” it stops all traffic from inside to outside. It’s completely backwards, and I’m wondering why.
I’m using the latest build from today (5/23)…

Has anyone else run into this? Am I just doing something very wrong, or do the words “in” and “out” have different meanings when it comes to vyos?

Thanks in advance, again.

–reno

[ngoehring]

I have always found the following graphic to be extremely helpful with IN, OUT, LOCAL. It’s from the Ubiquiti EdgeMax forums (still Vyatta-based so lots of similarities to VyOS). Hope it’s of help to you:

https://community.ui.com/questions/Laymans-firewall-explanation/2dafa379-3269-4749-b224-0dee15374de9

[reno138]

That’s pretty much how I had it in my head, too.
That’s why confused. When I assign the firewall to the wan interface as “in” it blocks outgoing traffic. But when I assign it to the wan interface as “out,” it works as expected.

Ex with eth0 being the wan interface

set interfaces ethernet eth0 firewall in name OUTSIDE-IN <- This stops outbound lan -> internet traffic.

set interfaces ethernet eth0 firewall out name OUTSIDE-IN <- this works as I would expect when assigned to “in.”

I’m confused, to say the least.

The firewall is a very simple all-ping disable, default drop, one rule to allow tcp connections to a dnat rule on http(s) and smtp ports. Definitely not doing anything fancy. It just doesn’t make any sense whatsoever to me…

[Jeff]

The old Vyatta documentation may be on some help here, you can find it at this address:
http://0.us.mirrors.vyos.net/vyatta/vc6.5/docs/

The firewall part has some nice graphics explaining the interactio between firewall and NAT that is very useful. For example:

(Due to copyright VyOs cannot blindly copy this doc on its wiki).

[ngoehring]

I think you have confused the way the directions work. The behavior you are seeing is what one would expect.

WAN-IN should essentially be default drop and with rules to allow established/related states. It keeps all connection attempts that didn’t originally originate from the network from coming in. Your use indicates you have an internal server so you would have dnat rules to allow new (state new enable) connections to come in.

WAN-OUT is generally essentially accept all since that is your pipe out and is the gateway for your internal network connections getting out to the world. You could set up drop rules if you had devices you didn’t want to get out to the Internet.

From what you have provided, you should have a WAN-IN firewall with rules to do exactly what you described above and is applied to the IN direction of your WAN. You also need a WAN-OUT firewall that has a a default action of “action accept” and is applied to your interface on the OUT direction. If you have any service running on your router that you want to get through to (ssh, wireguard/vpn) then you’d need to make sure you had a WAN-LOCAL firewall, default drop but then allow connections (state new enable) on the ports that those services run on.

In other words, you need 3 firewall definitions. 1 for WAN-IN, 1 for WAN-OUT, and 1 for WAN-LOCAL.

Make sense?

[reno138]

@ngoehring Makes perfect sense, but it doesn’t seem to be working that way –

So, here’s where I’m lost.

This applied to eth0 “in” -

vyos@vyos# show firewall name OUTSIDE-IN
 default-action drop
 rule 1801 {
     action accept
     destination {
         address 172.16.18.5
         group {
             port-group MAILPORTS
         }
     }
     log enable
     protocol tcp
     state {
         established enable
         new enable
         related enable
     }
 }
 rule 5001 {
     action accept
     source {
         group {
             address-group ALL-INSIDE
         }
     }
     state {
         established enable
         new enable
         related enable
     }
 }
[edit]

This (or nothing) applied to eth0 “out”

 vyos@vyos# show firewall name INSIDE-OUT
 default-action accept
 rule 5001 {
     action accept
     source {
         group {
             address-group ALL-INSIDE
         }
     }
     state {
         established enable
         new enable
         related enable
     }
 }
[edit]

And this (or nothing) applied to eth0 as local

vyos@vyos# show firewall name OUTSIDE-LOCAL
 default-action drop
[edit]

If I assign the first (OUTSIDE-IN) to eth0 “in”, traffic from inside -> out stops

If I assign OUTSIDE-IN to eth0 “out” traffic flows, and the ruleset for OUTSIDE-IN work as expected

That’s where I’m confused. Why would it only work when applied to “out”? Just to be clear - When I assigned OUTSIDE-IN to eth0 (the WAN interface) all rules work as expected. I can get to the machine internally. If I have all-ping disabled, I stop getting ping replies when it’s assigned to “out”

Rule 5001 on OUTSIDE-IN was just an attempt to try to get it working, not normally there. It didn’t change anything, anyway.

It’s like it started working backwards for some reason.

Am I just wrong here? I feel like it’s either broken, or I’m missing some very basic thing that my head just isn’t getting around.

[reno138]

OK, I missed the one thing I should have seen all along…

I didn’t add a rule for all related and established connections to the OUTSIDE-IN ruleset.
Yeah, it was something super simple that I was overlooking. Again.

Thanks all for your input. I’ll write this one down as a lesson learned.

[ngoehring]

Glad you got it working. The established/related lines are certainly important. There is a cool feature with Vyos where you can set those states as enabled to dropped as a system-wide default so that you don’t have to include the rule for them. Helps save a few keystrokes and I personally don’t see a problem with it as long as one understands what’s going on.

This can be invoked via:

set firewall state-policy established/related/invalid action [accept | drop | reject].