tab bridge Raspberry Pi <-> Mac OSX 10.9.5 / Tunnelblick

THW

Hi,

I have the following Problem:
I have OpenVPN (2.3.6) up and running successfully between numerous sites with tun / routing. No problems.

No I need to connect one Network with an OpenVPN Ethernet bridge to one client because I need to route other protocols (Synology NAS etc.)
I'm trying all sort of probably nonsense since a week, exhausted google search, read good and bad howtos, re-read the OpenVPN howto's up and down and now I feel stuck and ready to give up. I don't know how to proceed.

My setup:

SERVER Side:

OpenVPN-Server:
LAN, 192.168.199/24,
Gateway 192.168.199.1,
Nameserver 192.168.199.2,
DHCP Server 192.168.199.2
OpenVPN Server 192.168.199.239

OpenVPN Server is a Raspberry PI, Debian wheezy

/etc/network/interfaces:

auto lo
iface lo inet loopback

auto br0
iface br0 inet static
	address 192.168.199.239
	netmask 255.255.255.0
	gateway 192.168.199.1
	dns-nameservers 192.168.199.2 192.168.199.1 8.8.8.8
	pre-up openvpn --mktun --dev tap0
	pre-up ifconfig eth0 promisc
	pre-up ifconfig tap0 promisc
	bridge_ports eth0 tap0

auto eth0:1
iface eth0:1 inet static
	address 10.10.3.1
	netmask 255.255.255.0
	gateway 192.168.199.1
	dns-nameservers 192.168.199.2 192.168.199.1 8.8.8.8

Bridge comes up, tcpdump -i br0 dumps nicely all desired packets.
So my believe is that the bridge-part is ok.

