Problem with bridged openvpn 2.1.1 on freebsd 8.0-RELEASE-p2

zen_guerrilla

zen_guerrilla

Hello all,
I'm installing a gateway running freebsd 8.0-RELEASE-p2 (amd64), which will also act
as openvpn server (2.1.1 from ports) in bridged mode.
Everything works so far the first time the client connects. On the next connection
(or after the openvpn daemon is restarted) the client connects normally, but no traffic
passes through the vpn.

tcpdump on tap0 (during the second connection) - ping from an openvpn client:
Code: 
$ sudo tcpdump -env -ttt -i tap0 icmp
tcpdump: WARNING: tap0: no IPv4 address assigned
tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size 96 bytes
00:00:00.000000 6a:b9:be:7c:24:91 > 00:bd:90:26:00:00, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 60217, offset 0, flags [none], proto ICMP (1), length 84)
   192.168.100.220 > 192.168.100.254: ICMP echo request, id 10876, seq 0, length 64
00:00:00.000042 00:1b:21:5d:8e:fa > 92:c5:5c:7e:06:ee, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 12980, offset 0, flags [none], proto ICMP (1), length 84)
   192.168.100.254 > 192.168.100.220: ICMP echo reply, id 10876, seq 0, length 64
00:00:00.975944 6a:b9:be:7c:24:91 > 00:bd:90:26:00:00, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 49461, offset 0, flags [none], proto ICMP (1), length 84)
   192.168.100.220 > 192.168.100.254: ICMP echo request, id 10876, seq 1, length 64
00:00:00.000033 00:1b:21:5d:8e:fa > 92:c5:5c:7e:06:ee, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 12983, offset 0, flags [none], proto ICMP (1), length 84)
   192.168.100.254 > 192.168.100.220: ICMP echo reply, id 10876, seq 1, length 64

The same tcpdump on em0 & bridge0 returns nothing.

Here's my setup:

Code: 
$ make showconfig -C /usr/ports/security/openvpn
===> The following configuration options are available for openvpn-2.1.1:
     PW_SAVE=off "Interactive passwords may be read from a file"
     PKCS11=off "Use security/pkcs11-helper"
===> Use 'make config' to modify these settings

/etc/rc.conf
Code: 
ifconfig_em0="inet 192.168.100.254 netmask 255.255.255.0"
cloned_interfaces="bridge0 tap0"
ifconfig_tap0="up"
ifconfig_bridge0="addm em0 addm tap0 up"
openvpn_enable="YES"
openvpn_configfile="/usr/local/etc/openvpn/server.conf"

/usr/local/etc/openvpn/server.conf
Code: 
server-bridge 192.168.100.254 255.255.255.0 192.168.100.220 192.168.100.229
proto udp
port 1194
dev tap0
keepalive 10 120
status /var/openvpn/status
comp-lzo
max-clients 10
script-security 2
user _openvpn
group _openvpn
persist-key
persist-tun
duplicate-cn
verb 4
mute 20
client-to-client
tls-server
cd /usr/local/etc/openvpn
tls-auth keys/ta.key 0
ca keys/ca.crt
cert keys/XXX.crt
key keys/XXX.key
dh keys/dh1024.pem
chroot chroot
push "dhcp-option DNS 192.168.100.254"
push "dhcp-option DOMAIN XXX.YYY"

pf.conf
Code: 
pass quick on { lo, em0, tap0, bridge0 }

When the openvpn daemon is stopped, it changes tap0's state to DOWN, so
I manually set it to up with ifconfig before starting the openvpn daemon
again. Yet, it doesn't work.

The only solution to have traffic in vpn again, is to reboot the system;
at least this works every time, but of course it's not THE solution.

Any ideas? Thanks in advance.
 
I've found that, even though I have a skip rule on my OpenVPN device (in my case tun), restarting OpenVPN sometimes requires me to reload pf's ruleset ([cmd=]pfctl -f /etc/pf.conf[/cmd], nothing more complicated than that) to get traffic flowing again.
 
Thanks for replying. Reloading pf's rule set was the first thing I've tried, but unfortunately it doesn't
work. Pflog doesn't show anything weird either. I've also tried to kldunload & kldload the if_tap &
if_bridge modules, re-create tap0 & bridge0 and restart openvpn, but still the same. The only thing that
makes it operational again is a system reboot. I think the problem comes from the bridge, but I don't know
how to investigate further..
 
You might try [cmd=]/etc/rc.d/netif restart[/cmd] followed by [cmd=]/etc/rc.d/routing restart[/cmd] instead of rebooting.
 
This isn't a solution either. First of all, the system is *the* gateway and openvpn uses the bridge interface, so flushing the routes table won't do much. Plus it's a headless system (so only remote ssh
access) that runs lots of services, so restarting netif, now and then, is not an option. This system
will be on production this week, so having unreliable solutions is not an option.
I'm quite sure that the problem comes from the bridge -- not openvpn nor the tap interface; however time
is running out for my deadline, so I don't think I'll be able to get on with debugging etc.
I think I'll try openssh-based vpn or ipsec; unless there's another suggestion. Thanks for replying
anyway; I really appreciate it.
 
You must log in or register to reply here.
Back
Top