ANSWERED Clodo or others - nftables and Eddie help please

[iwih2gk 93]

SOLVED - SEE SOLUTION BELOW

Clodo,

(other linux guru's welcome to  chime in here - please)

I wasn't sure whether to post this here or in the Eddie forum.  You had posted (elsewhere in the forum) that Eddie now supports nftables in linux if the client is in "automatic" mode.  Having noticed that I am trying to use nftables on my buster machines and combine that with Eddie as my "way out" to the internet.   I am an absolute NEWBIE on nftables and I am not ashamed to admit it.  So I was thinking of the following scenario (which thousands of other users here could benefit from, seeing as how Debian future releases are going to be leaving IPTables):
1. Install nftables
2. configure nftable to flush on startup, then set "policy drop" hooks in a simple way so the machine is completely locked/blocked from going online at start. No exceptions.
3. then use the Eddie client to bypass that firewall setting Network Lock, and upon client exit the machine would return to locked via the nftables.

A. Is it possible for me to accomplish this task easily?  Would you care to paste in a simple nftable config I could copy to the config file that would achieve the "locked" firewall.  I want to study the flow but its over my head just a little at this point.

B. Would Eddie do an auto bypass if I start it, or would I need to create a custom path or whatever to bypass the nftable firewall.  The client used to bypass my UFW/IPtable firewall without any needed path entries "back in the day".  Thought maybe the same could happen here since nftables are now being recognized.

Paste of nftable conf file:

}flush ruleset

table inet filter {
chain input {
type filter hook input priority 0; policy drop;
}

chain forward {
type filter hook forward priority 0; policy drop;
}

chain output {
type filter hook output priority 0; policy drop;
}

[iwih2gk 93]

NFTables is now working on this Buster box, but I am a long way from finished.  I need to edit something in Eddie to bypass the "policy drop" in my conf file, which is posted above.  Observe my nftable conf above is super simple.  I want everything blocked except then  to allow Eddie using Admin privs to bypass the policy drops.  How can I do that?    Anyone??

Originally I could NOT get nftables to work and after rebooting several times I realized I needed to set the machine to start nftables on boot.

terminal
sudo systemctl enable nftables.service

For now in order to get online I have to flush the nftables  ---- >   sudo nft flush ruleset

Of course once I flush the ruleset the firewall is gone and I am back to Eddie's network lock.

This whole project has become important because there have been multiple times family members have neglected to connect via Eddie and have gone online using my ISP directly.  No thanks.  This is very important to me to prevent.  They are novice so I am trying in earnest to avoid using certificates and the network manager.  Eddie would be so much easier and then no restrictions on any of the hundreds of servers.
 

[iwih2gk 93]

I was kind of thinking something in the path or networking in Eddie.  Lost here, any help would make smiles on this end, LOL!

[nwlyoc 16]

Check out this post, there you will find a nftables ruleset (last file in the post) to block all traffic (except to airvpn and local traffic) and a boot script to activate the ruleset at boot (second script in the post). The latter is to be used as a systemd unit (4th file in the post) and also establishes an AirVPN connection, but you can just take the "acitvate_lock" function from it. It backs up the current ruleset (usually the default one set by the system) and activates the blocking ruleset. This is used with a systemd unit because the nftables ruleset always resets at boot. When Eddie/Hummingbird is started, it will do basically the same thing as the boot script – backup the current ruleset (which is now the one blocking all traffic) and replace it with its own ruleset. When Eddie/Hummingbird is closed, it will put the blocking ruleset back in place. So you don't have to set anything up inside Eddie to make it work. Just make sure to tell Eddie to use nftables (it won't default to nftables if iptables is also installed) and make sure nothing else on your system interferes with the firewall. Also, in case you use SELinux (not the default on Debian though), make sure to read the part about SELinux and nftables in the linked post.
Hope this helps!

[iwih2gk 93]

nwlyoc,

