Linux Prevent Leaks with Linux & Firestarter (also Stop traffic when VPN Drops)

[Guest]

Is it possible to add UFW rule like "allow out from any to <ip address of server>" but for dynamic DNS like nl.airvpn.org? Even if I manually add all servers from this area it still won't work.

 

Resolved hosts option in config generator is not working anymore I believe. It generates config for single server only.

[not_a_salamander 0]

delete me

[JpvEXonHrB 0]

@Believer_01 @stupidcats @CriticalRabbit @fe719bf5 and anybody else who is having troubles with gufw/ufw and the instructions @worric posted. You need in rule #1 of gufw/ufw a dns server "allow out all interfaces anywhere <DNS IP>" else it will not be able to resolve anything which in turns results in no connection out. It is working fine for me after adding DNS in rule #1. I think @worric forgot to mention that in his original instructions and he blanked out the DNS in the screenshot.

 

Also just as a note if you are using gufw to configure, in all the rules @worric posted with Anywhere in them, make sure in gufw you write "any" in IP section, and not leave the IP blank, else the rule will not work.

[not_a_salamander 0]

Following @randombit 's tutorial things are working but I'm curious if anyone's getting the same curious ufw logs:

 

• [open Firefox]: [local dhcp ip] on [local adapter]->outgoing block to [vpn ip]:80 -- not a "continuous" log but happens after the first couple of minutes of FF being opened. At first I thought this might have been related to FF52's new "captive portal detection" feature but after disabling network.captive-portal-service.enabled, the same behavior exists.
• [upon allowing forwarded tun0 port] : [local dhcp ip] on [local adapter]->outgoing block to [vpn ip]:[forwarded port] -- regularly repeating log, but not every second.

 

Everything appears to be fine otherwise. Any ideas?

[not_a_salamander 0]

Following @randombit 's tutorial things are working but I'm curious if anyone's getting the same curious ufw logs:

 

• [open Firefox]: [local dhcp ip] on [local adapter]->outgoing block to [vpn ip]:80 -- not a "continuous" log but happens after the first couple of minutes of FF being opened. At first I thought this might have been related to FF52's new "captive portal detection" feature but after disabling network.captive-portal-service.enabled, the same behavior exists.
• [upon allowing forwarded tun0 port] : [local dhcp ip] on [local adapter]->outgoing block to [vpn ip]:[forwarded port] -- regularly repeating log, but not every second.

 

Everything appears to be fine otherwise. Any ideas?

 

A small update on this: even if you don't forward any ports on tun0, ufw will still complain that it's trying to use [local dhcp ip] to try to connect to [vpn ip]:[app-specific incoming port] -- notice how this is still an outbound block though, which is weird. Now obviously, tun0 is ultimately making the outbound connections on behalf of the routed traffic so this is "not really a problem," but again, I find it curious on why apps use the lan ip over the tun0 ip "firstly" when making outbound connections. Could this be an "order of preference" issue -- perhaps brought on by the recent updates to network-manager? And yes, UPnP is disabled everywhere. Looking back at the guide again, should the rule Anywhere on tun0 be placed at slot #1 instead of #3?

[not_a_salamander 0]

Just to follow up on my posts, there is another blocking message you may be wondering about. [local ip]:5353 -> 224.0.0.[x]:5353 -- this is a mulitcast address and it basically exists so you can be lazy on the network and "discover" printers, "files to look at, and people to talk to." -- according to the arch wiki. If you're a purist, you want this immediately terminated and, if you wanted to actually connect to a device on your network, you would manually type in the correct address of said device. Solution to the problem:

# systemctl disable avahi-daemon
$ reboot

After that, no more "discovery" attempts on the network.

[not_a_salamander 0]

After that, no more "discovery" attempts on the network.

 

This is especially useful considering today's shit-show of "cyber attacks" affecting the UK's NHS and various places around the world affecting antiquated windiz boxes. Who knew that a lowly SMB vuln could cause so much damage and corporate losses?

 

Btw, while this doesn't affect us on (proper) distros, it's always best practice to stop network propagation especially if you have antiquated windiz boxes on your network (for whatever reason.)

[bananaphone69 0]

Hi. I use a similar, though not identical method and was wondering how I might go about setting up an SSL or SSH connection using a network manager.

[Netpun 0]

Thanks!