Hummingbird on Linux: Making exceptions to default gateway for a service/application?

[nexsteppe 24]

I'm running hummingbird 1.0.2 on Linux x86-64.  The default DNS pushes and iptables "network lock" work exactly as they should, ensuring that all traffic destined for the greater network are tunnelled through Air's servers.
But I have one service I wish to always run "in the clear" (i.e., sans VPN).  It occupies a single port for both TCP and UDP, and my router's firewall is already configured to allow traffic from outside to directly reach these ports.  Is there a clean way to make an exception for this service in hummingbird's DNS and iptables rules?
Ideally, I would like to be able to start or stop my Air connection at will without affecting this service while still ensuring all other traffic is properly tunnelled when hummingbird is running.
Any suggestions or pointers appreciated.

[NaDre 157]

This might point the way:

https://github.com/tool-maker/VPN_just_for_torrents/wiki/Maintaining-SSH-Access-Using-a-VPN-on-a-Remote-Linux-Server

The title says "SSH", but it is about allowing any remote access via the real interface while the VPN is the default gateway.

However the firewall rules there may conflict with what Hummingbird sets up (I do not know). You may have to drop "Network Lock" and re-implement it for yourself, with necessary adjustments. You could also extend the firewall rule that applies the "connection firewall mark" to only apply the mark for one port if you wanted.
 

[eburom 16]