Thanks for trying to help me.  Your solution is currently beyond my understanding, which may seem hard to believe but it is.  Is it not possible for me to simply open a hole (in the nftable I already have) in the firewall for airvpn to connect and then have Eddie do everything else including setting the network lock?  I want to launch Eddie from the desktop on Debian systems for my family.  If this can't be done without extra scripts to "click on" every time then these folks won't use such a method.

NFtables are so new to me.  This worked great for me back with IPtables on Debian < Stretch versions, but its changed now.  Please feel to display a rule to open a hole in nftable if such a simple solution is doable.

Sorry for my infancy with nftables.

[nwlyoc 16]

No problem, getting into it is the only way to learn about it anyway I guess ;)
If you already have your desired nftables ruleset in place, you don't need the script. That was just an example how to automate activating a ruleset at boot. I don't think you need to open a hole or anything in your ruleset for Eddie since Eddie's network lock will replace your whole ruleset anyway while it's active. I use Hummingbird instead of Eddie, but I just looked it up and it seems as of Eddie 2.19.1 the network lock actually even does default to nft if present (contrary to what I wrote before). So if you put your own ruleset in place and then start Eddie with its network lock, everything should work. You just shouldn't manipulate the nftables while the network lock is active. What exactly is not working? And what version of Eddie are you running?
To check if Eddie's network lock works you could run "sudo nft list ruleset" before you activate the lock (the output should be your own ruleset) and again after you activate the lock (now the rules should have changed).

[nwlyoc 16]

Actually the problem might be that you need to allow communication with your router in your "blocking everything" ruleset for Eddie to establish a connection. I suspect it's because a DNS query of an AirVPN server that is made before Eddie sets its own DNS server and fully initializes its network lock (looks like that in the logs). Often your own router will be set as the DNS server (you can check in /etc/resolv.conf while Eddie is not running) which in turn usually uses your ISP's default DNS server. So to make that work you need to allow communication with your router in your own ruleset by adding the line "ip saddr 192.168.0.0/16 ip daddr 192.168.0.0/16 accept" to your output chain (in case your router is actually set as the DNS server in /etc/resolv.conf – if you use a custom DNS server, you would probably need to allow its IP address) and the line "ct state established,related accept" to your input chain (to allow established connections – in this case the answer for the DNS query).
Let me know if that works or if that was too unclear.

[iwih2gk 93]

nwlyoc,

I am running the latest 2.19.4 Eddie.  Its is set to nftables in preferences as well.

When I click on Eddie it locks up/freezes and does nothing.  If I flush the NFTable Eddie immediately boots up and away I go, but of course that is because in effect I have turned nftable off removing the rules.

Paste after mounting Buster and using terminal before even attempting to click on Eddie:
XXX@debian:~$ sudo nft list ruleset
[sudo] password for XXX:
table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy drop;
    }
}
_________________________________________________

I can't go anywhere because of the general policy drop settings, of course.  Eddie freezes/won't start and then I flush nftable.  I checked "sudo nft list ruleset" after flush and of course there is nothing there.  Then I connect to Eddie and go back and look at "sudo nft list ruleset" to notice that Eddie has created a large ruleset and I can confirm the network lock is working via dnsleaktest.com.  When I exit Eddie I go back to "sudo nft list ruleset" and notice there is nothing there because I had flushed the ruleset before connecting.

So now I am back to the original question.  What can I do to permit Eddie to connect without having to flush the ruleset my system raises upon boot?  Eddie does write whatever ruleset back upon exit so it is working in every way except I can't connect.  Hmm!
 

[iwih2gk 93]

5 minutes ago, nwlyoc said:

Actually the problem might be that you need to allow communication with your router in your "blocking everything" ruleset for Eddie to establish a connection. I suspect it's because a DNS query of an AirVPN server that is made before Eddie sets its own DNS server and fully initializes its network lock (looks like that in the logs). Often your own router will be set as the DNS server (you can check in /etc/resolv.conf while Eddie is not running) which in turn usually uses your ISP's default DNS server. So to make that work you need to allow communication with your router in your own ruleset by adding the line "ip saddr 192.168.0.0/16 ip daddr 192.168.0.0/16 accept" to your output chain (in case your router is actually set as the DNS server in /etc/resolv.conf – if you use a custom DNS server, you would probably need to allow its IP address) and the line "ct state established,related accept" to your input chain (to allow established connections – in this case the answer for the DNS query).
Let me know if that works or if that was too unclear.


Let me run this down and see what I find.  I cannot tell you how much I appreciate your help.

[nwlyoc 16]

(Seems we answered at the same time – check my last answer if you haven't seen it yet and see if that works.)
Edit: okay apparently you saw it, this reply makes no sense anymore, but I can't find a way to delete it.

Edit 2 (making some use of this wasted reply): Be aware that if you go with the mentioned way (allowing communication to your router for DNS queries) your ISP will still get all your DNS queries. So for example if you type "google.com" in your browser's address bar, nothing will happen (because of your blocking ruleset), but your ISP will still know that you tried to reach Google (this is only the case while you are not connected to AirVPN). So if you want to have more privacy from your ISP, consider changing your DNS server either on the router or on your system (in /etc/resolv.conf – this file can be changed by DHCP though when connecting to networks, preventing that is a different topic; in this case you would need to allow communication with the DNS's IP instead of your router in your rules) to an independent DNS server of your choice. And if you want to go full privacy mode, you could even put restrictions in place so that only queries about AirVPN could go out, but I believe this is very much over the top for your needs ; )

[iwih2gk 93]

I appreciate your suggestion in Edit 2 above but that is not a problem on this end.  My point is to never allow users go anywhere without Air - EVER.  The FF browsers are set to go to Duck Duck Go (home page) when they are opened.  My users would see "we cannot find that site" so they would know to connect to Air. I don't care if my ISP sees a search engine click.  Once Eddie engages all activity will be outside of my ISP's eyes, LOL!  I never allow LAN in Eddie either because I don't trust network TV's and such.

It is going to be awhile until I get around the house.  Is it possible for you to simply paste the rule addition into the conf file I have above, adding the rule you suspect will solve this issue?  Again, sorry for the Kindergarten approach here.

referenced above ------ >    ip saddr 192.168.0.0/16 ip daddr 192.168.0.0/16 accept

[nwlyoc 16]

Sure, something simple as this should hopefully be enough:

flush ruleset
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
ct state established,related accept
}

chain forward {
type filter hook forward priority 0; policy drop;
}

chain output {
type filter hook output priority 0; policy drop;
ip saddr 192.168.0.0/16 ip daddr 192.168.0.0/16 accept
}

[iwih2gk 93]

17 hours ago, nwlyoc said:

Sure, something simple as this should hopefully be enough:

flush ruleset
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
ct state established,related accept
}

chain forward {
type filter hook forward priority 0; policy drop;
}

chain output {
type filter hook output priority 0; policy drop;
ip saddr 192.168.0.0/16 ip daddr 192.168.0.0/16 accept
}

No go.

I pasted this suggestion above into my nftable.conf and rebooted Buster.  I was watching the boot and I saw two "red" letter flags telling my nftables did not start.  I was able to grab Eddie immediately without a firewall of course.  There is something in the syntax above that Debian Buster doesn't like.

These new symbols (as opposed to IPtables) are killing me.  NFtable sounds so simple: Create a Table, Place a Chain in the Table, add rules to a Chain.

Any suggested edits to above?  I am wondering if pasting is the issue as opposed to manually entering the file?  I have time today to hammer away on this.  I'm here on and off but mostly here.

[Staff 9972]

1 hour ago, iwih2gk said:

There is something in the syntax above that Debian Buster doesn't like.

Hello,

nobody likes a missing closing bracket.

Kind regards
 

[iwih2gk 93]

2 hours ago, Staff said:

Hello,

nobody likes a missing closing bracket.

Kind regards
 

Thanks.  Placing the closing bracket allowed nftable to fire right up.  BUT the simple little firewall doesn't work for allowing Eddie to connect.

