Re: OpenVPN problem.
Hi Simen. Then 10.0.8.1 and 10.0.8.2 are allocate by openvpn server and in the client are 10.0.8.6 and 10.0.8.5 they appear in ifconfing of tun0 on client and server side in this form: 10.0.8.1 - 10.0.8.2 10.0.8.6 - 10.0.8.5 My purpose is to study VPN with openvpn and i've not a remote place to get this setup and then I've reproduced a little reality. Simen Stavdal wrote: Ciao Alessandro, So, from the server, the client gets allocated 10.0.8.5/32 (btw, probably a minor thing, but in your server conf file, you have a mismatch on the host/mask when you push the routes- it reads push route 10.1.1.1 255.255.0.0 while it should read 10.1.0.0) (doesn't seem to bother the client too much, but it might be worth a try to correct it). Also, on the server side routing table, you have the following : 192.168.7/24 10.0.8.2 UGS0 175 - 8 tun0 Where is 10.0.8.2? This is from the pool of client addresses, but does not exist anywhere? You also have som route statements in your server conf file, like this one : route 192.168.7.0 255.255.255.0 It doesn't have a gateway, and is not locally connected This tells the client host to route 192.168.7.0 to nowhere (even though it is locally connected on the client side). On my config, the client side routing table looks like this (windows host) : 10.10.177.0255.255.255.0 10.10.177.5 10.10.177.6 1 10.10.177.4 255.255.255.252 10.10.177.6 10.10.177.6 30 Also, the two hosts are not connected with public addresses, can I ask why you want to use NAT between to RFC1918 networks that don't overlap? I am trying to understand your objective and the purpose of the setup, maybe there is a different way of setting it up? Cheers, Simon. Alessandro Baggi wrote: Simen Stavdal wrote: and... do you have the routing table for some of the hosts that can/cannot ping each other? Are there other gateways out of the networks, other than the openvpn box? S. I'm trying openvpn in my internal network: internet | primary node 192.168.1.1 / \ OBSD OBSD 2 192.168.1.33 192.168.1.2 10.1.0.0/16 192.168.7.0/24 | | . .
OpenVPN problem.
Hi list! I'm setting up a vpn between two openbsd firewall: This is the scenario: FW1 FW2 $ext 192.168.1.33 $ext 192.168.1.2 $int 10.1.1.1 $int 192.168.7.1 $host 10.1.3.53 $host2 192.168.7.2 then I've made the certificate, client can contact the server, and from the client I can ping a Linux Machine behind the server, and from linux machine to client. Then I've tried to get communication with LAN clients behind the VPN client gw. Then, 192.168.7.2 of FW2's VPN can comunicate with 10.1.3.53, but not viceversa. All routing table are ok (I think). server configuration file: proto udp port 1194 dev tun0 ca /etc/openvpn/ca.crt cert /etc/openvpn/192.168.1.33.crt key /etc/openvpn/private/192.168.1.33.key dh /etc/openvpn/dh1024.pem server 10.0.8.0 255.255.255.0 keepalive 10 50 comp-lzo user _openvpn group _openvpn daemon openvpn persist-key persist-tun client-config-dir ccd push route 10.1.1.1 255.255.0.0 route 192.168.7.0 255.255.255.0 status /var/log/openvpn-status.log log /tmp/openvpn.log verb 2 /etc/openvpn/ccd/192.168.1.2: iroute 192.168.7.0 255.255.255.0 Client conf: client remote 192.168.1.33 1194 proto udp dev tun0 daemon openvpn keepalive 10 50 nobind persist-key persist-tun ca /etc/openvpn/ca.crt cert /etc/openvpn/192.168.1.2.crt key /etc/openvpn/private/192.168.1.2.key comp-lzo log /tmp/openvpn.log verb 2 It is a routing problem? This is the server routing table: default192.168.1.1UGS2 2995 - 8 vr0 10.0.8/24 10.0.8.2 UGS0 301 - 8 tun0 10.0.8.2 10.0.8.1 UH 30 - 4 tun0 10.1/16link#1 UC 20 - 4 rl0 10.1.3.53 00:1d:60:ec:a5:14 UHLc 2 3480 - 4 rl0 loopback localhost UGRS 00 33200 8 lo0 localhost localhostUH 10 33200 4 lo0 192.168.1/24 link#3 UC 20 - 4 vr0 192.168.1.100:13:49:cb:fa:75 UHLc 10 - 4 vr0 192.168.1.200:1d:0f:c4:0c:1d UHLc 1 1482 - 4 vr0 192.168.7/24 10.0.8.2 UGS0 516 - 8 tun0 ifconfig tun0 on server: tun0: flags=8151UP,POINTOPOINT,RUNNING,PROMISC,MULTICAST mtu 1500 priority: 0 groups: tun media: Ethernet autoselect status: active inet 10.0.8.1 -- 10.0.8.2 netmask 0x can someone tell me a point? Thanks in advanced.
Re: OpenVPN problem.
On Mon, Jan 25, 2010 at 5:45 AM, Alessandro Baggi alessandro.ba...@gmail.com wrote: Hi list! I'm setting up a vpn between two openbsd firewall: This is the scenario: FW1 FW2 $ext 192.168.1.33 $ext 192.168.1.2 $int 10.1.1.1 $int 192.168.7.1 $host 10.1.3.53 $host2 192.168.7.2 then I've made the certificate, client can contact the server, and from the client I can ping a Linux Machine behind the server, and from linux machine to client. Then I've tried to get communication with LAN clients behind the VPN client gw. Then, 192.168.7.2 of FW2's VPN can comunicate with 10.1.3.53, but not viceversa. Are you permitting traffic from $host through the firewall? What's your pf.conf? Have you verified that your firewalls pass other traffic normally?
Re: OpenVPN problem.
On Mon, Jan 25, 2010 at 10:05 AM, Alessandro Baggi alessandro.ba...@gmail.com wrote: Johan Beisser wrote: Hi Johan. Thanks for the answer. I've reduced my pf.conf on client and server side to: ext=rl0 int=rl1 nat on $ext from $int:network - $ext:0 nat on tun0 from $int:network - tun0:0 pass all What version of OpenBSD are you running? I can ping from client LAN of the vpn client the entire Server side lan, but not viceversa. Are you certain your packets are being natted properly?
Re: OpenVPN problem.
Johan Beisser wrote: On Mon, Jan 25, 2010 at 5:45 AM, Alessandro Baggi alessandro.ba...@gmail.com wrote: Hi list! I'm setting up a vpn between two openbsd firewall: This is the scenario: FW1 FW2 $ext 192.168.1.33 $ext 192.168.1.2 $int 10.1.1.1 $int 192.168.7.1 $host 10.1.3.53 $host2 192.168.7.2 then I've made the certificate, client can contact the server, and from the client I can ping a Linux Machine behind the server, and from linux machine to client. Then I've tried to get communication with LAN clients behind the VPN client gw. Then, 192.168.7.2 of FW2's VPN can comunicate with 10.1.3.53, but not viceversa. Are you permitting traffic from $host through the firewall? What's your pf.conf? Have you verified that your firewalls pass other traffic normally? Hi Johan. Thanks for the answer. I've reduced my pf.conf on client and server side to: ext=rl0 int=rl1 nat on $ext from $int:network - $ext:0 nat on tun0 from $int:network - tun0:0 pass all I can ping from client LAN of the vpn client the entire Server side lan, but not viceversa.
Re: OpenVPN problem.
Johan Beisser wrote: On Mon, Jan 25, 2010 at 10:05 AM, Alessandro Baggi alessandro.ba...@gmail.com wrote: Johan Beisser wrote: Hi Johan. Thanks for the answer. I've reduced my pf.conf on client and server side to: ext=rl0 int=rl1 nat on $ext from $int:network - $ext:0 nat on tun0 from $int:network - tun0:0 pass all What version of OpenBSD are you running? I can ping from client LAN of the vpn client the entire Server side lan, but not viceversa. Are you certain your packets are being natted properly? On server side 4.5 updated to 4.6 and client side 4.6. Packet from server side network are natted, with tcpdump on tun0, I get 10.0.8.1 - 192.168.7.2 but I don't receive an answer. I can ping client side (10.0.8.6) from server (10.0.8.1) I can ping and ssh to client server side (10.1.0.0/16) from 192.168.7.0/24
Re: OpenVPN problem.
and... do you have the routing table for some of the hosts that can/cannot ping each other? Are there other gateways out of the networks, other than the openvpn box? S. Alessandro Baggi wrote: Johan Beisser wrote: On Mon, Jan 25, 2010 at 10:05 AM, Alessandro Baggi alessandro.ba...@gmail.com wrote: Johan Beisser wrote: Hi Johan. Thanks for the answer. I've reduced my pf.conf on client and server side to: ext=rl0 int=rl1 nat on $ext from $int:network - $ext:0 nat on tun0 from $int:network - tun0:0 pass all What version of OpenBSD are you running? I can ping from client LAN of the vpn client the entire Server side lan, but not viceversa. Are you certain your packets are being natted properly? On server side 4.5 updated to 4.6 and client side 4.6. Packet from server side network are natted, with tcpdump on tun0, I get 10.0.8.1 - 192.168.7.2 but I don't receive an answer. I can ping client side (10.0.8.6) from server (10.0.8.1) I can ping and ssh to client server side (10.1.0.0/16) from 192.168.7.0/24
Re: OpenVPN problem.
Simen Stavdal wrote: and... do you have the routing table for some of the hosts that can/cannot ping each other? Are there other gateways out of the networks, other than the openvpn box? S. I'm trying openvpn in my internal network: internet | primary node 192.168.1.1 / \ OBSD OBSD 2 192.168.1.33 192.168.1.2 10.1.0.0/16 192.168.7.0/24 | | . .
Re: OpenVPN problem.
Simen Stavdal wrote: Hello Alessandro, Can you see any of the traffic on the inside LAN on the client side with tcpdump? I.e set tcpdump on $int with tcpdump -i nameofinternalinterface proto icmp and then try to ping from a server? Silly suggestion, but What about client side firewalls? Do they allow to be pinged? What is your server.conf file for openvpn and the client conf file? Simon. Alessandro Baggi wrote: Johan Beisser wrote: On Mon, Jan 25, 2010 at 5:45 AM, Alessandro Baggi alessandro.ba...@gmail.com wrote: Hi list! I'm setting up a vpn between two openbsd firewall: This is the scenario: FW1 FW2 $ext 192.168.1.33 $ext 192.168.1.2 $int 10.1.1.1 $int 192.168.7.1 $host 10.1.3.53 $host2 192.168.7.2 then I've made the certificate, client can contact the server, and from the client I can ping a Linux Machine behind the server, and from linux machine to client. Then I've tried to get communication with LAN clients behind the VPN client gw. Then, 192.168.7.2 of FW2's VPN can comunicate with 10.1.3.53, but not viceversa. Are you permitting traffic from $host through the firewall? What's your pf.conf? Have you verified that your firewalls pass other traffic normally? Hi Johan. Thanks for the answer. I've reduced my pf.conf on client and server side to: ext=rl0 int=rl1 nat on $ext from $int:network - $ext:0 nat on tun0 from $int:network - tun0:0 pass all I can ping from client LAN of the vpn client the entire Server side lan, but not viceversa. Hi simon. I've already tried this. I've putted tcpdump also on openvpn client on tun0 interface, and on rl0 (interlan interface) and on (tun0) of server openvpn side. When I try to ping from lan client side I get from openvpn client tcpdump on tun0: 10.0.8.6 - 10.1.3.53 10.1.3.53 - 10.0.8.6 on internal interface nothing and on tun0 of openvpn server the previous result. When I ping from this network (10.1.0.0/16) to 192.168.7.0/24 I get result from tcpdump only on server openvpn, with natted address: 10.0.8.1 - 192.168.7.2: icmp: echo request 10.0.8.1 - 192.168.7.2: icmp: echo request 10.0.8.1 - 192.168.7.2: icmp: echo request and so on... Those are my configuration file: server.conf: -- proto udp port 1194 dev tun0 ca /etc/openvpn/ca.crt cert /etc/openvpn/192.168.1.33.crt key /etc/openvpn/private/192.168.1.33.key dh /etc/openvpn/dh1024.pem server 10.0.8.0 255.255.255.0 keepalive 10 120 comp-lzo user _openvpn group _openvpn daemon openvpn persist-key persist-tun client-config-dir ccd push route 10.1.1.1 255.255.0.0 route 192.168.7.0 255.255.255.0 status /var/openvpn/openvpn-status.log log-append /var/openvpn/openvpn.log verb 8 ccd/client: - iroute 192.168.7.0 255.255.255.0 client.conf: -- client dev tun0 proto udp remote 192.168.1.33 1194 nobind user _openvpn group _openvpn persist-key persist-tun ca /etc/openvpn/ca.crt cert /etc/openvpn/client.crt key /etc/openvpn/private/client.key comp-lzo verb 8 mute 20 log-append /var/openvpn/openvpn.log This is the routing table of the openvpn server: default192.168.1.1UGS2 145394 - 8 vr0 10.0.8/24 10.0.8.2 UGS0 206 - 8 tun0 10.0.8.2 10.0.8.1 UH 30 - 4 tun0 10.1/16link#1 UC 30 - 4 rl0 10.1/1610.0.8.2 UGS00 - 8 tun0 10.1.3.53 00:1d:60:ec:a5:14 UHLc 210834 - 4 rl0 192.168.7/24 10.0.8.2 UGS0 175 - 8 tun0 loopback localhost UGRS 00 33200 8 lo0 localhost localhost UH 10 33200 4 lo0 192.168.1/24 link#3 UC 20 - 4 vr0 192.168.1.100:13:49:cb:fa:75 UHLc 10 - 4 vr0 192.168.1.200:19:66:65:53:1c UHLc 1 1158 - 4 vr0 BASE-ADDRESS.MCAST localhost URS00 33200 8 lo0 This is the routing table of the openvpn client: default192.168.1.1UGS1 141 - 8 re0 10.0.8.1/3210.0.8.5 UGS00 - 8 tun0 10.0.8.5 10.0.8.6 UH 20 - 4 tun0 10.1/1610.0.8.5 UGS1 105 - 8 tun0 192.168.7/24 link#2 UC 10 - 4 rl0 192.168.7.2 00:1f:c6:7e:35:75 UHLc 02 - 4 rl0 loopback localhost UGRS 00 33200 8 lo0 localhost localhost UH 10 33200 4 lo0 192.168.1/24 link#1 UC 20 - 4 re0 192.168.1.1
Re: OpenVPN problem.
Hello Alessandro, Can you see any of the traffic on the inside LAN on the client side with tcpdump? I.e set tcpdump on $int with tcpdump -i nameofinternalinterface proto icmp and then try to ping from a server? Silly suggestion, but What about client side firewalls? Do they allow to be pinged? What is your server.conf file for openvpn and the client conf file? Simon. Alessandro Baggi wrote: Johan Beisser wrote: On Mon, Jan 25, 2010 at 5:45 AM, Alessandro Baggi alessandro.ba...@gmail.com wrote: Hi list! I'm setting up a vpn between two openbsd firewall: This is the scenario: FW1 FW2 $ext 192.168.1.33 $ext 192.168.1.2 $int 10.1.1.1 $int 192.168.7.1 $host 10.1.3.53 $host2 192.168.7.2 then I've made the certificate, client can contact the server, and from the client I can ping a Linux Machine behind the server, and from linux machine to client. Then I've tried to get communication with LAN clients behind the VPN client gw. Then, 192.168.7.2 of FW2's VPN can comunicate with 10.1.3.53, but not viceversa. Are you permitting traffic from $host through the firewall? What's your pf.conf? Have you verified that your firewalls pass other traffic normally? Hi Johan. Thanks for the answer. I've reduced my pf.conf on client and server side to: ext=rl0 int=rl1 nat on $ext from $int:network - $ext:0 nat on tun0 from $int:network - tun0:0 pass all I can ping from client LAN of the vpn client the entire Server side lan, but not viceversa.
Re: OpenVPN problem.
Ciao Alessandro, So, from the server, the client gets allocated 10.0.8.5/32 (btw, probably a minor thing, but in your server conf file, you have a mismatch on the host/mask when you push the routes- it reads push route 10.1.1.1 255.255.0.0 while it should read 10.1.0.0) (doesn't seem to bother the client too much, but it might be worth a try to correct it). Also, on the server side routing table, you have the following : 192.168.7/24 10.0.8.2 UGS0 175 - 8 tun0 Where is 10.0.8.2? This is from the pool of client addresses, but does not exist anywhere? You also have som route statements in your server conf file, like this one : route 192.168.7.0 255.255.255.0 It doesn't have a gateway, and is not locally connected This tells the client host to route 192.168.7.0 to nowhere (even though it is locally connected on the client side). On my config, the client side routing table looks like this (windows host) : 10.10.177.0255.255.255.0 10.10.177.5 10.10.177.6 1 10.10.177.4 255.255.255.252 10.10.177.6 10.10.177.6 30 Also, the two hosts are not connected with public addresses, can I ask why you want to use NAT between to RFC1918 networks that don't overlap? I am trying to understand your objective and the purpose of the setup, maybe there is a different way of setting it up? Cheers, Simon. Alessandro Baggi wrote: Simen Stavdal wrote: and... do you have the routing table for some of the hosts that can/cannot ping each other? Are there other gateways out of the networks, other than the openvpn box? S. I'm trying openvpn in my internal network: internet | primary node 192.168.1.1 / \ OBSD OBSD 2 192.168.1.33 192.168.1.2 10.1.0.0/16 192.168.7.0/24 | | . .
Re: Non critical but weird pf and openvpn problem
Hi list again, Sorry for delayed replie, I was away :) My problem was solved by adding: pass quick on tun0 to my /etc/pf.conf Thanks Mark Rolen
Re: Non critical but weird pf and openvpn problem
Update. With help from the mailing list, both of my problems have
been solved. The first problem was the same as the original
poster. To reiterate, the problems were:
1. On startup, pf would not allow any packets through on tun0.
Thus openvpn would not work. The temporary fix was to ssh in and
run pfctl -f /etc/pf.conf
2. After running pfctl -f /etc/pf.conf, openvpn would only work
if pass in on $int_if from 10.8.0.0/24 to any was in the pf.conf
file.
The solution was twofold. First, remove the two lines from my
pf.conf file (listed at the bottom):
set skip on { lo, tun0 }
pass in on $int_if from 10.8.0.0/24
The second part of the solution was to add after block in:
pass quick on { lo, tun0 }
This fixed both problems. I hope this works for the original
poster as well. I guess set skip doesn't work for tun0.
On Fri, 20 Jul 2007 09:12:20 -0700 [EMAIL PROTECTED] wrote:
Here are my pf rules:
ext_if=fxp0
int_if=ath0
set skip on { lo, tun0 }
set block-policy return
scrub in
nat-anchor ftp-proxy/*
rdr-anchor ftp-proxy/*
nat on $ext_if from !($ext_if) - ($ext_if:0)
rdr pass on $int_if proto tcp to port ftp - 127.0.0.1 port 8021
anchor ftp-proxy/*
block in
antispoof quick for { lo, $int_if, tun0 }
pass in on $int_if proto tcp from 10.1.1.2 to 10.1.1.1 port ssh
pass in proto icmp
pass in on $int_if from 10.8.0.0/24 to any
pass in on $int_if proto udp from 10.1.1.2 to 10.1.1.1 port 1194
pass out
Re: Non critical but weird pf and openvpn problem
I do have an /etc/hostname.tun0 file that I created manually with touch. What is the theory of openvpn being the problem source? Obviously openvpn started up correctly or I would have to do more to fix the problem than merely running pfctl -f /etc/pf.conf. :-) Thanks for the pfctl -sr suggestion. Though I use this often, but I never thought to run this before doing pfctl -f /etc/pf.conf after booting up, duh. :-) On Thu, 19 Jul 2007 16:47:58 -0700 Tim Kuhlman [EMAIL PROTECTED] wrote: On Thu July 19 2007 5:12:58 pm Bill wrote: On Thu, 19 Jul 2007 15:06:55 -0700 [EMAIL PROTECTED] spake: I have the same problem. I was going to post a this question too along with another question. When I first boot up my OpenBSD 4.1 sever. I can not access my OpenVPN wireless connection. I can access ssh wirelessly though. So what I do is login via ssh and run pfctl -f /etc/pf.conf. Now my OpenVPN connection works just fine. I too have my startup script in /etc/rc.local but it is much simpler: /usr/local/sbin/openvpn /var/openvpn/server.conf I am curious to know why pf requires a command line start for it to work. I have a few OpenVPN installations running and do not have this problem with any of them. I start my PF normally through the rc.conf.local Same here I have few installations which are very reliable and problem free. Do you have a hostname.tun0 file in /etc? I forget if OpenVPN will create the tun0, but it could be why PF needs to be run after in your instance. I have simply: UP my hostname.tun0 is set to inet 0.0.0.0 0.0.0.0 NONE Either way probably works fine. Have you checked out your log files? Openvpn does a good job logging in my experience. If the logs are empty I would try turning up the verbosity or running openvpn by hand before doing a reload of the pf rules. It would also be interesting to run pfctl -sr before reloading to see if they even loaded properly. -- Tim Kuhlman Network Administrator ColoradoVnet.com
Re: Non critical but weird pf and openvpn problem
* jean-philippe luiggi [EMAIL PROTECTED] [2007-07-20 03:04]: I'm perhaps wrong but i think the interface must exists before loading any rules which use it. yes, you are almost wrong. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: Non critical but weird pf and openvpn problem
Mark Rolen [EMAIL PROTECTED] wrote:
I had the same symptom, where I'd have to manually reload my pf
rules
after a reboot to get OpenVPN traffic to flow. Using tcpdump
showed
that pf was blocking all the traffic on my tun interfaces although
I had
a set skip rule for them.
Here are my pf rules:
ext_if=fxp0
int_if=ath0
set skip on { lo, tun0 }
set block-policy return
scrub in
nat-anchor ftp-proxy/*
rdr-anchor ftp-proxy/*
nat on $ext_if from !($ext_if) - ($ext_if:0)
rdr pass on $int_if proto tcp to port ftp - 127.0.0.1 port 8021
anchor ftp-proxy/*
block in
antispoof quick for { lo, $int_if, tun0 }
pass in on $int_if proto tcp from 10.1.1.2 to 10.1.1.1 port ssh
pass in proto icmp
pass in on $int_if from 10.8.0.0/24 to any
pass in on $int_if proto udp from 10.1.1.2 to 10.1.1.1 port 1194
pass out
Note, this problem is occurring even though I too have set skip on
{ lo, tun0 }. I stated before that I had another question I would
post. Since you brought this up, I'll post it. About a two or
three months ago, I posted a question about how come my openvpn
wireless connection was not working with the above pf rules with
one exception. I did not have the this line in there:
pass in on $int_if from 10.8.0.0/24 to any
I still had to run pfctl -f /etc/pf.conf after bootup. Even after
running pfctl -f /etc/pf.conf, it would not work. By adding this
line it worked just fine. So now I'm confused. I thought the way
this worked was that when I connect to openvpn, pf allows it on
port 1194 which it then sends to tun0. Since tun0 is not blocked
from the set skip on { lo, tun0 } it should pass through tun0.
By adding the line above, proves that this is not so. So is there
a bug, especially with the tun device, or am I not understanding
something? If I'm not understanding something, please enlighten me
(it will be appreciated).
Anyhow, I don't have the issue any longer because I just added
this rule:
pass quick on { tun0 tun1 }
That seems to be effective regardless of whether or not the
interfaces
exist when pf loads, so my OpenVPN tunnels work after reboots
without
intervention.
Does this point to a problem with set skip on { lo, tun0 }? I
will try your suggestion to see if it works (pass quick on { tun0
tun1 }), but I dislike using quick in my rules.
I added up to my /etc/hostname.tun0 to see if that worked based
on one of the suggestions but the startup problem still exist? I
have since removed up since in the past I have never needed to
use it and I read somewhere that touch /etc/hostname.tun0 was all
that I needed.
Re: Non critical but weird pf and openvpn problem
[EMAIL PROTECTED] wrote:
Does this point to a problem with set skip on { lo, tun0 }? I
will try your suggestion to see if it works (pass quick on { tun0
tun1 }), but I dislike using quick in my rules.
I added up to my /etc/hostname.tun0 to see if that worked based
on one of the suggestions but the startup problem still exist? I
have since removed up since in the past I have never needed to
use it and I read somewhere that touch /etc/hostname.tun0 was all
that I needed.
Your experience matches mine. Having up in /etc/hostname.tun0 wasn't
enough, openvpn traffic was still blocked on the tun interface. Using
the pass quick on tun0 rule somewhere at the top of your rules should
work for you, let me know if not.
For completeness, here's my pf.conf as well so you can compare. ..
ext_if=fxp2
int_if=fxp1
wifi_if=fxp0
voip=192.168.10.2
high_pri_tcp=22, 6667
med_pri_tcp=21, 25, 80, 110, 443, 995, 1723
high_pri_udp=53
med_pri_udp=123
table scanners persist
set skip on lo
set loginterface $ext_if
set ruleset-optimization basic
set block-policy return
scrub in
altq on $ext_if cbq bandwidth 495Kb queue { q_low, q_med, q_high, q_max }
queue q_low bandwidth 63% priority 0 cbq(default)
queue q_med bandwidth 15% priority 2 cbq(borrow)
queue q_high bandwidth 15% priority 4 cbq(borrow)
queue q_max bandwidth 7% priority 6 cbq(borrow)
nat-anchor ftp-proxy/*
nat on $ext_if from !($ext_if) - ($ext_if:0)
rdr-anchor ftp-proxy/*
rdr on $int_if proto tcp to port ftp - 127.0.0.1 port 8021
anchor ftp-proxy/*
antispoof quick for { lo $int_if $wifi_if }
block drop quick from scanners
block in log
pass out
pass quick on { tun0 tun1 }
pass quick on $int_if from $voip to any no state tag PHONE
pass quick on $int_if inet proto udp from any port 27960 no state tag Q3
pass quick on $int_if no state
pass in quick on $wifi_if inet proto tcp to ($wifi_if) port ssh
pass in quick on $wifi_if inet proto udp from any port bootpc to any
port bootps
pass in quick on $wifi_if inet proto udp to ($wifi_if) port 1194
pass in quick on $wifi_if inet proto icmp to ($wifi_if)
## only used when an open AP needed, e.g. guests over
##pass in quick on $wifi_if
block in on $wifi_if
block in quick on $ext_if inet6 all
pass in on $ext_if inet proto icmp
pass in on $ext_if inet proto tcp to ($ext_if) port ssh flags S/SA \
keep state (source-track rule, max-src-conn-rate 5/60, overload \
scanners flush global) queue q_high
pass out on $ext_if inet to any queue (q_low,q_med)
pass out quick on $ext_if inet to any tagged PHONE queue q_max
pass out quick on $ext_if inet to any tagged Q3 queue q_high
pass out quick on $ext_if inet proto tcp to any port { $high_pri_tcp }
queue q_high
pass out quick on $ext_if inet proto tcp to any port { $med_pri_tcp }
queue (q_med,q_high)
pass out quick on $ext_if inet proto udp to any port { $high_pri_udp }
queue q_high
pass out quick on $ext_if inet proto udp to any port { $med_pri_udp }
queue q_med
pass out quick on $ext_if inet proto icmp queue q_high
HTH,
Mark
Re: Non critical but weird pf and openvpn problem
On Fri, 20 Jul 2007 09:46:41 -0700 Mark Rolen [EMAIL PROTECTED]
wrote:
Using
the pass quick on tun0 rule somewhere at the top of your rules
should
work for you, let me know if not.
I made the following two changes to my pf.conf and this fixed the
problem.
#set skip on { lo, tun0 }
pass quick on { lo, tun0 }
Does this mean that set skip on { lo, tun0 } doesn't work for the
tun interface? Should I report it as a bug in sendbug or is it
just some misunderstanding on my part?
Non critical but weird pf and openvpn problem
Hi list,
I'm having weird problem with my openvpn install and pf.
I start vpn and connect to it from client computers with no problems,
but I can't access any computers on internal lan. Then I issue pfctl -f
/etc/pf.conf and everything starts to work. So my rc.local script is:
---
if [ X${openvpn} == XYES -a -x /usr/local/sbin/openvpn ];
then echo -n ' openvpn';
/usr/local/sbin/openvpn --cd /etc/openvpn --config server.conf
sleep 10
/sbin/pfctl -f /etc/pf.conf
fi
---
And everything works fine. But why do I need to reload my pf?
My server.conf is:
---
daemon openvpn
local xxx.xxx.xxx.xxx
port 1194
proto udp
dev tun0
tun-mtu 1500
mssfix
keepalive 10 120
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
tls-auth ta.key 0
cipher AES-256-CBC
server 192.168.5.0 255.255.255.0
push route 192.168.0.0 255.255.255.0
route 192.168.6.0 255.255.255.0
chroot /etc/openvpn
status /var/log/openvpn-status.log
log/var/log/openvpn-log.log
writepid /var/run/openvpn.pid
ifconfig-pool-persist ipp.txt
replay-persist replay.txt
client-config-dir ccd
max-clients 5
user nobody
group nobody
persist-key
persist-tun
comp-lzo
verb 3
mute 10
---
My hostname.tun0 is:
---
up
---
My pf.conf is:
---
ext_if=vr0
int_if=vr1
admins1=xxx.xxx.xxx.xxx
admins2=xxx.xxx.xxx.xxx
organization_net=192.168.0.0/24
ovpn_net=192.168.6/24
ovpn=1194
table admins { $admins1, $admins2 } const persist
table rfc1918 { 10/8, 172.16/12, 192.168/16 } const persist
table bad_hosts persist
set block-policy drop
set optimization normal
set ruleset-optimization basic
set state-policy if-bound
set loginterface $ext_if
set skip on { lo0, $int_if, tun0 }
scrub on $ext_if no-df fragment reassemble random-id
nat-anchor ftp-proxy/*
nat on $ext_if from $organization_net to any - ($ext_if:0)
rdr pass on $int_if inet proto tcp to port ftp - 127.0.0.1 port 8021
rdr-anchor ftp-proxy/*
block log all
block in log quick on $ext_if from any to 255.255.255.255
antispoof log quick for { lo0, $ext_if, $int_if }
anchor ftp-proxy/*
pass log on $ext_if inet proto icmp icmp-type unreach code needfrag
pass in log quick on $ext_if inet proto icmp from admins to ($ext_if)
icmp-type echoreq modulate state label icmp for admins
pass in log quick on $ext_if inet proto tcp from admins to ($ext_if)
port ssh modulate state label ssh for admins
pass out on $ext_if inet proto { tcp, udp, icmp } from ($ext_if) to any
modulate state
pass in log on $ext_if inet proto udp from any to ($ext_if) port $ovpn
modulate state (max-src-conn-rate 30/10, overload bad_hosts flush global)
---
I'm using OpenBSD 4.1 and OpenVPN openvpn-2.0.6p0.
Non critical but weird pf and openvpn problem
I have the same problem. I was going to post a this question too along with another question. When I first boot up my OpenBSD 4.1 sever. I can not access my OpenVPN wireless connection. I can access ssh wirelessly though. So what I do is login via ssh and run pfctl -f /etc/pf.conf. Now my OpenVPN connection works just fine. I too have my startup script in /etc/rc.local but it is much simpler: /usr/local/sbin/openvpn /var/openvpn/server.conf I am curious to know why pf requires a command line start for it to work.
Re: Non critical but weird pf and openvpn problem
On Thu, 19 Jul 2007 15:06:55 -0700 [EMAIL PROTECTED] spake: I have the same problem. I was going to post a this question too along with another question. When I first boot up my OpenBSD 4.1 sever. I can not access my OpenVPN wireless connection. I can access ssh wirelessly though. So what I do is login via ssh and run pfctl -f /etc/pf.conf. Now my OpenVPN connection works just fine. I too have my startup script in /etc/rc.local but it is much simpler: /usr/local/sbin/openvpn /var/openvpn/server.conf I am curious to know why pf requires a command line start for it to work. I have a few OpenVPN installations running and do not have this problem with any of them. I start my PF normally through the rc.conf.local pf= pf_rules=/etc/brock.conf My OpenVPN starts in rc.local echo -n ' openvpn'; /usr/local/sbin/openvpn --cd /etc/openvpn --config server.conf --daemo It all just works(TM). Do you have a hostname.tun0 file in /etc? I forget if OpenVPN will create the tun0, but it could be why PF needs to be run after in your instance. I have simply: UP in this file.
Re: Non critical but weird pf and openvpn problem
On Thu July 19 2007 5:12:58 pm Bill wrote: On Thu, 19 Jul 2007 15:06:55 -0700 [EMAIL PROTECTED] spake: I have the same problem. I was going to post a this question too along with another question. When I first boot up my OpenBSD 4.1 sever. I can not access my OpenVPN wireless connection. I can access ssh wirelessly though. So what I do is login via ssh and run pfctl -f /etc/pf.conf. Now my OpenVPN connection works just fine. I too have my startup script in /etc/rc.local but it is much simpler: /usr/local/sbin/openvpn /var/openvpn/server.conf I am curious to know why pf requires a command line start for it to work. I have a few OpenVPN installations running and do not have this problem with any of them. I start my PF normally through the rc.conf.local Same here I have few installations which are very reliable and problem free. Do you have a hostname.tun0 file in /etc? I forget if OpenVPN will create the tun0, but it could be why PF needs to be run after in your instance. I have simply: UP my hostname.tun0 is set to inet 0.0.0.0 0.0.0.0 NONE Either way probably works fine. Have you checked out your log files? Openvpn does a good job logging in my experience. If the logs are empty I would try turning up the verbosity or running openvpn by hand before doing a reload of the pf rules. It would also be interesting to run pfctl -sr before reloading to see if they even loaded properly. -- Tim Kuhlman Network Administrator ColoradoVnet.com
Re: Non critical but weird pf and openvpn problem
I had the same symptom, where I'd have to manually reload my pf rules
after a reboot to get OpenVPN traffic to flow. Using tcpdump showed
that pf was blocking all the traffic on my tun interfaces although I had
a set skip rule for them.
I may not be completely right here, but I believe pf gets loaded before
openvpn, so openvpn will not have created the interface yet. I ran into
this problem here because I was trying to do set skip on { tun0 tun1 }
so pf would ignore my vpn interfaces. However, they weren't yet created
so the skip rule had no effect and pf would block all traffic on them
until I reloaded the ruleset. I also had /etc/hostname.{tun0,tun1}
files, both simply containing the up keyword.
Anyhow, I don't have the issue any longer because I just added this rule:
pass quick on { tun0 tun1 }
That seems to be effective regardless of whether or not the interfaces
exist when pf loads, so my OpenVPN tunnels work after reboots without
intervention.
Regards,
Mark
Bill wrote:
On Thu, 19 Jul 2007 15:06:55 -0700
[EMAIL PROTECTED] spake:
I have the same problem. I was going to post a this question too
along with another question.
When I first boot up my OpenBSD 4.1 sever. I can not access my
OpenVPN wireless connection. I can access ssh wirelessly though.
So what I do is login via ssh and run pfctl -f /etc/pf.conf. Now
my OpenVPN connection works just fine. I too have my startup
script in /etc/rc.local but it is much simpler:
/usr/local/sbin/openvpn /var/openvpn/server.conf
I am curious to know why pf requires a command line start for it to
work.
I have a few OpenVPN installations running and do not have this problem
with any of them. I start my PF normally through the rc.conf.local
pf=
pf_rules=/etc/brock.conf
My OpenVPN starts in rc.local
echo -n ' openvpn'; /usr/local/sbin/openvpn --cd /etc/openvpn --config
server.conf --daemo
It all just works(TM).
Do you have a hostname.tun0 file in /etc?
I forget if OpenVPN will create the tun0, but it could be why PF needs
to be run after in your instance. I have simply:
UP
in this file.
Re: Non critical but weird pf and openvpn problem
Hello,
I'm perhaps wrong but i think the interface must exists before loading
any rules which use it.
Best regards,
Jean-philippe.
On Thu, 19 Jul 2007 10:47:31 +0300
Tomas [EMAIL PROTECTED] wrote:
Hi list,
I'm having weird problem with my openvpn install and pf.
I start vpn and connect to it from client computers with no problems,
but I can't access any computers on internal lan. Then I issue pfctl
-f /etc/pf.conf and everything starts to work. So my rc.local script
is: ---
if [ X${openvpn} == XYES -a -x /usr/local/sbin/openvpn ];
then echo -n ' openvpn';
/usr/local/sbin/openvpn --cd /etc/openvpn --config server.conf
sleep 10
/sbin/pfctl -f /etc/pf.conf
fi
---
And everything works fine. But why do I need to reload my pf?
My server.conf is:
---
daemon openvpn
local xxx.xxx.xxx.xxx
port 1194
proto udp
dev tun0
tun-mtu 1500
mssfix
keepalive 10 120
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
tls-auth ta.key 0
cipher AES-256-CBC
server 192.168.5.0 255.255.255.0
push route 192.168.0.0 255.255.255.0
route 192.168.6.0 255.255.255.0
chroot /etc/openvpn
status /var/log/openvpn-status.log
log/var/log/openvpn-log.log
writepid /var/run/openvpn.pid
ifconfig-pool-persist ipp.txt
replay-persist replay.txt
client-config-dir ccd
max-clients 5
user nobody
group nobody
persist-key
persist-tun
comp-lzo
verb 3
mute 10
---
My hostname.tun0 is:
---
up
---
My pf.conf is:
---
ext_if=vr0
int_if=vr1
admins1=xxx.xxx.xxx.xxx
admins2=xxx.xxx.xxx.xxx
organization_net=192.168.0.0/24
ovpn_net=192.168.6/24
ovpn=1194
table admins { $admins1, $admins2 } const persist
table rfc1918 { 10/8, 172.16/12, 192.168/16 } const persist
table bad_hosts persist
set block-policy drop
set optimization normal
set ruleset-optimization basic
set state-policy if-bound
set loginterface $ext_if
set skip on { lo0, $int_if, tun0 }
scrub on $ext_if no-df fragment reassemble random-id
nat-anchor ftp-proxy/*
nat on $ext_if from $organization_net to any - ($ext_if:0)
rdr pass on $int_if inet proto tcp to port ftp - 127.0.0.1 port 8021
rdr-anchor ftp-proxy/*
block log all
block in log quick on $ext_if from any to 255.255.255.255
antispoof log quick for { lo0, $ext_if, $int_if }
anchor ftp-proxy/*
pass log on $ext_if inet proto icmp icmp-type unreach code needfrag
pass in log quick on $ext_if inet proto icmp from admins to
($ext_if) icmp-type echoreq modulate state label icmp for admins
pass in log quick on $ext_if inet proto tcp from admins to
($ext_if) port ssh modulate state label ssh for admins
pass out on $ext_if inet proto { tcp, udp, icmp } from ($ext_if) to
any modulate state
pass in log on $ext_if inet proto udp from any to ($ext_if) port
$ovpn modulate state (max-src-conn-rate 30/10, overload bad_hosts
flush global) ---
I'm using OpenBSD 4.1 and OpenVPN openvpn-2.0.6p0.
!DSPAM:1,469f22cc303651336712104!
