However, you may need some open connectivity to the Internet in order to establish the OpenVPN connection to your service provider, such as domain name services. Is your connection to your service provider by domain name, or by IP address?

Quote:

Originally Posted by ucharfli

@jggimi;
No domain services. I'm a normal internet user.

I think @ucharfli that you doesn't understand the question. Your VPN service provider sent you some information about how to connect to VPN. One of the information is address - either IP address or domain name. Which one?

__________________
Signature: Furthermore, I consider that systemd must be destroyed.
Based on Latin oratorical phrase

Every "normal" Internet user is a user of the Domain Name System ("DNS"). Including you. When you tell your browser to reach out to daemonforum.org, your browser requests this website's IP address from a DNS server. The browser MUST do this, in order to connect to this website.

I'll restate my question, because your OpenVPN client may need to translate a domain name into an IP address in order to connect and establish a connection to the VPN.

When you provisioned your VPN service, did you use an IP address the VPN service provider gave you, or did you use a domain name they have given you?

I ask because the translation of a domain name into an IP address requires the use of a domain server, and the domain protocol.

I'll ask a second question, related to configuring the IP address on your wireless network connection.

Do you use DHCP to provision your wireless NIC's IP address?

If you don't know the answer, look in your /etc/hostname.ral0 file. I ask because if you use DHCP, then this protocol must also be permitted through your wireless interface. (And you have a typo in your pf.conf file you posted here. There is no such device as "ra0." I assume this must be "ral0" instead.)

If you use DHCP, then your system uses the DHCP protocol at boot time to configure:

an IP address

an IP netmask, required for routing

a default route, required for routing

the address of one or more DNS nameservers, to resolve domain names to IP addresses

These are my notes. They are not complete. I refer to the books to get other information.. If you use them and screw up, its your funeral.

I have not tested torrenting with these rules, as I couldn't be bothered after the trouble I went to get this far. I only set it up to work on my desktop machine, so I don't know if it will work in a router type situation.

These notes will only give you clues to help you though roadblocks if you read the books I mentioned, as well as related man files. If you don't read up on this, you will have no clue what it all means. I don't have a clue either and I read everything there was to read. lol

If you get tired of trying take my advice in the post above. Install an operating system a VPN makes a GUI client for that does all this for you and get on with your life. If your VPN does not make such a client, cut your losses with them and find one that does.

Even them writing 3 little files you need to use OpenBSD safely can't be that hard for them can it? If they won't do that much for you. they obviously don't need your business.

The first link is where I got the main fragment. My pf file has a version of it pasted at the bottom of the original one. Or perhaps it should be at the top? You better read The Book of PF or you will not know.l

"Various Internet bodies have set aside three subnets for use on private
networks. You cannot use them on the public Internet, but anybody can use
them on a private network. The networks 10.0.0.0/8, 172.16.0.0/12, and
192.168.0.0/16 are freely usable by organizations. You’ll see these
addresses in huge organizations and home networks, and have probably
encountered some of them already. These addresses are also globally
unique, within your organization. Your hosts should never see these
addresses elsewhere, and other networks should never see these addresses
on your network." - From Networking for Systems Administrators, by Michael Lucas

"The following very basic rules would block all traffic outside the tunnel
(edit with any text editor /etc/pf.conf) assuming that your ethernet or wifi
interface has the address 192.168.*.* and that the tun interface used by
OpenVPN is tun0:"

block out on <your_network_interface> from 192.168.0.0/16 to any
pass out quick on <your_network_interface> from 192.168.0.0/16 to <AirVPN_server_entry_IP>
pass out quick on tun0 from any to any

Note the IP address in OpenVPN is slightly different to the one reported in the webpage that tests leaks. You want the one OpenVPN reports obviously.
# The OpenVPN IP for each server is marked by: [AF_INET]

For my machine:
block out on em0 from 192.168.0.0/16 to any
pass out quick on em0 from 192.168.0.0/16 to <insert 1st vpn server IP here>
pass out quick on em0 from 192.168.0.0/16 to <insert 2nd vpn server IP here>
pass out quick on em0 from 192.168.0.0/16 to <insert 3rd vpn server IP here>
pass out quick on em0 from 192.168.0.0/16 to <insert 4th vpn server IP here>
pass out quick on tun0 from any to any

Then execute