My Server.conf:
(current status, after following advise from http://www.arda.homeunix.net/openvpn-setup/)

local 192.168.199.239
port 1194
proto tcp
dev tap0

ca 	/etc/openvpn/keys/...
cert	/etc/openvpn/keys/...
key	/etc/openvpn/keys/...
dh	/etc/openvpn/keys/...

ifconfig-pool-persist ipp.txt

server-bridge 192.168.199.239 255.255.255.0 192.168.199.245 192.168.199.250
ifconfig 192.168.199.240 255.255.255.0

push "dhcp-option DNS 192.168.199.2"


keepalive 120 360
link-mtu 1576

status openvpn-server.log
verb 4

Still on the server Side, I fire up OpenVPN, tcpdump on tap0 and see nicely the packets I'm supposed to see.
Same as on br0. So the server side gets packets all the way into the tap0 interface. Fine, I think.

CLIENT Side:

The client side is a MacBook Air, connected through WLAN to a DSL router:
MacBook: 192.168.1.100
DSL-Router: 192.168.1.1
Netmask 255.255.255.0

I have some aktive OpenVPN connections running, one of them connecting me to my above mentioned OpenVPN server.
For the new connection I need to use a ssh-tunnel or the existing OpenVPN tun connection, because the server is not reachable from the outside.
More detail:
192.168.199.239 runs an OpenVPN client to connect to a OpenVPN server in the public.
My Macbook runs an OpenVPN client to connect to the same OpenVPN server in the public.
Connection is up, ping works, login works, DNS works, all great, but that's not the problem here.

I decide to use a ssh-tunnel to allow my the tap-OpenVPN client to reach the tap-OpenVPN server at 192.168.199.239, which is accessible to me through the existing run-OpenVPN connection:

ssh -L1192:192.168.199.239:1192 .... 10.10.3.1
works.

Local (MacbookAir) config:

client
proto tcp
dev tap

remote localhost 1194

resolv-retry infinite

nobind

persist-key
persist-tun


mute-replay-warnings

ca 	ca.crt
cert 	MBA-HW.crt
key 	MBA-HW.key

ns-cert-type server

comp-lzo
link-mtu 1576

lladdr 00:ff:32:b6:80:df

# Set log file verbosity.
verb 4

# Silence repeating messages
mute 20

connects fine.
Tunnelblick-log:

2015-01-26 13:57:42 *Tunnelblick: OS X 10.9.5; Tunnelblick 3.4.3 (build 4055.4198); prior version 3.4.2 (build 4055.4161)
2015-01-26 13:57:42 *Tunnelblick: Attempting connection with UNICAT using shadow copy; Set nameserver = 1; not monitoring connection
2015-01-26 13:57:42 *Tunnelblick: openvpnstart start UNICAT.tblk 1337 1 0 1 1 16754 -ptADGNWradsgnw 2.3.6
2015-01-26 13:57:43 us=104633 Current Parameter Settings:
2015-01-26 13:57:43 us=104813   config = '/Library/Application Support/Tunnelblick/Users/...
2015-01-26 13:57:43 us=104826   mode = 0
2015-01-26 13:57:43 us=104834   show_ciphers = DISABLED
2015-01-26 13:57:43 us=104842   show_digests = DISABLED
2015-01-26 13:57:43 us=104849   show_engines = DISABLED
2015-01-26 13:57:43 us=104856   genkey = DISABLED
2015-01-26 13:57:43 us=104864   key_pass_file = '[UNDEF]'
2015-01-26 13:57:43 us=104871   show_tls_ciphers = DISABLED
2015-01-26 13:57:43 us=104878 Connection profiles [default]:
2015-01-26 13:57:43 us=104885   proto = tcp-client
2015-01-26 13:57:43 us=104893   local = '[UNDEF]'
2015-01-26 13:57:43 us=104900   local_port = 0
2015-01-26 13:57:43 us=104907   remote = 'localhost'
2015-01-26 13:57:43 us=104915   remote_port = 1194
2015-01-26 13:57:43 us=104922   remote_float = DISABLED
2015-01-26 13:57:43 us=104929   bind_defined = DISABLED
2015-01-26 13:57:43 us=104936   bind_local = DISABLED
2015-01-26 13:57:43 us=104943   connect_retry_seconds = 5
2015-01-26 13:57:43 us=104951   connect_timeout = 10
2015-01-26 13:57:43 us=104958 NOTE: --mute triggered...
2015-01-26 13:57:43 us=104980 251 variation(s) on previous 20 message(s) suppressed by --mute
2015-01-26 13:57:43 us=104990 OpenVPN 2.3.6 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Jan  8 2015
2015-01-26 13:57:43 us=105006 library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08
2015-01-26 13:57:43 us=106249 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:1337
2015-01-26 13:57:43 us=106908 Need hold release from management interface, waiting...
2015-01-26 13:57:43 *Tunnelblick: openvpnstart log:
     Tunnelblick: 
     OpenVPN started successfully. Command used to start OpenVPN (one argument per displayed line):
     
          /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.6/openvpn
          --daemon
          --log
          /Library/Application Support/Tunnelblick/Logs/...
          --cd
          /Library/Application Support/Tunnelblick/Users/...
          --config
          /Library/Application Support/Tunnelblick/Users/...
          --cd
          /Library/Application Support/Tunnelblick/Users/...
          --management
          127.0.0.1
          1337
          --management-query-passwords
          --management-hold
          --script-security
          2
          --up
          /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -w -d -a -f -ptADGNWradsgnw
          --down
          /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -w -d -a -f -ptADGNWradsgnw
          --route-pre-down
          /Applications/Tunnelblick.app/Contents/Resources/client.route-pre-down.tunnelblick.sh -w -d -a -f -ptADGNWradsgnw

2015-01-26 13:57:42 *Tunnelblick: openvpnstart starting OpenVPN
2015-01-26 13:57:43 us=291257 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1337
2015-01-26 13:57:43 *Tunnelblick: Established communication with OpenVPN
2015-01-26 13:57:43 us=327600 MANAGEMENT: CMD 'pid'
2015-01-26 13:57:43 us=327768 MANAGEMENT: CMD 'state on'
2015-01-26 13:57:43 us=327870 MANAGEMENT: CMD 'state'
2015-01-26 13:57:43 us=327996 MANAGEMENT: CMD 'bytecount 1'
2015-01-26 13:57:43 us=328215 MANAGEMENT: CMD 'hold release'
2015-01-26 13:57:43 us=328573 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2015-01-26 13:57:43 us=329689 LZO compression initialized
2015-01-26 13:57:43 us=329905 Control Channel MTU parms [ L:1576 D:140 EF:40 EB:0 ET:0 EL:0 ]
2015-01-26 13:57:43 us=330065 Socket Buffers: R=[131072->65536] S=[131072->65536]
2015-01-26 13:57:43 us=330336 MANAGEMENT: >STATE:1422273463,RESOLVE,,,
2015-01-26 13:57:43 us=332081 Data Channel MTU parms [ L:1576 D:1450 EF:44 EB:135 ET:32 EL:0 AF:3/1 ]
2015-01-26 13:57:43 us=332228 Local Options String: 'V4,dev-type tap,link-mtu 1576,tun-mtu 1532,proto TCPv4_CLIENT,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
2015-01-26 13:57:43 us=332299 Expected Remote Options String: 'V4,dev-type tap,link-mtu 1576,tun-mtu 1532,proto TCPv4_SERVER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
2015-01-26 13:57:43 us=332384 Local Options hash (VER=V4): '31fdf004'
2015-01-26 13:57:43 us=332461 Expected Remote Options hash (VER=V4): '3e6d1056'
2015-01-26 13:57:43 us=332546 Attempting to establish TCP connection with [AF_INET]127.0.0.1:1194 [nonblock]
2015-01-26 13:57:43 us=332625 MANAGEMENT: >STATE:1422273463,TCP_CONNECT,,,
2015-01-26 13:57:44 us=333411 TCP connection established with [AF_INET]127.0.0.1:1194
2015-01-26 13:57:44 us=333517 TCPv4_CLIENT link local: [undef]
2015-01-26 13:57:44 us=333589 TCPv4_CLIENT link remote: [AF_INET]127.0.0.1:1194
2015-01-26 13:57:44 us=333753 MANAGEMENT: >STATE:1422273464,WAIT,,,
2015-01-26 13:57:44 us=913748 MANAGEMENT: >STATE:1422273464,AUTH,,,
2015-01-26 13:57:44 us=914260 TLS: Initial packet from [AF_INET]127.0.0.1:1194, sid=37454b13 1117601c
...
2015-01-26 13:58:02 us=376107 Connection reset, restarting [0]
2015-01-26 13:58:02 us=376473 TCP/UDP: Closing socket
2015-01-26 13:58:02 us=376617 SIGUSR1[soft,connection-reset] received, process restarting
2015-01-26 13:58:02 us=376698 MANAGEMENT: >STATE:1422273482,RECONNECTING,connection-reset,,
2015-01-26 13:58:02 *Tunnelblick: No 'reconnecting.sh' script to execute
2015-01-26 13:58:02 us=516986 MANAGEMENT: CMD 'hold release'
2015-01-26 13:58:02 us=517385 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2015-01-26 13:58:02 us=517478 Re-using SSL/TLS context
2015-01-26 13:58:02 us=517546 LZO compression initialized
2015-01-26 13:58:02 us=517654 Control Channel MTU parms [ L:1576 D:140 EF:40 EB:0 ET:0 EL:0 ]
2015-01-26 13:58:02 us=517778 Socket Buffers: R=[131072->65536] S=[131072->65536]
2015-01-26 13:58:02 us=517911 MANAGEMENT: >STATE:1422273482,RESOLVE,,,
2015-01-26 13:58:02 us=518571 Data Channel MTU parms [ L:1576 D:1450 EF:44 EB:135 ET:32 EL:0 AF:3/1 ]
2015-01-26 13:58:02 us=518692 Local Options String: 'V4,dev-type tap,link-mtu 1576,tun-mtu 1532,proto TCPv4_CLIENT,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
2015-01-26 13:58:02 us=518764 Expected Remote Options String: 'V4,dev-type tap,link-mtu 1576,tun-mtu 1532,proto TCPv4_SERVER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
2015-01-26 13:58:02 us=518842 Local Options hash (VER=V4): '31fdf004'
2015-01-26 13:58:02 us=518913 Expected Remote Options hash (VER=V4): '3e6d1056'
2015-01-26 13:58:02 us=518992 Attempting to establish TCP connection with [AF_INET]127.0.0.1:1194 [nonblock]
2015-01-26 13:58:02 us=519057 MANAGEMENT: >STATE:1422273482,TCP_CONNECT,,,
2015-01-26 13:58:02 us=519297 TCP connection established with [AF_INET]127.0.0.1:1194
2015-01-26 13:58:02 us=519379 TCPv4_CLIENT link local: [undef]
2015-01-26 13:58:02 us=519446 TCPv4_CLIENT link remote: [AF_INET]127.0.0.1:1194
2015-01-26 13:58:02 us=519523 MANAGEMENT: >STATE:1422273482,WAIT,,,
2015-01-26 13:58:03 us=755347 MANAGEMENT: >STATE:1422273483,AUTH,,,
2015-01-26 13:58:03 us=755460 TLS: Initial packet from [AF_INET]127.0.0.1:1194, sid=c6438e3c e967f3e3
...
2015-01-26 13:58:17 us=887773 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1532', remote='tun-mtu 1533'
2015-01-26 13:58:17 us=887940 WARNING: 'comp-lzo' is present in local config but missing in remote config, local='comp-lzo'
2015-01-26 13:58:17 us=888375 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
2015-01-26 13:58:17 us=888459 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
2015-01-26 13:58:17 us=888617 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
2015-01-26 13:58:17 us=888686 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
2015-01-26 13:58:17 us=888809 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
2015-01-26 13:58:17 us=888962 [unicat-server] Peer Connection Initiated with [AF_INET]127.0.0.1:1194
2015-01-26 13:58:18 us=809507 MANAGEMENT: >STATE:1422273498,GET_CONFIG,,,
2015-01-26 13:58:19 us=423779 SENT CONTROL [unicat-server]: 'PUSH_REQUEST' (status=1)
2015-01-26 13:58:20 us=754633 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 192.168.199.2,route-gateway 192.168.199.239,ping 120,ping-restart 360,ifconfig 192.168.199.245 255.255.255.0'
2015-01-26 13:58:20 us=754920 OPTIONS IMPORT: timers and/or timeouts modified
2015-01-26 13:58:20 us=755003 OPTIONS IMPORT: --ifconfig/up options modified
2015-01-26 13:58:20 us=755067 OPTIONS IMPORT: route-related options modified
2015-01-26 13:58:20 us=755128 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2015-01-26 13:58:20 us=755477 TUN/TAP device /dev/tap0 opened
2015-01-26 13:58:20 us=755592 /sbin/ifconfig tap0 lladdr 00:ff:32:b6:80:df
2015-01-26 13:58:20 us=760657 TUN/TAP link layer address set to 00:ff:32:b6:80:df
2015-01-26 13:58:20 us=760825 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
2015-01-26 13:58:20 us=760921 MANAGEMENT: >STATE:1422273500,ASSIGN_IP,,192.168.199.245,
2015-01-26 13:58:20 us=761010 /sbin/ifconfig tap0 delete
                                        ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
2015-01-26 13:58:20 us=766839 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2015-01-26 13:58:20 us=766956 /sbin/ifconfig tap0 192.168.199.245 netmask 255.255.255.0 mtu 1500 up
2015-01-26 13:58:20 us=769380 /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -w -d -a -f -ptADGNWradsgnw tap0 1500 1576 192.168.199.245 255.255.255.0 init
                                        **********************************************
                                        Start of output from client.up.tunnelblick.sh
                                        Configuring tap DNS via DHCP asynchronously
                                        End of output from client.up.tunnelblick.sh
                                        **********************************************
2015-01-26 13:58:22 us=816210 Initialization Sequence Completed
2015-01-26 13:58:22 us=816525 MANAGEMENT: >STATE:1422273502,CONNECTED,SUCCESS,192.168.199.245,127.0.0.1
2015-01-26 13:58:22 *Tunnelblick: No 'connected.sh' script to execute
2015-01-26 13:58:22 *Tunnelblick: Could not determine this computer's apparent public IP address before the connection was completed
                                        Sleeping for 0 seconds to wait for DHCP to finish setup.
                                        Sleeping for 1 seconds to wait for DHCP to finish setup.
                                        Sleeping for 2 seconds to wait for DHCP to finish setup.
                                        Sleeping for 3 seconds to wait for DHCP to finish setup.
                                        Sleeping for 4 seconds to wait for DHCP to finish setup.
                                        WARNING: No DNS information received from OpenVPN (DHCP), so no network/DNS configuration changes need to be made.

No remote packets seen with tcpdump -i tap0 this (Macbook) side...

OpenVPN-Server-log:

Jan 26 12:57:43 localhost ovpn-server[3615]: MULTI: multi_create_instance called
Jan 26 12:57:43 localhost ovpn-server[3615]: Re-using SSL/TLS context
Jan 26 12:57:43 localhost ovpn-server[3615]: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1501)
Jan 26 12:57:43 localhost ovpn-server[3615]: Control Channel MTU parms [ L:1576 D:140 EF:40 EB:0 ET:0 EL:0 ]
Jan 26 12:57:43 localhost ovpn-server[3615]: Data Channel MTU parms [ L:1576 D:1450 EF:43 EB:4 ET:32 EL:0 ]
Jan 26 12:57:43 localhost ovpn-server[3615]: Local Options String: 'V4,dev-type tap,link-mtu 1576,tun-mtu 1533,proto TCPv4_SERVER,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Jan 26 12:57:43 localhost ovpn-server[3615]: Expected Remote Options String: 'V4,dev-type tap,link-mtu 1576,tun-mtu 1533,proto TCPv4_CLIENT,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Jan 26 12:57:43 localhost ovpn-server[3615]: Local Options hash (VER=V4): '92393728'
Jan 26 12:57:43 localhost ovpn-server[3615]: Expected Remote Options hash (VER=V4): '8084fe4a'
Jan 26 12:57:43 localhost ovpn-server[3615]: TCP connection established with [AF_INET]192.168.199.239:55475
Jan 26 12:57:43 localhost ovpn-server[3615]: TCPv4_SERVER link local: [undef]
Jan 26 12:57:43 localhost ovpn-server[3615]: TCPv4_SERVER link remote: [AF_INET]192.168.199.239:55475
Jan 26 12:57:44 localhost ovpn-server[3615]: 192.168.199.239:55475 TLS: Initial packet from [AF_INET]192.168.199.239:55475, sid=059043e8 62d23a8e
...
Jan 26 12:58:01 localhost ovpn-server[3615]: 192.168.199.239:55475 TLS_ERROR: BIO read tls_read_plaintext error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
Jan 26 12:58:01 localhost ovpn-server[3615]: 192.168.199.239:55475 TLS Error: TLS object -> incoming plaintext read error
Jan 26 12:58:01 localhost ovpn-server[3615]: 192.168.199.239:55475 TLS Error: TLS handshake failed
Jan 26 12:58:01 localhost ovpn-server[3615]: 192.168.199.239:55475 Fatal TLS error (check_tls_errors_co), restarting
Jan 26 12:58:01 localhost ovpn-server[3615]: 192.168.199.239:55475 SIGUSR1[soft,tls-error] received, client-instance restarting
Jan 26 12:58:01 localhost ovpn-server[3615]: TCP/UDP: Closing socket
Jan 26 12:58:02 localhost ovpn-server[3615]: MULTI: multi_create_instance called
Jan 26 12:58:02 localhost ovpn-server[3615]: Re-using SSL/TLS context
Jan 26 12:58:02 localhost ovpn-server[3615]: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1501)
Jan 26 12:58:02 localhost ovpn-server[3615]: Control Channel MTU parms [ L:1576 D:140 EF:40 EB:0 ET:0 EL:0 ]
Jan 26 12:58:02 localhost ovpn-server[3615]: Data Channel MTU parms [ L:1576 D:1450 EF:43 EB:4 ET:32 EL:0 ]
Jan 26 12:58:02 localhost ovpn-server[3615]: Local Options String: 'V4,dev-type tap,link-mtu 1576,tun-mtu 1533,proto TCPv4_SERVER,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Jan 26 12:58:02 localhost ovpn-server[3615]: Expected Remote Options String: 'V4,dev-type tap,link-mtu 1576,tun-mtu 1533,proto TCPv4_CLIENT,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Jan 26 12:58:02 localhost ovpn-server[3615]: Local Options hash (VER=V4): '92393728'
Jan 26 12:58:02 localhost ovpn-server[3615]: Expected Remote Options hash (VER=V4): '8084fe4a'
Jan 26 12:58:02 localhost ovpn-server[3615]: TCP connection established with [AF_INET]192.168.199.239:55476
Jan 26 12:58:02 localhost ovpn-server[3615]: TCPv4_SERVER link local: [undef]
Jan 26 12:58:02 localhost ovpn-server[3615]: TCPv4_SERVER link remote: [AF_INET]192.168.199.239:55476
...
Jan 26 12:58:16 localhost ovpn-server[3615]: 192.168.199.239:55476 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1533', remote='tun-mtu 1532'
Jan 26 12:58:16 localhost ovpn-server[3615]: 192.168.199.239:55476 WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'
Jan 26 12:58:16 localhost ovpn-server[3615]: 192.168.199.239:55476 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Jan 26 12:58:16 localhost ovpn-server[3615]: 192.168.199.239:55476 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jan 26 12:58:16 localhost ovpn-server[3615]: 192.168.199.239:55476 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Jan 26 12:58:16 localhost ovpn-server[3615]: 192.168.199.239:55476 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jan 26 12:58:18 localhost ovpn-server[3615]: 192.168.199.239:55476 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Jan 26 12:58:18 localhost ovpn-server[3615]: 192.168.199.239:55476 [MBA-HW] Peer Connection Initiated with [AF_INET]192.168.199.239:55476
Jan 26 12:58:18 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI_sva: pool returned IPv4=192.168.199.245, IPv6=38b1:d7be:801e:f0b6:344b:f5b6:9c26:2b7
Jan 26 12:58:19 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 PUSH: Received control message: 'PUSH_REQUEST'
Jan 26 12:58:19 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 send_push_reply(): safe_cap=960
Jan 26 12:58:19 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 SENT CONTROL [MBA-HW]: 'PUSH_REPLY,dhcp-option DNS 192.168.199.2,route-gateway 192.168.199.239,ping 120,ping-restart 360,ifconfig 192.168.199.245 255.255.255.0' (status=1)
Jan 26 12:58:22 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped
Jan 26 12:58:22 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped
Jan 26 12:58:22 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:ff:ff:00:ff:32], packet dropped
Jan 26 12:58:23 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: Learn: 00:00:fb:00:ff:32 -> MBA-HW/192.168.199.239:55476
Jan 26 12:58:24 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:ff:ff:00:ff:32], packet dropped
Jan 26 12:58:26 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:ff:ff:00:ff:32], packet dropped
Jan 26 12:58:30 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:ff:ff:00:ff:32], packet dropped
Jan 26 12:58:39 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped
Jan 26 12:58:40 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped
Jan 26 12:58:40 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped
Jan 26 12:58:40 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped
^C

