Hi all,
It appears that the tap interface isn't forwarding traffic between OVPN endpoints.
A bit of background:
I have two networks which I intend to bridge using OpenVPN; so, I'll have a computer on each end creating a tap connection and making an interface bridge to the local network. (Don't worry: I know how to make sure there are DHCP conflicts and whatnot).
The server is an OS-X 10.9 server running OpenVPN 2.3.2 and I'm using the TUNTAP kernel extension found easily via the almighty google. (Note that I have a similar server running a tunnel and it works perfectly).
The endpoint, in the end, will probably be a Raspberry Pi running Rasbian (as long as it doesn't end up being too slow, but initial tests are promising).
For testing, I currently have the following setup:
ClientMachine ---> Phone ---> Internet
MyNetworkAndOVPNServer ---> Router ---> Internet
Note that my main network is using 10.0.0.0/16.
When I had troubles with the RasPi, I got an old MBP running OS-X 10.7.5 also with OVPN 2.3.2 to test as the client. Both computers exhibit the same behavior.
So, the problem:
I have the server set up with the following configuration:
(NOTE: Some of the settings may be unnecessary because: (a) what is and is not needed isn't all that clear; and (b) this was made by modifying the tun server's configuration)
port 9004
proto udp
dev tap0
# HELP! I saw this somewhere... Does it do anything?
mode server
#server-bridge 192.168.251.4 255.255.255.0 192.168.251.128 192.168.251.254
#server 192.168.251.0 255.255.255.0
persist-local-ip
persist-remote-ip
comp-lzo
keepalive 10 120
client-to-client
user daemon
group daemon
writepid /var/run/ovpn_bridge
persist-key
persist-tun
ca ../Keys/ca.crt
cert ../Keys/server.crt
key ../Keys/server.key
duplicate-cn # Allow this (so we can have one cert per person)
dh ../Keys/dh1024.pem
tls-auth ../Keys/shared.key 0
tls-server
cipher AES-256-CBC
status /KGL/Services/OpenVPN/Server-Bridge/log.ovpn.status.txt
log-append /KGL/Services/OpenVPN/Server-Bridge/log.ovpn.general.txt
verb 3
mute 20
The server starts successfully, creates tap0, sets and IP address/netmask (if I uncomment one of the server directives), and whatnot.
The client is set up with the following configuration:
proto udp
remote 10.0.0.2 9004
resolv-retry infinite
dev tap0
client
comp-lzo
keepalive 10 120
nobind
ca ca.crt
cert client.crt
key client.key
dh dh1024.pem
tls-auth shared.key 1
cipher AES-256-CBC
status openvpn-status.log
log-append openvpn.log
verb 3
mute 20
When I run OVPN on the client, it connects. Both the server's and the client's log register a successful connection and don't appear to be giving any errors.
Server log:
Fri Mar 14 20:44:37 2014 MULTI: multi_create_instance called
Fri Mar 14 20:44:37 2014 10.0.0.214:37091 Re-using SSL/TLS context
Fri Mar 14 20:44:37 2014 10.0.0.214:37091 LZO compression initialized
Fri Mar 14 20:44:37 2014 10.0.0.214:37091 Control Channel MTU parms [ L:1590 D:166 EF:66 EB:0 ET:0 EL:0 ]
Fri Mar 14 20:44:37 2014 10.0.0.214:37091 Data Channel MTU parms [ L:1590 D:1450 EF:58 EB:135 ET:32 EL:0 AF:3/1 ]
Fri Mar 14 20:44:37 2014 10.0.0.214:37091 Local Options hash (VER=V4): '44bd8b5e'
Fri Mar 14 20:44:37 2014 10.0.0.214:37091 Expected Remote Options hash (VER=V4): '48527533'
Fri Mar 14 20:44:37 2014 10.0.0.214:37091 TLS: Initial packet from 10.0.0.214:37091, sid=223aa708 4eaf9e9f
Fri Mar 14 20:44:37 2014 10.0.0.214:37091 VERIFY OK: depth=1, <MANUALLY-REDACTED>
Fri Mar 14 20:44:37 2014 10.0.0.214:37091 VERIFY OK: depth=0, <MANUALLY-REDACTED>
Fri Mar 14 20:44:37 2014 10.0.0.214:37091 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Fri Mar 14 20:44:37 2014 10.0.0.214:37091 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Mar 14 20:44:37 2014 10.0.0.214:37091 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Fri Mar 14 20:44:37 2014 10.0.0.214:37091 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Mar 14 20:44:37 2014 10.0.0.214:37091 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Mar 14 20:44:37 2014 10.0.0.214:37091 [OVPN-chris] Peer Connection Initiated with 10.0.0.214:37091
Fri Mar 14 20:44:39 2014 OVPN-chris/10.0.0.214:37091 PUSH: Received control message: 'PUSH_REQUEST'
Fri Mar 14 20:44:39 2014 OVPN-chris/10.0.0.214:37091 SENT CONTROL [OVPN-chris]: 'PUSH_REPLY,route-gateway 192.168.251.4,ping 10,ping-restart 120,ifconfig 192.168.251.128 255.255.255.0' (status=1)
Client log:
Fri Mar 14 20:44:36 2014 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Fri Mar 14 20:44:36 2014 WARNING: file 'client.key' is group or others accessible
Fri Mar 14 20:44:36 2014 WARNING: file 'shared.key' is group or others accessible
Fri Mar 14 20:44:36 2014 Control Channel Authentication: using 'shared.key' as a OpenVPN static key file
Fri Mar 14 20:44:36 2014 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Mar 14 20:44:36 2014 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Mar 14 20:44:36 2014 Socket Buffers: R=[42080->65536] S=[9216->65536]
Fri Mar 14 20:44:36 2014 UDPv4 link local: [undef]
Fri Mar 14 20:44:36 2014 UDPv4 link remote: [AF_INET]10.0.0.2:9004
Fri Mar 14 20:44:37 2014 TLS: Initial packet from [AF_INET]10.0.0.2:9004, sid=9c562f4a d2649b3e
Fri Mar 14 20:44:37 2014 VERIFY OK: depth=1, C=US, ST=Arizona, L=Tucson, O=Kemsley-Cluster, OU=OVPN-CA, CN=OVPN-CA, name=OVPN-CA, emailAddress=kemsleyc@gmail.com
Fri Mar 14 20:44:37 2014 VERIFY OK: depth=0, C=US, ST=Arizona, L=Tucson, O=Kemsley-Cluster, OU=OVPN-Server, CN=OVPN-Server, name=OVPN-Server, emailAddress=kemsleyc@gmail.com
Fri Mar 14 20:44:37 2014 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Fri Mar 14 20:44:37 2014 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Mar 14 20:44:37 2014 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Fri Mar 14 20:44:37 2014 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Mar 14 20:44:37 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Mar 14 20:44:37 2014 [OVPN-Server] Peer Connection Initiated with [AF_INET]10.0.0.2:9004
Fri Mar 14 20:44:39 2014 SENT CONTROL [OVPN-Server]: 'PUSH_REQUEST' (status=1)
Fri Mar 14 20:44:39 2014 PUSH: Received control message: 'PUSH_REPLY,route-gateway 192.168.251.4,ping 10,ping-restart 120,ifconfig 192.168.251.128 255.255.255.0'
Fri Mar 14 20:44:39 2014 OPTIONS IMPORT: timers and/or timeouts modified
Fri Mar 14 20:44:39 2014 OPTIONS IMPORT: --ifconfig/up options modified
Fri Mar 14 20:44:39 2014 OPTIONS IMPORT: route-related options modified
Fri Mar 14 20:44:39 2014 TUN/TAP device /dev/tap0 opened
Fri Mar 14 20:44:39 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Fri Mar 14 20:44:39 2014 /sbin/ifconfig tap0 delete
ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
Fri Mar 14 20:44:39 2014 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
Fri Mar 14 20:44:39 2014 /sbin/ifconfig tap0 192.168.251.128 netmask 255.255.255.0 mtu 1500 up
Fri Mar 14 20:44:39 2014 Initialization Sequence Completed
The client messages about the tap interface are OK, I think. The tap interface is created and assigned an IP.
After connection, I assigned the interfaces manually (and did a bridge on the server side):
The server's addresses:
en1: 10.0.0.2/16
tap0: 10.0.1.220/16 <-- temporary
bridge0: bridging en1 and tap0
The client's addresses:
en1 (phone's connection): 172.something (forgot what it was)
tap0: 10.0.0.252/16
No bridge.
Note that I've also played with other configurations, such as using OpenVPN's assigned IPs, no bridging, etc and the behavior is the same.
On the client, I do:
... when I manually assigned addresses:
ping 10.0.0.2
ping 10.0.1.220
... when I left OpenVPN's addresses:
ping 192.168.251.128
ping 192.168.251.1
The only ping that works (i.e. isn't "unreachable" or "timed out") is the 192.168.251.128 (which is itself... so, duh)
I cannot for the life of me figure out why this isn't working. A tap should just be a tap, right?
Any help would be greatly appreciated! Thanks ahead of time!