pfctl -e
pfctl -f /etc/pf.conf

to enable pf and load your ruleset.

If the connection drops, no packets will go out, so you will only be able to
reconnect to the VPN and nothing else until you disable pf with

As currently configured, I see two types of communication that are required outside of your VPN, as they are needed to connect to the VPN. If you block all traffic other than over VPN, you must (at this time) still permit the direct passing of these communications:

DHCP. This protocol uses UDP ports 67 and 68 to assign the client -- your system -- with an IP address, and to provision netmask, routing, and domain name services. As your workstation is configured to use DHCP, you must permit this traffic to obtain a network connection.

Domain Name Resolution. This translates domain names to IP addresses, via UDP port 53. Large responses (greater than 512 bytes) use TCP, so TCP port 53 should also be permitted. This is needed in order to resolve all of the domain names in your OpenVPN configuration into IP addresses.

The VPN "tunnel" connections must also be permitted to flow. As configured, these are TCP connections to a variety of servers, using the destination port 443. This is the same port number used for by the HTTPS protocol, and your service provider may have selected it because most firewalls will not hinder this traffic.

A PF configuration can be established with a default block of all traffic, then permitting this select traffic to be passed. There are some considerations:

Domain traffic (UDP and TCP port 53) can be allowed to be passed to any destination, or, passed only to specific domain name servers. This latter choice will prohibit the use of untrusted domain name servers, as well as making it difficult to use port 53 for other purposes.

Your VPN traffic cannot be easily discerned from HTTPS traffic, since they share the same destination port number and the same underlying protocol, TCP. There are ways to classify them so that PF can choose to pass or block correctly. The options available vary depending on whether the OpenVPN client is being run on a workstation or on a gateway router.

PF is a kernel function, and does not do domain name resolution. The pfctl(8) management tool will resolve domain names when it loads the rules. This will complicate the boot process, since PF rules are first loaded before access to a resolver has been established.

Quote:

I can change domain names to IP. No problem.!

That would simplify PF rules at boot, though it may complicate your life if your service provider re-addresses their VPN servers.

@Prevet;
I applied what you wrote, but I do not get internet.
Am I making a mistake somewhere?
My pf.conf

Code:

block out on $wlan_if from 192.168.0.0/16 to any
pass out quick on $wlan_if from 192.168.0.0/16 to $vpn
pass out quick on tun0 from any to any

The value in $wlan_if you get with a program called ifconfig. Read the man page on ifconfig. For mine it is the entry titled em0, yours might be different. It has a section under it marked media: Ethernet ...

$vpn variable should be the full number of the IP address of what you are connecting to. You can get that when OpenVPN is up and running. Look for the entry marked [AF_INET] in the terminal screen that pops up when OpenVPN is running.

Don't try to use these PF rules until you have made OpenVPN connect to one of your VPN's servers, then you can get [AF_INET] from it.

If you search that page for "your_network_interface" you will see them discussing it.

Also this number could be different on your machine. I can't remember what program I used to report what it is on my machine.

Quote:

"Various Internet bodies have set aside three subnets for use on private
networks. You cannot use them on the public Internet, but anybody can use
them on a private network. The networks 10.0.0.0/8, 172.16.0.0/12, and
192.168.0.0/16 are freely usable by organizations. You’ll see these
addresses in huge organizations and home networks, and have probably
encountered some of them already. These addresses are also globally
unique, within your organization. Your hosts should never see these
addresses elsewhere, and other networks should never see these addresses
on your network." - From Networking for Systems Administrators, by Michael Lucas

Quote:

For my machine:
block out on em0 from 192.168.0.0/16 to any
pass out quick on em0 from 192.168.0.0/16 to <insert 1st vpn server IP here>
pass out quick on em0 from 192.168.0.0/16 to <insert 2nd vpn server IP here>
pass out quick on em0 from 192.168.0.0/16 to <insert 3rd vpn server IP here>
pass out quick on em0 from 192.168.0.0/16 to <insert 4th vpn server IP here>
pass out quick on tun0 from any to any

****

I just noticed you can find the number (192.168.0.0/16) for your machine, if you use ifconfig command. Look in the section that has the media: Ethernet that I mentioned in the post above. For me it is the last line that has netmask 0xffffff00 broadcast 192.168.... Netmasks are explained in the Michael Lucas book.