what puzzles me, is that the bad source address is a 'shift' of the MAC-Address of the tap0 interface:

tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 00:ff:32:b6:80:df
inet 192.168.199.245 netmask 0xffffff00 broadcast 192.168.199.255
inet 169.254.159.127 netmask 0xffff0000 broadcast 169.254.255.255
open (pid 1290)

plus, where is the 169.254.159.127 interface coming from?

If anybody has a clue or a pointer to a working Linux <-> Mac Openvpn tap bridge,

please let me know.

Thanks id advance.

Thomas.

Traffic

THW wroteJan 26 12:58:40 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped

The OpenVPN server has no routing info for 192.168.199.239 : The usual solution is to add an iroute for the host to the CCD file.
eg: CCD_File:iroute 192.168.199.239

THW wroteinet 169.254.159.127 netmask 0xffff0000 broadcast 169.254.255.255

This is a DHCP default IP address .. means that the interface has failed to assign an IP address via DHCP. Check your DHCP server setup and make sure what ever services are required for your client to assign a DHCP address are started (Windows: DHCP client service).

*Note: Your setup sounds complex, so these solutions may not apply.

THW

Thanks for your help, Traffic.

But I don't think it would help:

Traffic wrote The OpenVPN server has no routing info for 192.168.199.239 : The usual solution is to add an iroute for the host to the CCD file.
eg: CCD_File:iroute 192.168.199.239