Nwlyoc or Staff,

If you run across this and have any other ideas for what I can try and edit let me know.

[nwlyoc 16]

5 hours ago, Staff said:

nobody likes a missing closing bracket.

Sorry, should have checked after copying the example from the original post.

As for the problem: I just did some testing with the ruleset and could reproduce the error with the ruleset above. It seems the problem was that loopback wasn't allowed. Please try the following ruleset with loopback allowed:

flush ruleset
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
iifname "lo" accept
ct state established,related accept
}

chain forward {
type filter hook forward priority 0; policy drop;
}

chain output {
type filter hook output priority 0; policy drop;
oifname "lo" accept
ip saddr 192.168.0.0/16 ip daddr 192.168.0.0/16 accept
}
}

[Staff 9972]

@nwlyoc
@iwih2gk

Good to know you solved the issue!

Eddie "frontend" and "backend" communicate. If you block lo or even just localhost, you not only block Eddie communications, but even any other communication of your system with itself (i.e.any process with any process), with all sorts of bad consequences.

Kind regards
 

[iwih2gk 93]

nwlyoc,

THANK YOU!!  Your solution addressing loopback was the aspect I completely disregarded.  I have tested this inside my nftable conf and examined its effectiveness alongside Eddie.  They "like" each other now, LOL!  As expected Eddie replaces the nftable ruleset on exit.  Looking at sudo nft list ruleset before Eddie, during Eddie, and after Eddie its all working perfectly now.

Staff,
I wanted to thank you and the other Admins here that foster an atmosphere where members come in and help each other when those learning new skills need help.  This is why I know I speak for many members ------- we will NEVER leave Airvpn.  Great place to learn and keep yourself safe online.

Just as a summation for any folks reading along on this thread.  The whole purpose here was to develop an nftable firewall that you could put on your linux OS.  Using this means you can simply block all non-Eddie traffic, BUT have the convenience of the Air Eddie client.  Currently many members are writing certificates from the generator, which are effective but limiting if you want access to the hundreds of servers you could access with Eddie.  Now you get them all without risking WAN traffic ever getting outside of Air.  Before you pause and say to yourself I'll just put Eddie on my Desktop.  I won't accidentally ever go online without connecting, let me assure you that it WILL happen.  We are all human and especially if you have family members that just want to surf and could care less about security.

Debian is going to do away with IPTables and I think Bullseye may mean the loss of that firewall structure.  You may as well start learning nftable now.

Credit for this great little firewall goes to nwlyoc.  You can't make anything more simple for such an important task.  Enjoy this if you want your system configured as mentioned above in this thread.
 

flush ruleset
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
iifname "lo" accept
ct state established,related accept
}

chain forward {
type filter hook forward priority 0; policy drop;
}

chain output {
type filter hook output priority 0; policy drop;
oifname "lo" accept
ip saddr 192.168.0.0/16 ip daddr 192.168.0.0/16 accept
}
}

[Staff 9972]

14 hours ago, iwih2gk said:

Staff,
I wanted to thank you and the other Admins here that foster an atmosphere where members come in and help each other when those learning new skills need help. This is why I know I speak for many members ------- we will NEVER leave Airvpn. Great place to learn and keep yourself safe online.

Thank you!

As a small addition to your kind words, for you and all the readers interested in practical examples to set up permanent Network Lock rules with nft and MUCH more, you can:

• observe rules while Hummingbird is connected to some VPN server with network lock set to "nftables" mode
• examine the Bourne Again Shell scripts by @nwlyoc (yes, again 👏 ) https://airvpn.org/forums/topic/46717-interactive-wrapper-for-hummingbird-with-boot-script-and-default-network-lock/

Kind regards

[nwlyoc 16]

I'm glad it works now, happy to help out!
And thank you for the honorable mentions. I too appreciate this forum as a place to learn and support, already picked up a lot of interesting stuff by choosing this VPN
I will soon update and move the mentioned scripts to Gitlab to make them better accessible easier to examine.