Basic failure in ruleset

J

jasonhirsh

I'm trying to build a ruleset I though I had my handle on it but when I rebooted, I was locked out. Objective: Implementation of OpenVPN with PF/NAT to allow traffic to access a standalone FreeBSD 8.0 server and also to tunnel to the internet. The server has no intranet connections.

There must be something fundamentally wrong in this ruleset:

Code: 
tcp_pass = "{ 20 21 22 25 53 80 81 8010 110 137 138 139 443 445 465 587 993
udp_pass = "[ 137 138 139 465 587 1194}"
vpn_if   = "tun0"
vpn_net  = "10.8.0.0/24"
ext_if   = "re0"
ip_addr  = "209.160.65.133"
openvpn_server = "10.8.0.1"
openvpn_port   = "1194"

#basic rules
pass out on re0 proto tcp to any port $tcp_pass keep state
pass out on re0 proto udp to any port $udp_pass keep state
pass in on re0 proto udp to any port $udp_pass keep state
pass int on re0 proto tcp to any port $tcp_pass keep state

#nat rules
nat on $ext_if inet from $vpn_net to any -> $ext_if


# --- pass incoming openvpn connections to the internal openvpn server ---
pass in quick on $ext_if inet proto { tcp udp } from any to $OPENVPN_SERVER

pass out quick on $ext_if inet from any to any keep state

# --- SCRUB section ---
scrub in all

# --- antispoof protection ---
antispoof quick for $ext_if inet


#provide a wall
block all
 
Yes, something is fundamentally wrong. It fails to pass a parse test on my FreeBSD 9.1 box ;)