My understanding/hope is that we are'nt routing here.
It's supposed to be an Ethernet bridge, meaning we are not handling Layer 3 (IP routing), but one level lower, MAC/Ethernet 'routing', like a switch.

Traffic wrote
THW wroteinet 169.254.159.127 netmask 0xffff0000 broadcast 169.254.255.255
This is a DHCP default IP address .. means that the interface has failed to assign an IP address via DHCP. Check your DHCP server setup and make sure what ever services are required for your client to assign a DHCP address are started (Windows: DHCP client service).
*Note: Your setup sounds complex, so these solutions may not apply.

DHCP is running just fine on the 192.168.199/24 side. It's a mixed network of Windows, Mac, Linux, Handheld, etc. pp. computers and none of them ever complained about DHCP problems.
Also the server-bridge statement in the server config is the one giving out a range of IP adresses as stated in the statement. We probably need DHCP to tell us about gateway, nameservers, ntp servers and so forth, but my understanding is that this is done 'through' the tap0 interface on the client side, right? And as long as NO Ethernet frame passes through it, there can't be a response from the server side. But maybe I don't understand enough about the internals - maybe the OpenVPN client/server are still responsible for the DHCP requests on their communication line....

No, I think the main problem really lies with the 'packet dropped' messages.
As I said, the MAC adresses are 'shifted', let me explain:
the MAC adress assigned to the client-tap0 is 00:ff:32:b6:80:df

Jan 26 12:58:19 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 SENT CONTROL [MBA-HW]: 'PUSH_REPLY,dhcp-option DNS 192.168.199.2,route-gateway 192.168.199.239,ping 120,ping-restart 360,ifconfig 192.168.199.245 255.255.255.0' (status=1)
Jan 26 12:58:22 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped
Jan 26 12:58:22 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped
Jan 26 12:58:22 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:ff:ff:00:ff:32], packet dropped
Jan 26 12:58:23 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: Learn: 00:00:fb:00:ff:32 -> MBA-HW/192.168.199.239:55476
Jan 26 12:58:24 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:ff:ff:00:ff:32], packet dropped
Jan 26 12:58:26 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:ff:ff:00:ff:32], packet dropped
Jan 26 12:58:30 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:ff:ff:00:ff:32], packet dropped
Jan 26 12:58:38 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:ff:ff:00:ff:32], packet dropped
Jan 26 12:58:38 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped
Jan 26 12:58:39 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped
Jan 26 12:58:39 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped
Jan 26 12:58:39 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped
Jan 26 12:58:40 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped
Jan 26 12:58:40 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped
Jan 26 12:58:40 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped
Jan 26 12:58:42 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [fb:00:ff:32:b6:80], packet dropped
Jan 26 12:58:43 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [fb:00:ff:32:b6:80], packet dropped
Jan 26 12:58:43 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [fb:00:ff:32:b6:80], packet dropped

what we see here is the same adress 00:ff:32:b6:80:df scrambled in various ways.

Jan 26 12:58:22 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped
Jan 26 12:58:22 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped

our MAC address is 'shifted right' by 1, padded with 'ff' on the left.

Jan 26 12:58:22 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:ff:ff:00:ff:32], packet dropped
Jan 26 12:58:23 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: Learn: 00:00:fb:00:ff:32 -> MBA-HW/192.168.199.239:55476
Jan 26 12:58:24 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:ff:ff:00:ff:32], packet dropped
Jan 26 12:58:26 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:ff:ff:00:ff:32], packet dropped
Jan 26 12:58:30 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:ff:ff:00:ff:32], packet dropped
Jan 26 12:58:38 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:ff:ff:00:ff:32], packet dropped

shifted right by 3, padded left with 'ff:ff:ff'
'learns' an adress that's also shifted right by 3, padded with '00:00:fb'

Jan 26 12:58:38 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped
Jan 26 12:58:39 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped
Jan 26 12:58:39 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped
Jan 26 12:58:39 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped
Jan 26 12:58:40 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped
Jan 26 12:58:40 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped
Jan 26 12:58:40 localhost ovpn-server[3615]: MBA-HW/192.168.199.239:55476 MULTI: bad source address from client [ff:00:ff:32:b6:80], packet dropped

