Using OpenVPN For All Network Traffic Except For LAN
Hi!
Recently I noticed that my Android smartphone was not able to connect to YouTube via third-party apps. I narrowed it down to the issue with it being able to resolve hostnames to the correct IPv6 addresses but not being able to connect to them (somehow the IPv6 part of my internet connection is broken. A problem for a different time).
In order to work around the problem I am using an OpenVPN connection which automatically forces all outgoing connections to use IPv4, not IPv6. The only problem was that internal LAN connections did not work any more.
In the .ovpn configuration file I am using
redirect-gateway local def1
(because it is a WiFi connection), but I was also using
redirect-gateway def1
before that, which did not make any difference in that regard.
If add a route directive like the following one after the redirect-gateway directive, you can add a route to the routing table, directing all traffic for the specified route to the WiFi connection instead of the VPN connection:
redirect-gateway local def1 route 192.168.0.0 255.255.255.0 net_gateway
You will probably have to adjust the network address and maybe even the subnet mask to match your network.
The routing table is basically a prioritized table which lets the operating system decide which network adapter it should use for a specific connection. With the above entry you add a rule with a higher priority, overriding the generic one(s) from the OpenVPN connection configuration. These ones are added because of redirect-gateway def1 and tell the operating system to send all traffic via the virtual VPN network adapter, effectively sending it all over the VPN.
If you are configuring this from the OpenVPN server side, of course you can still use these directives, but in the context of the push directive. I am not doing that, however, so I saved both directives in the client configuration.
Now I can watch / listen to YouTube videos with third-party apps AND connect to LAN devices!
I hope this was helpful to you.
Thank you for reading!
PhonerLite With FRITZ!Box
Hello!
If you want to set up your PhonerLite VoIP/SIP client with the FRITZ!Box so you can receive phone calls on your computer as well, of course you should have a look at the official AVM documentation (like the one for the FRITZ!Box 7390).
However, I encountered the following problems:
- outgoing calls would result in a "480 Temporarily Unavailable" error (even the test number **797)
- saving the configuration (tab "Configuration" => "Save" button) repeatedly would cause the status bar to alternate between
- showing a red indicator and the error message "sip:<number>@fritz.box not registered <Connectivity Checks Failed>" every second click
- showing a green indicator and the message "sip:<number>@fritz.box registered" every other click
I changed the following server / connection settings to fix the problem:
- Proxy/Registrar: <FRITZ!Box IP address instead of fritz.box, e.g. 192.168.1.1>
- Domain/Realm: fritz.box
After that, every time I saved the configuration if would show the success indicator and message and telephony just worked in general.
My local network interface uses an external DNS server for hostname resolution and I have added the fritz.box name manually in my hosts file. This might be why this was causing me problems.
I hope this was of any help to you in case you encountered this as well.
Thanks for reading!
Installing mod_cloudflare For Apache HTTPd 2.4 On Debian 8 (Jessie) Via Aptitude Repository
[Update on 2019-09-19] Warning: From Debian 9 (stretch) upwards, according to the official documentation Cloudflare has dropped support for mod_cloudflare. Instead they recommend replacing it with the new alternative: the official Apache HTTPd module mod_remoteip.
Hi!
If you are using the Cloudflare proxy functionality, you will find that your web server will end up only working with Cloudflare's IPs instead of the visitors'. After quite some time I thought that there has to be a better way to go about this, and I found mod_cloudflare, a solution officially developed by Cloudflare themselves.
When I was looking at the official Cloudflare documentation on how to install mod_cloudflare for Apache 2.4 on Debian 8 (Jessie) today, I was disappointed to find that they were only recommending manual ways: installing a .deb package or compiling the module yourself.
Luckily I found a guide on how to accomplish the installation with the standard apt-get / aptitude tool for Debian / Ubuntu.
This is how:
- Add the aptitude repository to a new sources list file, e.g. at /etc/apt/sources.list.d/cloudflare-main.list - with this content:
deb http://pkg.cloudflare.com/ jessie main
- Download the Cloudflare repository key and add it to the aptitude known keys:
# wget https://pkg.cloudflare.com/pubkey.gpg # apt-key add pubkey.gpg # rm pubkey.gpg
- Update the aptitude cache:
# aptitude update
- Look at which packages are available in the new repository:
# grep ^Package: /var/lib/apt/lists/pkg.cloudflare.com_dists_jessie_main_binary-amd64_Packages
- Install mod_cloudflare:
# aptitude install libapache2-mod-cloudflare
- Restart the Apache HTTPd service:
# service apache2 restart
Hopefully this way of installing will enable everyone to update / maintain it much more easily and with less one-time use packages installed.
Additionally, this could prove even more useful for people who want to install more Cloudflare packages.
I am confident that this method also works for Ubuntu and other versions of Debian - just replace the "jessie" part in the aptitude sources list file with your distribution major release codename (like "wheezy" for Debian 7 or "vivid" for Ubuntu 15.04).
Thanks for reading!
Original source: https://emtunc.org/blog/01/2016/installing-mod_cloudflare-ubuntu-14-04-apache-server/
Mozilla Thunderbird: Changing the EHLO / HELO Value in the “Received”-Header for Outgoing Mail
Hi!
If you have had a look at your outgoing e-mail headers that you've sent from Mozilla Thunderbird, you might have noticed that Thunderbird uses the IP of the network interface that it uses to connect to the internet with by default. If you are using a router on your network, this is a private IP from your LAN (for example 192.168.1.2) instead of one that might be of actual use.
Example:
Received: from external.sender.host.example.org ([123.123.123.123] helo=[192.168.1.2]) by mail.example2.org (incoming-mta-service) with esmtpsa (outgoing-mta-service) id 0a1b2c-3D4e5F6G7h-0a1B2c for <[email protected]>; Sun, 02 Nov 2014 20:55:41 +0100
where "123.123.123.123" is the publicly facing IP and "external.sender.host.example.org" is its hostname.
If you do not wish to expose this information to every and all recipients of the e-mails you are sending with Thunderbird to (maybe out of security concerns in a business environment), you can set the EHLO / HELO value manually for every outgoing e-mail sent by the Thunderbird client with your current user profile and even for every simple SMTP server individually.
Here's how:
Globally
- Open your Thunderbird options ("Tools" => "Options")
- "Advanced" => "Config Editor..."
- Create (or edit) the entry named "mail.smtpserver.default.hello_argument". If you need to create it, use right-click => "New" => "String".
- Change the value to the desired IP or hostname (FQDN).
Per SMTP server
- Open your Thunderbird options ("Tools" => "Options")
- "Advanced" => "Config Editor..."
- Create (or edit) the entry named "mail.smtpserver.smtp<number>.hello_argument" where <number> is the ID for the SMTP server you would like to apply the setting to. Type "mail.smtpserver.smtp" to see which ones are available and which ID they have. If you need to create the entry, use right-click => "New" => "String".
- Change the value to the desired IP or hostname (FQDN).
Technically this value is not relevant for sending/receiving the mail, but because it might be used for spam scoring or simply out of courtesy I would recommend entering a valid IP / hostname.
I myself am using 127.0.0.1.
Thanks for reading!
Sources: