OpenVPN, bridged

[xor]

First, since it's my first post here - hello everyone

Now to the point.
(freebsd7.2, ipfw, openvpn server 2.0.6_9, client 2.0.9)
I've installed and configured openvpn, bridged. After struggle, i'm able to connect XP/Vista openvpn client. And that's all
No pings, no netbios communication
Firewall is not an issue - checked even with switched off on both sides, without any effect.

After checking packet flaw with tcpdump on tap devices, on both sides (freebsd server and windows xp client) i can see traffic from machines on ma bridged LAN /192.168.1.xxx/, so bridging on server works fine.
BUT ! Strange is, that on server tap0 I cant't see any packets originating from my vpn client /192.168.1.100/! Yet on client i can see packets from lan and server !

My config files :
loader.conf

ipfw_load="YES"
ipdivert_load="YES"
net.inet.ip.forwarding=1
snd_via8233_load="YES"
ext2fs_load="YES"
if_tap_load="YES"
if_bridge_load="YES"

rc.conf

firewall_enable="YES"
firewall_script="/usr/local/etc/ipfw.rules"
gateway_enable="YES"
dhcpd_enable="YES"
dhcpd_ifaces="vr0"

keymap="pl_PL.ISO8859-2"
linux_enable="YES"
sshd_enable="YES"
named="YES"
sendmail_enable="NONE"
#konfig. interfejsow
#inet
ifconfig_rl0="inet xx.xx.xx.xx  netmask xx.xx.xx.xx"
defaultrouter="xx.xx.xx.xx"
hostname="S0"
#lan
ifconfig_vr0="inet 192.168.1.1  netmask 255.255.255.0"

natd_enable="YES"
natd_interface="rl0"
natd_flags="-f /usr/local/etc/nat.conf"

nmbd_enable="YES"
smbd_enable="YES"

openvpn_enable="YES"
openvpn_configfile="/usr/local/etc/openvpn/openvpn.conf"
openvpn_if="tap bridge"

openvpn.conf

cd /usr/local/etc/openvpn
up /usr/local/etc/openvpn/up.sh
down /usr/local/etc/openvpn/down.sh
dev tap0
local xx.xx.xx.xx
port xyz
proto udp
keepalive 10 120
comp-lzo
daemon
client-to-client

verb 3
log-append /var/log/openvpn.log

#push "route-gateway 192.168.1.1"
push "dhcp-option DNS 192.168.1.1"
push "dhcp-option WINS 192.168.1.1"


#mode server
#dhcp on lan assigns up to 192.168.1.14
server-bridge 192.168.1.1 255.255.255.0 192.168.1.100 192.168.1.105
tls-server
tls-auth ta.key 0
dh	dh2048.pem
ca	ca.crt
cert	server.crt
key	server.key

up.sh

#!/bin/sh
ifconfig bridge0 create
ifconfig bridge0 addm vr0 addm $dev up

down.sh

#!/bin/sh
ifconfig bridge0 deletem $dev
ifconfig bridge0 destroy

on firewall just at the beginning i pass :
allow all from any to any via vr0
allow all from any to any via bridge0
allow all from any to any via tap0
On vpn port (xyz ) i skip before nat to check-state, then i pass in setup tcp and all udp with keep-state.
Like i said, client connects fine on vpn port, so i think firewall is ok.

and on windows client
client.ovpn

client
dev tap
dev-node vpn
proto udp
remote xx.xx.xx.xx xyz
resolv-retry infinite
nobind
ca ca.crt
cert client.crt
key client.key
tls-auth ta.key 1
comp-lzo
verb 6

 

[pbd]

I guess the client does not have a proper route. Can you post openvpn log from the client and "netstat -rn" from it, please?

 

[xor]

Thanks for answer.
Attached client log and route print output.

BTW. If i try from client to ping server lan ip, on client on tap interface i see packet "ARP, Request who-has ...", and if i try from server to ping client lan ip, on client tap i can see also ARP request from server lan, and ARP reply "is-at" from client, but the last one do not reach server...

Not obfuscated ip was my dynamic client ip.

 

[pbd]

I don't see any problem in client logs and routing doesn't seem to be problem either.

But did I understand well that if you try ping client from server you see outgoing arp requests on tap interface on server, the same arp request incoming on tap interface on client, subsequent arp answer outgoing on tap on client, but nothing incoming on server's tap?

And if you try to ping server from client, you see outgoing arp requests on tap on client, but nothing on tap on server?

If this is correct, can you check if you see incoming udp packets on server - outside the tunnel - on rl0 when you try to ping 192.168.1.100 from client? And if not, if you see outgoing udp packets on client, also "outside" tunnel?

 

[xor]

You did understand well. The situation looks exactly as you wrote.

I already have been checking udp packets on server incoming from client, and there come sometimes some, but i don't know how to identify whether these are the vpn internal pings to check connection, or my ping request encapsulated ?

 

[pbd]

Well if you keep ping on client going and see every second some udp from client on server's rl0, than I think you can say, that these are the arp requests from client.

In that case, there must be something blocking traffic on tap (rl0 should be fine, I guess, since the tunnel is established correctly). Try please to temporary disable firewall:

# /etc/rc.d/ipfw stop
# /etc/rc.d/pf stop

 

[xor]

I tried again to kill firewall and test - no effect /Tested if no firewalling was present like pinging from inet to server, and server responded, which is normaly blocked/

I tried to tcpdump on client on both tap and internet connection, and simultanously on server internet connection (rl0).
There are plenty of udp packets from client on server rl0.

1) there are matching /via time stamp/ outgoing packets on client internet_interface and tap interface, so client tap is sent correctly to the world encapsulated in udp

2) these udp packets are arraving to server's internet interface rl0

3) these packets do not show on servers tap0, even with no firewall present on server side

4) yet packets form tap0 server interface are set through rl0 to client, which recives them on it's tap interface

So i belive problem lies on server side, somewhere between 2) and 3).
I'll analize logs tomorrow more closely.

But I'm starting to lose patience grrr...

 

[pbd]

I have found this thread. It is not the same problem as yours, but it brings idea to destroy the bridge and see if something changes.

 

[xor]

I belive bridge is not the problem, since in my case packets travel looks like this :

     c_tap <-> c_openvpn <-> c_wan <---
..
..
(vast inet space)
..
..
---> s_wan <-> s_openvpn <-> s_tap <-> s_bridge <-> s_lan

and problem lies between s_wan and s_tap (packets reach s_wan, but not s_tap), bridge0 interface is not even reached.

(c_* means client side, s_* server side; so s_wan = rl0, s_tap = tap0, s_bridge = bridge0)

Right now i'm checking verb 11 log from server openvpn, and compare it to logs from s_tap, s_wan, c_tap, c_wan...

 

[xor]

I've found it ! As i presumed, tap0 interface was a problem. Yet how trivial... Tap0 interface is not up when created by openvpn.
Adding simple:

ifconfig $dev up

to up.sh solves the problem.

And what only was needed, was to look more carefuly to ifconfig output... eh

btw. in down.sh also added

ifconfig $dev destroy

b'couse openvpn creates it, but not destroys on exit. But it's just cosmetic change.

pbd -> big thanks ! you were very helpful to me. Děkuji


Now next problem of course occured... extremly slow exploring of samba shares. Pings are 150-300ms...