shifted right by 1, padded with 'ff'. And so on.
So we see Ethernet frames, but their addresses are not quite random, but seemingly randomly shifted and padded...

I have no explanation for this at all, but my strong believe is that as long as we experience this, there is no hope to have a working bridge.

Thomas.

THW

Well, mystery solved:

It's NOT very helpful to have comp-lzo in one config (client) and not in the other (server). :oops:
Found out be eliminated MacOS specifics by temporarily using a Linux-Box to test the setup.

Now the bridge is up and running - the 'only' problem left now is getting the en0 - tap0 bridge setup on MacOS.
Anybody done that? From what I read I need to sysctl forwarding? Shouldn't - we are talking layer 2, right?

Thomas.

Traffic

169.254.0.0/16 is the default range assigned when DHCP fails .. double check your DHCP.

THW wrote/etc/network/interfaces:

Code:
auto lo
iface lo inet loopback

auto br0
iface br0 inet static
address 192.168.199.239
netmask 255.255.255.0
gateway 192.168.199.1
dns-nameservers 192.168.199.2 192.168.199.1 8.8.8.8
pre-up openvpn --mktun --dev tap0
pre-up ifconfig eth0 promisc
pre-up ifconfig tap0 promisc
bridge_ports eth0 tap0

auto eth0:1
iface eth0:1 inet static
address 10.10.3.1
netmask 255.255.255.0
gateway 192.168.199.1
dns-nameservers 192.168.199.2 192.168.199.1 8.8.8.8

Bridge comes up, tcpdump -i br0 dumps nicely all desired packets.
So my believe is that the bridge-part is ok.

This is wrong ..

When you create a bridge .. all interfaces included in the bridge take on the bridge IP address not their own.

Traffic

Traffic wrotebridge_ports eth0 tap0

auto eth0:1

Maybe .. in this case I missed the :1 part.

THW

Traffic wrote
Traffic wrotebridge_ports eth0 tap0

auto eth0:1
Maybe .. in this case I missed the :1 part.

Yep.
Otherwise it wouldn't have worked at all.

But see my post above (where I say that part of the problem is solved. Shame on me for that nonsense.)

I'm still missing the bridge part on the Mac.
Actually I made good progress on that side. Bridge is working:

sudo ifconfig create bridge1
sudo ifconfig bridge1 addm en0
sudo ifcontig bridge1 addm tap0
sudo ifconfig bridge1 up

Problem is now:
- the Synology Tool sends a broadcast to 255.255.255.255. Rightfully so.
- The Mac doesn't do what he's supposed to do:
I think it should send packets to all available local devices (en0 - 192.168.1.100, tap0 - 192.168.199.43), so packets should go out to 192.168.199.255 and 192.168.1.255
but only sends packets to 192.168.1.255

I tried to trick it with setting arp 'ff:ff:ff:ff:ff:ff' entries and routing the 255.255.255.255 to the pseudo-host with this entry, but so far I'm not successful...

Maybe later, maybe somebody has advice

Thomas.

Traffic

THW wrote The Mac doesn't do what he's supposed to do:
I think it should send packets to all available local devices (en0 - 192.168.1.100, tap0 - 192.168.199.43), so packets should go out to 192.168.199.255 and 192.168.1.255
but only sends packets to 192.168.1.255

I had the same problem with windows clients and solved it by:

server-bridge IP.add.default.gw etc

so change from server-bridge 192.168.199.239 to server-bridge 192.168.199.1 .. that worked for me.

Traffic

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

Traffic

Even this information is now out-dated !

Client running 23x will automatically load/initialize LZO after the first failure if the session is restarted by openvpn.

IE:

Server CCD for client:

push "comp-lzo"

Client no comp-lzo parameter specified:

Client Log #1:

Tue Jan 27 17:16:03 2015 us=691924 OpenVPN 2.3.6 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Dec 1 2014
Tue Jan 27 17:16:03 2015 us=691924 library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.08
... {no LZO Initiallized}
Tue Jan 27 17:16:10 2015 us=161227 PUSH: Received control message: 'PUSH_REPLY, ... ,comp-lzo, ... ,ifconfig x x'
Tue Jan 27 17:16:10 2015 us=161227 Option 'explicit-exit-notify' in [PUSH-OPTIONS]:3 is ignored by previous <connection> blocks
Tue Jan 27 17:16:10 2015 us=161227 OPTIONS IMPORT: timers and/or timeouts modified
Tue Jan 27 17:16:10 2015 us=161227 OPTIONS IMPORT: explicit notify parm(s) modified
Tue Jan 27 17:16:10 2015 us=161227 OPTIONS IMPORT: --ifconfig/up options modified
Tue Jan 27 17:16:10 2015 us=161227 OPTIONS IMPORT: route options modified
Tue Jan 27 17:16:10 2015 us=161227 OPTIONS IMPORT: route-related options modified
Tue Jan 27 17:16:10 2015 us=161227 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Tue Jan 27 17:16:30 2015 us=380300 write to TUN/TAP [State=AT?c Err=[c:\users\samuli\tap-windows-github\src\tapdrvr.c/2475] #O=2 Tx=[8,0] Rx=[0,2] IrpQ=[0,1,16] PktQ=[0,1,64] InjQ=[0,1,16]]: The data area passed to a system call is too small. (code=122)
Tue Jan 27 17:16:40 2015 us=64225 write to TUN/TAP [State=AT?c Err=[c:\users\samuli\tap-windows-github\src\tapdrvr.c/2475] #O=2 Tx=[15,0] Rx=[0,3] IrpQ=[1,1,16] PktQ=[0,1,64] InjQ=[0,1,16]]: The data area passed to a system call is too small. (code=122)
...
Tue Jan 27 17:17:31 2015 us=77579 [client1] Inactivity timeout (--ping-restart), restarting
Tue Jan 27 17:17:31 2015 us=77579 TCP/UDP: Closing socket
...
Tue Jan 27 17:17:31 2015 us=97608 Closing TUN/TAP interface
Tue Jan 27 17:17:31 2015 us=107622 SIGUSR1[soft,ping-restart] received, process restarting

Server Log #1:

Tue Jan 27 17:16:05 2015 us=472843 MULTI: multi_create_instance called
..
Tue Jan 27 17:16:08 2015 us=116872 88.105.39.199:2845 WARNING: 'comp-lzo' is present in local config but missing in remote config, local='comp-lzo'
..
Tue Jan 27 17:16:10 2015 us=163596 client1/x.x.x.x:pppp SENT CONTROL [client1]: 'PUSH_REPLY, ... ,comp-lzo, ... ,ifconfig x x' (status=1)
Tue Jan 27 17:16:15 2015 us=355525 client1/x.x.x.x:pppp Bad compression stub decompression header byte: 69
Tue Jan 27 17:16:16 2015 us=832727 client1/x.x.x.x:pppp Bad compression stub decompression header byte: 69
...
Tue Jan 27 17:17:10 2015 us=77366 client1/x.x.x.x:pppp [client1] Inactivity timeout (--ping-restart), restarting
Tue Jan 27 17:17:10 2015 us=77694 client1/x.x.x.x:pppp SIGUSR1[soft,ping-restart] received, client-instance restarting

Client log #2:

Tue Jan 27 17:17:31 2015 us=107622 MANAGEMENT: >STATE:1422379051,RECONNECTING,ping-restart,,
Tue Jan 27 17:17:31 2015 us=117636 Restart pause, 2 second(s)
...
Tue Jan 27 17:17:33 2015 us=130531 LZO compression initialized
...
Tue Jan 27 17:17:38 2015 us=227860 PUSH: Received control message: 'PUSH_REPLY, ... ,comp-lzo, ... ,ifconfig x x'
Tue Jan 27 17:17:38 2015 us=227860 Option 'explicit-exit-notify' in [PUSH-OPTIONS]:3 is ignored by previous <connection> blocks
Tue Jan 27 17:17:38 2015 us=227860 OPTIONS IMPORT: timers and/or timeouts modified
Tue Jan 27 17:17:38 2015 us=227860 OPTIONS IMPORT: explicit notify parm(s) modified
Tue Jan 27 17:17:38 2015 us=227860 OPTIONS IMPORT: LZO parms modified
Tue Jan 27 17:17:38 2015 us=227860 OPTIONS IMPORT: --ifconfig/up options modified
Tue Jan 27 17:17:38 2015 us=237875 OPTIONS IMPORT: route options modified
Tue Jan 27 17:17:38 2015 us=237875 OPTIONS IMPORT: route-related options modified
Tue Jan 27 17:17:38 2015 us=237875 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
...
Tue Jan 27 17:17:49 2015 us=113513 Initialization Sequence Completed

Server log #2:

Tue Jan 27 17:17:33 2015 us=183884 MULTI: multi_create_instance called
...
Tue Jan 27 17:17:38 2015 us=237866 client1/x.x.x.x:pppp SENT CONTROL [client1]: 'PUSH_REPLY, ... ,comp-lzo, ... ,ifconfig x x' (status=1)

and all is well :ugeek:

Traffic

Even this information is now out of date !

If you run 2.3_git-master:

comp-lzo is loaded/initialized by default (if it is included at compile)
the server push will set the client and server lzo
regardless of what the client config specifies.
No time-out restart required.