Code: 
[cmd=#] pfctl -vnf test-pf[/cmd]
test-pf:2: syntax error
vpn_net = "10.8.0.0/24"
ext_if = "re0"
ip_addr = "209.160.65.133"
openvpn_server = "10.8.0.1"
openvpn_port = "1194"
test-pf:11: macro 'tcp_pass' not defined
test-pf:11: syntax error
test-pf:12: macro 'udp_pass' not defined
test-pf:13: macro 'udp_pass' not defined
test-pf:14: macro 'tcp_pass' not defined
test-pf:21: macro 'OPENVPN_SERVER' not defined
test-pf:21: syntax error
test-pf:26: Rules must be in order: options, normalization, queueing, translation, filtering

Do yourself a favour and print out a copy of the pfctl(8) manual and study it how to load a ruleset manually. You really should not reboot a box to test a firewall rule set.

A cleaned up and more logical version:

Code: 
tcp_pass = "{ 20 21 22 25 53 80 81 8010 110 137 138 139 443 445 465 587 993}"
udp_pass = "{ 137 138 139 465 587 1194}"
vpn_if   = "tun0"
vpn_net  = "10.8.0.0/24"
ext_if   = "re0"
ip_addr  = "209.160.65.133"
OPENVPN_SERVER = "10.8.0.1"
openvpn_port   = "1194"

# --- SCRUB section ---
scrub in all

# --- NAT  rules -------------
nat on $ext_if inet from $vpn_net to any -> $ext_if


# ------------------ FILTER RULES -------------------
# --- OUTGOING
pass out quick on $ext_if inet proto tcp to any port $tcp_pass 
pass out quick on $ext_if inet proto udp to any port $udp_pass
pass out quick on $ext_if inet from any to any keep state

# --- INCOMING
pass in quick on $ext_if inet proto udp to any port $udp_pass 
pass in quick on $ext_if inet proto tcp to any port $tcp_pass

# --- pass incoming openvpn connections to the internal openvpn server ---
pass in quick on $ext_if inet proto { tcp udp } from any to $OPENVPN_SERVER

# --- antispoof protection ---
antispoof quick for $ext_if inet

# --- default policy
block log all

# --- end of pf rule set

A test parsing/load:

Code: 
[cmd=#]pfctl -vvnf test-pf[/cmd]
tcp_pass = "{ 20 21 22 25 53 80 81 8010 110 137 138 139 443 445 465 587 993}"
udp_pass = "{ 137 138 139 465 587 1194}"
vpn_if = "tun0"
vpn_net = "10.8.0.0/24"
ext_if = "re0"
ip_addr = "209.160.65.133"
OPENVPN_SERVER = "10.8.0.1"
openvpn_port = "1194"
warning: macro 'vpn_if' not used
warning: macro 'ip_addr' not used
warning: macro 'openvpn_port' not used
@0 scrub in all fragment reassemble
@1 nat on re0 inet from 10.8.0.0/24 to any -> xx.yy.195.234
@0 pass in quick on re0 inet proto tcp from any to any port = ftp-data flags S/SA keep state
@1 pass in quick on re0 inet proto tcp from any to any port = ftp flags S/SA keep state
@2 pass in quick on re0 inet proto tcp from any to any port = ssh flags S/SA keep state
@3 pass in quick on re0 inet proto tcp from any to any port = smtp flags S/SA keep state
@4 pass in quick on re0 inet proto tcp from any to any port = domain flags S/SA keep state
@5 pass in quick on re0 inet proto tcp from any to any port = http flags S/SA keep state
@6 pass in quick on re0 inet proto tcp from any to any port = hosts2-ns flags S/SA keep state
@7 pass in quick on re0 inet proto tcp from any to any port = 8010 flags S/SA keep state
@8 pass in quick on re0 inet proto tcp from any to any port = pop3 flags S/SA keep state
@9 pass in quick on re0 inet proto tcp from any to any port = netbios-ns flags S/SA keep state
@10 pass in quick on re0 inet proto tcp from any to any port = netbios-dgm flags S/SA keep state
@11 pass in quick on re0 inet proto tcp from any to any port = netbios-ssn flags S/SA keep state
@12 pass in quick on re0 inet proto tcp from any to any port = https flags S/SA keep state
@13 pass in quick on re0 inet proto tcp from any to any port = microsoft-ds flags S/SA keep state
@14 pass in quick on re0 inet proto tcp from any to any port = smtps flags S/SA keep state
@15 pass in quick on re0 inet proto tcp from any to any port = submission flags S/SA keep state
@16 pass in quick on re0 inet proto tcp from any to any port = imaps flags S/SA keep state
@17 pass in quick on re0 inet proto tcp from any to 10.8.0.1 flags S/SA keep state
@18 pass in quick on re0 inet proto udp from any to any port = netbios-ns keep state
@19 pass in quick on re0 inet proto udp from any to any port = netbios-dgm keep state
@20 pass in quick on re0 inet proto udp from any to any port = netbios-ssn keep state
@21 pass in quick on re0 inet proto udp from any to any port = smtps keep state
@22 pass in quick on re0 inet proto udp from any to any port = submission keep state
@23 pass in quick on re0 inet proto udp from any to any port = openvpn keep state
@24 pass in quick on re0 inet proto udp from any to 10.8.0.1 keep state
@25 pass out quick on re0 inet proto udp from any to any port = netbios-ns keep state
@26 pass out quick on re0 inet proto udp from any to any port = netbios-dgm keep state
@27 pass out quick on re0 inet proto udp from any to any port = netbios-ssn keep state
@28 pass out quick on re0 inet proto udp from any to any port = smtps keep state
@29 pass out quick on re0 inet proto udp from any to any port = submission keep state
@30 pass out quick on re0 inet proto udp from any to any port = openvpn keep state
@31 pass out quick on re0 inet all flags S/SA keep state
@32 block drop in quick on ! re0 inet from xx.yy.195.224/27 to any
@33 block drop in quick inet from xx.yy.195.234 to any
@34 block drop log all
 
I would not use rules that expand to so many rules with the port macros but individual rules for each port but that's my preference. The rules for the OpenVPN server are wrong. First you need a rule that passes udp traffic to port 1194 of the server. Then a rule that allows traffic on tun0 interface.

Code: 
pass in quick on $ext_if inet proto udp from any to ($ext_if) port openvpn
pass quick on tun0 all
 
I used the port macros to try to avoid typos from my fat fingers. I had actually read the manual, but I guess I really didn't appreciate/missed the meaning of parse. Does it really test the ruleset without loading them? The server is remote so I had figured one way of loading them was as good or bad as another.
 
OK. I got KVM access to my server as I am still trying to build a local test bed. I can not get connectivity with PF running. Here are my files:


rc.conf
Code: 
defaultrouter="209.160.64.1"
hostname="tuna.theoceanwindow-bv.com"
ifconfig_re0="inet 209.160.65.133  netmask 0xfffff800"
ifconfig_re0_alias0="inet 209.160.68.112 netmask 0xffffffff"
linux_enable="YES"
#firewall_enable="YES"
#firewall_script="/etc/ipfw.rules"
#firewall_logging="YES"
pf_enable="YES"
pf_rules="/etc/pf.conf"           # Packet filter rules file
pf_flags=""
pflog_enable="YES"
pflog_logfile="/var/log/pflog"
pflog_flags=""
sshd_enable="YES"
webmin_enable="YES"
mysql_enable="YES"
apache22_enable="YES"
named_enable="YES"
gateway_enable="YES"
openvpn_if="tun"
openvpn_enable="YES"
openvpn_configfile="/usr/local/etc/openvpn/server.conf"
clamsmtpd_enable="YES"
clamav_clamd_enable="YES"
clamav_freshclam_enable="YES"
clamav_milter_enable="YES"
dovecot_enable="YES"
ntpd_enable="YES"
inetd_enable="YES"
amavisd_enable="YES"
natd_enable="YES"
natd_interface="re0"
winbindd_enable="YES"
#postgrey_enable="YES"
#postgrey_pidfile="/var/run/postgrey.pid"
#postgrey_flags="--pidfile=${postgrey_pidfile} --inet=127.0.0.1:6000 -d --
samba_enable="YES"
proftpd_enable="YES"
#ftpd_enable="YES"
squid_enable="YES"
sshd_enable="YES"


pf.conf which passed parse
Code: 
pass in log all keep state
pass out log all keep state

kldstat | grep pf shows both pflog.ko and pf.ko loaded. pfctl -d says that it is disabling PF (also states that ALTQ support is not in kernel). Restart the firewall with pfctl -e, same ALT Q disclaimer but still no traffic. Ok, I am even more confused then when I started, I guess.
 
You absolutely need NAT for the VPN subnet. Add the nat rule and try again. You could also remove some redundant and possibly wrong settings from rc.conf:

Code: 
pf_rules="/etc/pf.conf"    
pf_flags=""
pflog_logfile="/var/log/pflog"
pflog_flags=""
openvpn_if="tun"
 
But doesn't the NAT deal with only the VPN? I get no traffic into the server, it doesn't respond to ping with the pf firewall up. This is even true if I eliminate the pf firewall from the rc.conf. It is like ipfw was providing some sort of basic routing.
 
I did try the NAT rule in a simple ruleset (nol errors on parse)

pf.conf

Code: 
ext_if   = "re0"
ip_addr  = "209.160.65.133"
OPENVPN_SERVER = "10.8.0.1"
openvpn_port   = "1194"
vpn_net  = "10.8.0.0/24"

# --- NAT  rules -------------
nat on $ext_if inet from $vpn_net to any -> $ext_if



## FILTER RULES
pass in log all keep state
pass out log all keep state
 
Quote from the pf website: The last rule to match is the "winner".

Code: 
#basic rules
pass out on re0 proto tcp to any port $tcp_pass keep state
pass out on re0 proto udp to any port $udp_pass keep state
pass in on re0 proto udp to any port $udp_pass keep state
pass int on re0 proto tcp to any port $tcp_pass keep state

#provide a wall
block all

So all of your basic rules will be block by the last rule.
 
The last rule set I am using but doesn't work either it is:

Code: 
ext_if   = "re0"
ip_addr  = "209.160.65.133"
OPENVPN_SERVER = "10.8.0.1"
openvpn_port   = "1194"
vpn_net  = "10.8.0.0/24"

# --- NAT  rules -------------
nat on $ext_if inet from $vpn_net to any -> $ext_if



## FILTER RULES
pass in log all keep state
pass out log all keep state
 
I have a hard time following of what is working and what is not. Please state clearly what you mean by "server" when you say "I get no traffic into the server". No traffic over the VPN to the VPN address or no traffic at all to the server system that runs the VPN server?
 
I'm little bit confused too what is the VPN server and what is the firewall. If the VPN server is not the box you're doing filtering, you need to redirect the port. Using your example of the rules:

Code: 
ext_if   = "re0"
ip_addr  = "209.160.65.133"
OPENVPN_SERVER = "10.8.0.1"
openvpn_port   = "1194"

# --- NAT  rules -------------
rdr on $ext_if proto tcp to $ip_addr port $openvpn_port -> $OPENVPN_SERVER

## FILTER RULES
pass in log all keep state
pass out log all keep state

I'm assuming ip_addr is on ext_if, OPENVPN_SERVER is somewhere on local network reachable by the server doing filtering.

Anything else is not needed right now, as you are passing all in/out.
 
OK I have a leased freeBSD FreeBSD server. It is standalone with a single ethernet connection. I am trying to use it as an OpenVPN server with the specified 10.8.0.1.

Here is the various appropriate information:

Code: 
ext_if   = "re0"
ip_addr  = "209.160.65.133"
OPENVPN_SERVER = "10.8.0.1"
openvpn_port   = "1194"
vpn_net  = "10.8.0.0/24"

Wit the the ipfw firewall I can ssh to the server but there is no further connectivity to the internet (tunnel).

When I try to go with the pf firewall any of the above rule sets I can not contact the server in any manner.

I hope this is a bit clearer.
 
So OPENVPN_SERVER IP is also on ext_if?

Code: 
# --- NAT  rules -------------
nat on $ext_if from $vpn_net to any -> $ip_addr
rdr on $ext_if proto tcp to $ip_addr port $openvpn_port -> $OPENVPN_SERVER

First rule NAT from your VPN network to your public IP. Second one redirects RQs to your public IP/ VPN port to proper destination.
Again, assuming other rules are pass in/out.
 
Just enabling pf(4) should never cut you out if you have a pass all ruleset enabled. Do you still have ipfw(4) loaded at the same time? That could explain some of the weirdness. Never load them at the same time unless you know how to use them together, it's a very advanced concept.

@@matoatlantis, the OpenVPN server is running on the host that also does the filtering, no need for rdr to anywhere.
 
Last edited by a moderator:
  1. The OpenVPN server program is running on the FreeBSD box.
  2. During the testing I have ensured that I have booted either with ipfw or pf, not both being loaded under rc.conf
  3. As far as being on the re0 here is the results of ifconfig

    Code: 
    re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
	ether 00:13:8f:e5:e4:15
	inet 209.160.65.133 netmask 0xfffff800 broadcast 209.160.71.255
	inet 209.160.68.112 netmask 0xffffffff broadcast 209.160.68.112
	media: Ethernet autoselect (10baseT/UTP <full-duplex>)
	status: active
rl0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=8<VLAN_MTU>
	ether 00:18:e7:08:27:dd
	media: Ethernet autoselect
	status: no carrier
ipfw0: flags=8801<UP,SIMPLEX,MULTICAST> metric 0 mtu 65536
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
	options=3<RXCSUM,TXCSUM>
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 
	inet6 ::1 prefixlen 128 
	inet 127.0.0.1 netmask 0xff000000 
	nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
	options=80000<LINKSTATE>
	inet 10.8.0.1 --> 10.8.0.2 netmask 0xffffffff

The last failed version of pf.conf has a pass rule:

pf.conf
Code: 
ext_if   = "re0"
ip_addr  = "209.160.65.133"
OPENVPN_SERVER = "10.8.0.1"
openvpn_port   = "1194"
vpn_net  = "10.8.0.0/24"

# --- NAT  rules -------------
nat on $ext_if inet from $vpn_net to any -> $ext_if



## FILTER RULES
pass in log all keep state
pass out log all keep state

I kept 'pass' at the end under the "last rule applicable" wins.

As a side project I am trying to clone the server onto Virtualbox to enable local testing.
 
Your OPENVPN_SERVER is not an IP of the VPN server but rather a tunnel IP. Your OpenVPN IP is your public IP. What IP does your OpenVPN bind to?

If I assume the following:

209.160.65.133 is IP where your OpenVPN listens to
10.8.0.0/24 is your subnet you push to your clients

pf.conf:

Code: 
ext_if="re0"
ip_addr="209.160.65.133"
openvpn_port="1194"
vpn_net="10.8.0.0/24"

nat on $ext_if from $vpn_net to any -> $ip_addr

# you can check VPN traffic this way
# later you can use this pass rule (when you'll have block in)
pass quick in proto {tcp,udp} from any to $ip_addr port $openvpn_port

pass in log all
pass out log all
@@kpa Right. The topology was not clear enough for me from the info we have here.
 
Last edited by a moderator:
I am sorry for my inability to clearly describe the topology. Let me summarize.

Box 1
  • Stand alone server
  • Freebsd FreeBSD 8.0
  • Public/external IP 209.160.65.133
  • No intranet
  • Hosting OpenVPN server
  • Currently using ipfw
(I'm trying to "clone" this box in VirtualBox so I can debug my pf firewall issues. This effort is going a little slow.)

ifconfig
Code: 
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
	ether 00:13:8f:e5:e4:15
	inet 209.160.65.133 netmask 0xfffff800 broadcast 209.160.71.255
	inet 209.160.68.112 netmask 0xffffffff broadcast 209.160.68.112
	media: Ethernet autoselect (10baseT/UTP <full-duplex>)
	status: active
rl0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=8<VLAN_MTU>
	ether 00:18:e7:08:27:dd
	media: Ethernet autoselect
	status: no carrier
ipfw0: flags=8801<UP,SIMPLEX,MULTICAST> metric 0 mtu 65536
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
	options=3<RXCSUM,TXCSUM>
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 
	inet6 ::1 prefixlen 128 
	inet 127.0.0.1 netmask 0xff000000 
	nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
tun0: flags=8010<POINTOPOINT,MULTICAST> metric 0 mtu 1500
	options=80000<LINKSTATE>

Box 2
  • Mac OS x 10.6.8
  • Local network IP 10.0.1.150
  • Public IP 174.57.220.98
  • Running OpenVPN client

ifconfig
Code: 
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
	inet6 ::1 prefixlen 128 
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
	inet 127.0.0.1 netmask 0xff000000 
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
	ether e8:06:88:cb:d1:04 
	inet6 fe80::ea06:88ff:fecb:d104%en0 prefixlen 64 scopeid 0x4 
	inet 10.0.1.100 netmask 0xffffff00 broadcast 10.0.1.255
	media: autoselect (100baseTX <full-duplex,flow-control>)
	status: active
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether e8:06:88:cb:bc:05 
	media: autoselect (<unknown type>)
	status: inactive
en2: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether 00:26:08:fd:8d:2b 
	inet6 fe80::226:8ff:fefd:8d2b%en2 prefixlen 64 scopeid 0x6 
	inet 10.0.1.109 netmask 0xffffff00 broadcast 10.0.1.255
	media: autoselect
	status: active
fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 4078
	lladdr 78:ca:39:ff:fe:10:f3:78 
	media: autoselect <full-duplex>
	status: inactive
vnic0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
	ether 00:1c:42:00:00:08 
	inet 10.211.55.2 netmask 0xffffff00 broadcast 10.211.55.255
	media: autoselect
	status: active
vnic1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether 00:1c:42:00:00:09 
	inet 10.37.129.2 netmask 0xffffff00 broadcast 10.37.129.255
	media: autoselect
	status: active

Objective is to allow Box 2 to connect to Box 1 over OpenVPN (working) and also to tunnel all Internet traffic through Box 1 (not working).

I had thought that the OpenVPN server was do a bind with use of the local IP in the server.conf. I gather I am wrong?

Code: 
local 209.160.65.133
port 1194
proto udp
bind
dev tun
push "redirect-gateway def1"
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/server.crt
key /usr/local/etc/openvpn/keys/server.key
dh /usr/local/etc/openvpn/keys/dh1024.pem
server  10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
tls-auth /usr/local/etc/openvpn/keys/ta.key 0 # This file is secret
cipher BF-CBC        # Blowfish (default)
comp-lzo
#ping 10
#max-clients 10
user nobody
group nobody
persist-key
persist-tun
status /var/log/openvpn.log
verb 9
mute 10
 
Last time I used OpenVPN it was when it was at version 2.0 or something. I am planning to configure VPN on one of my servers, though I incline to use mpd instead.

I pulled a backup of my configuration I used. I'll show the network part only:

openvpn.conf:
Code: 
dev tun  # tunneling

server 192.168.253.0 255.255.255.0        # my vpn subnet .. yours is 10.x/24
push "route 192.168.253.0 255.255.255.0"  # push this route to the clients

push "redirect-gateway"                   # all client's traffic will go through me
push "dhcp-option DNS $MY_PUBLIC_DNS_ON_THE_SERVER # my VPN server's DNS
local keyword does what you said. I had mine in rc.conf though:

Code: 
openvpn_flags="--local $MY_PUBLIC_IP"

On a Windows XP client (again showing only relevant part):

client.ovpn:
Code: 
client
dev tun
dev-node OpenVPN      # virtual adapter name
proto udp

remote server.fqdn.local 1194

PF was set as I mentioned already. I too have a multihomed server and I wanted to NAT only through a specified IP.
 
At the current time I am focusing on using a virtual FreeBSD server to try to resolve the firewall issues first. I think I am close on the OpenVPN configuration. I don't think mine is that dissimilar to yours. I can achieve access across the VPN but lack access from there further to the internet. It would seem that I need a NAT to make the internet connectivity work. I am centering my efforts on pf based on the input I have received here.
 
I've configured OpenVPN on my server (9.1-RELEASE), tested it on Windows 7 client. On server I have installed openvpn-2.3.1, Windows client version is 1.5.6.

OpenVPN configuration files are pretty much the same as ones I've already shared. It was not mentioned in this thread yet, but be sure to have IP forwarding on:

# sysctl net.inet.ip.forwarding
Code: 
net.inet.ip.forwarding: 1

This can be done manually, or in two configuration files (you can choose where to set it): /etc/sysctl.conf or /etc/rc.conf .

Relevant sections of my pf.conf :

Code: 
ext_if="em0"

IP_PUBLIC="192.0.2.1"   # my public IP
NET_OVPN="{192.168.254.0/24}"
PORT_OVPN="{1194}"

# OpenVPN
nat pass on $ext_if from $NET_OVPN to any -> $IP_PUBLIC

# OpenVPN
pass in quick proto {tcp,udp} to $IP_PUBLIC port $PORT_OVPN
pass in quick from $NET_OVPN to any   # I do have block in

On my virtual adapters I usually use set skip on keywords, meaning I trust the traffic there completely. During boot firewall settings are read sooner than OpenVPN starts, tun0 does not exist at the time of applying firewall configuration. That's why I had to specify the last line in the pf.conf example above.
 
Yes IP forwarding is on.

The pf.conf was beating me silly until I reread your last comment about tun0. I was still being blocked when I enabled/disabled pf from the command. Rebooted and let things follow their normal course and it works on my test bed

I was able to trace by issues on my production server on my first attempt at pf to still have ip_divert in the loader.conf.

OK, I guess the test is now to reconfigure the production server and see what happens there.
 
I don't have much time to concentrate on your issue now but there's one bit that I haven't mentioned about testing OpenVPN. It is that you should always have the client system on the "outside" network, never on the inside in same network with the OpenVPN server when testing connectivity trough the VPN tunnel. The reason is that the routes pushed by the server might conflict with the client machine's routing table effectively hiding the local network from the client machine.
 
I appreciate all of your help and suggestions. I have managed to hose the configuration and I am pretty much back at ground zero. Again thanks for taking the time.
 
You must log in or register to reply here.
Back
Top