Hi, not an expert but I've been using hummingbird for some time and I don't think there is such a fine tuning of the network lock designed in the application.
Soon there will be a new release that might address such customization, or at least the "allow local network" and such options present in eddie (hummingbird allows it and that's it).

As I see it, you have 2 options:
1. Handle your firewall yourself and launch hummingbird with network lock off.
2. Manually change the rules after running hummingbird with network lock. (The suggested method might not work, explained in a post below).

For the first scenario you can inspect the rules set by hummingbird for network-llock and use those as an starting point. You will have to be careful guessing the AirVPN servers entry IP so hummingbird should succeed reaching to it.

For the second, you can run hummingbird from a script that also adds the rules you need.

#!/bin/bash

/usr/bin/hummingbird /PathToMyFile/configFile.ovpn

# Alter the rules here.

So when you run it everything happens fast and automatically.

For what I see, even the default policy is to DROP incoming packets network-lock adds a last DROP rule that might interfere before the rules you add so I guess that you should handle that  too.
So I guess your additional section should look something like:

iptables -D INPUT -j DROP
iptables -A INPUT YOUR_CUSTOM_INPUT_RULES
...
iptables -A INPUT -j DROP

And something similar for whatever output rule you need.

I think Hummingbird only writes rules at the very beginning. In fact, it makes a backup of the current rules, and then sets its owns. (Extended explanation in a post below). When stopped (or called with --recover-network option) it restores the original ones.
So this approach should be save.

As a warning, I haven't tried any of this
  Edited ... by eburom
Corrections based on things I learned.

[NaDre 157]

2 hours ago, eburom said:

Hi, not an expert but I've been using hummingbird for some time and I don't think there is such a fine tuning of the network lock designed in the application.
Soon there will be a new release that might address such customization, or at least the "allow local network" and such options present in eddie (hummingbird allows it and that's it).
...

Did you look at what I posted above?

"When you start a VPN on a remote Linux server your SSH connection drops, and you cannot connect to your server over SSH.

The problem is that the default gateway gets changed by the VPN, by adding routing table entries that hide the original gateway's routing table entries, and that breaks your current SSH connection unless you set up appropriate routes before you start the VPN."
 

Just to be clear, this problem will be present even without "Network Lock". Or even if the VPN is not set up using OpenVPN. The issue is with how routing is done in Linux by default in a "multi-homed" network. Remote connections to the real interface will fail while the VPN is the default gateway, unless you take steps such as in my post above.

AirVPN has never shown an interest in having their clients directly support "traffic splitting".

 

[nexsteppe 24]

Thank you for (both) for your helpful replies.
With the advice given I was able to "split" traffic but there seems to be less finesse for DNS, all traffic using Air's nameservers when the tunnel is up.  There doesn't seem a clean approach to this.
I'm probably better off just setting up a separate machine for the service in question and leaving it at that.

[eburom 16]

Glad it helped.
Just in case someone comes across these answer I would like to rectify a couple of things from what I learned lately.
It seems I was wrong about hummingbird only changing the network lock at the very beginning. (At least for the current version of hummingbird: 1.0.3).
The other day I got some connection problems that led my airvpn connection to a weird state (I posted the logs in the thread where hummingbird 1.0.3 was announced).
In addition to the connections state, in the logs I could find that when the system decided to reconnect, DNS and network lock got restored (back to normal) before being set again.
This means that any extra rule added with the second method I proposed would get overwritten and lost.
I also think that hummingbirds decision of restoring the network lock and DNS even though being for a moment is a risky move from a security point of view. (But I'm not an expert here).

The part of the logs that make me think this:

...
Sun Jun  7 00:58:19.242 2020 ERROR: HANDSHAKE_TIMEOUT
Sun Jun  7 00:58:33.957 2020 ERROR: KEY_STATE_ERROR
Sun Jun  7 00:59:19.061 2020 ERROR: KEY_STATE_ERROR
Sun Jun  7 00:59:19.169 2020 ERROR: N_KEV_EXPIRE
Sun Jun  7 00:59:19.169 2020 ERROR: N_KEV_EXPIRE
Sun Jun  7 00:59:19.242 2020 ERROR: KEV_NEGOTIATE_ERROR
Sun Jun  7 00:59:19.242 2020 ERROR: HANDSHAKE_TIMEOUT
Sun Jun  7 00:59:19.242 2020 Session invalidated: KEV_NEGOTIATE_ERROR
Sun Jun  7 00:59:19.242 2020 Client terminated, restarting in 2000 ms...
Sun Jun  7 00:59:19.242 2020 net_route_del: 8000::/1 via fde6:7a:7d20:c9c::1 dev tun0 table 0 metric 0
Sun Jun  7 00:59:19.242 2020 net_route_del: ::/1 via fde6:7a:7d20:c9c::1 dev tun0 table 0 metric 0
Sun Jun  7 00:59:19.243 2020 net_route_del: 128.0.0.0/1 via 10.16.156.1 dev tun0 table 0 metric 0
Sun Jun  7 00:59:19.243 2020 net_route_del: 0.0.0.0/1 via 10.16.156.1 dev tun0 table 0 metric 0
Sun Jun  7 00:59:19.243 2020 net_addr_del: fde6:7a:7d20:c9c::107c/64 dev tun0
Sun Jun  7 00:59:19.243 2020 net_addr_del: 10.16.156.126/24 dev tun0
Sun Jun  7 00:59:19.243 2020 net_iface_mtu_set: mtu 1500 for tun0
Sun Jun  7 00:59:19.243 2020 net_iface_up: set tun0 down
Sun Jun  7 00:59:19.244 2020 net_route_del: 185.183.106.2/32 via 192.168.1.1 dev enp62s0u1u2 table 0 metric 0
Sun Jun  7 00:59:19.244 2020 Sun Jun  7 00:59:21.240 2020 EVENT: RECONNECTING
Sun Jun  7 00:59:21.241 2020 Successfully restored DNS settings
Sun Jun  7 00:59:21.295 2020 Network filter successfully restored
Sun Jun  7 00:59:21.295 2020 ERROR: N_RECONNECT
Sun Jun  7 00:59:21.296 2020 EVENT: RESOLVE
Sun Jun  7 00:59:21.296 2020 Network filter and lock is using iptables-legacy
Sun Jun  7 00:59:21.313 2020 Successfully loaded kernel module iptable_filter
Sun Jun  7 00:59:21.334 2020 Successfully loaded kernel module iptable_nat
Sun Jun  7 00:59:21.340 2020 Successfully loaded kernel module iptable_mangle
Sun Jun  7 00:59:21.345 2020 Successfully loaded kernel module iptable_security
Sun Jun  7 00:59:21.351 2020 Successfully loaded kernel module iptable_raw
Sun Jun  7 00:59:21.356 2020 Successfully loaded kernel module ip6table_filter
Sun Jun  7 00:59:21.372 2020 Successfully loaded kernel module ip6table_nat
Sun Jun  7 00:59:21.378 2020 Successfully loaded kernel module ip6table_mangle
Sun Jun  7 00:59:21.383 2020 Successfully loaded kernel module ip6table_security
Sun Jun  7 00:59:21.389 2020 Successfully loaded kernel module ip6table_raw
Sun Jun  7 00:59:21.392 2020 Network filter successfully initialized
Sun Jun  7 00:59:21.392 2020 Local IPv4 address 192.168.1.7
Sun Jun  7 00:59:21.392 2020 Local interface enp62s0u1u2
Sun Jun  7 00:59:21.392 2020 Local interface wlp2s0
Sun Jun  7 00:59:21.392 2020 Setting up network filter and lock
Sun Jun  7 00:59:21.392 2020 Allowing system DNS 127.0.0.1 to pass through the network filter
Sun Jun  7 00:59:21.392 2020 Adding IPv4 server 185.183.106.2 to network filter
Sun Jun  7 00:59:21.411 2020 Network filter and lock successfully activated
Sun Jun  7 00:59:21.411 2020 Contacting 185.183.106.2:443 via UDP
Sun Jun  7 00:59:21.411 2020 EVENT: WAIT
Sun Jun  7 00:59:21.411 2020 net_route_del: 185.183.106.2/32 via 192.168.1.1 dev enp62s0u1u2 table 0 metric 0
Sun Jun  7 00:59:21.411 2020 sitnl_send: rtnl: generic error: No such process (-3)
Sun Jun  7 00:59:21.411 2020 net_route_best_gw query IPv4: 185.183.106.2/32
Sun Jun  7 00:59:21.411 2020 sitnl_route_best_gw result: via 192.168.1.1 dev enp62s0u1u2
Sun Jun  7 00:59:21.411 2020 net_route_add: 185.183.106.2/32 via 192.168.1.1 dev enp62s0u1u2 table 0 metric 0
Sun Jun  7 00:59:21.411 2020 Error while executing NetlinkRoute4(add: 0) enp62s0u1u2: -3
Sun Jun  7 00:59:21.411 2020 Connecting to [185.183.106.2]:443 (185.183.106.2) via UDPv4
Sun Jun  7 00:59:21.426 2020 EVENT: CONNECTING
Sun Jun  7 00:59:21.426 2020 Tunnel Options:V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client
Sun Jun  7 00:59:21.426 2020 Peer Info:
...