Jump to content


Photo

AirVPN Setup on OpenWRT router using LUCI


  • Please log in to reply
20 replies to this topic

#1 syncswim

syncswim

    Member

  • Members
  • PipPip
  • 29 posts

Posted 30 January 2014 - 03:39 PM

I need help setting up my openVPN client on OpenWRT using the Luci web-interface with the openVPN-luci-api installed. I'd much prefer to do it using Luci so I can go in and switch servers easily in the future.

 

I feel like I've already set up most of what's needed, and the client status is 'started', but I seem to have no TUN device, and don't really know where to go from here. If someone can help me get this going I'll be happy to put together a tutorial, as there doesn't seem to be one anywhere else.

 

I created and downloaded a ovpn file from AirVPN, along with certs etc, and uploaded these files to my client_tun (see screnshoots), then I copied all the settings from the ovpn file into the appropriate fields in the luci. At first my instance 'client_tun' started, but since I added all the settings from the ovpn file, it won't start.

 

Also, I currently have my linux server connecting via openvpn, and that connection goes through the router. I guess I should make my server connect normally (ie without openvpn/airvpn) before I continue to configure the router? Basically, because I now have an openwrt router, I want to put all my traffic through airvpn, just just the traffic from my server.

 

Please help!!

 

PS in the screenshots there's an instance 'client_tap_bridge', I did not create this, it seemed to appear automatically

2014-01-30%2016_15_22-OpenWrt%20-%20Open

 

2014-01-30%2016_16_36-OpenWrt%20-%20LuCI

 

2014-01-30%2016_15_50-OpenWrt%20-%20LuCI

 

2014-01-30%2016_18_37-OpenWrt%20-%20LuCI

 

2014-01-30%2016_16_57-OpenWrt%20-%20LuCI

 

2014-01-30%2016_16_10-OpenWrt%20-%20LuCI



#2 syncswim

syncswim

    Member

  • Members
  • PipPip
  • 29 posts

Posted 30 January 2014 - 06:01 PM

relevant log errors

 

Jan 30 18:59:35 OpenWrt daemon.notice openvpn(client_tun)[1636]: MANAGEMENT: TCP Socket listening on 127.0.0.1:31194
Jan 30 18:59:35 OpenWrt daemon.warn openvpn(client_tun)[1636]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Jan 30 18:59:35 OpenWrt daemon.warn openvpn(client_tun)[1636]: WARNING: file '/lib/uci/upload/cbid.openvpn.client_tun.key' is group or others accessible
Jan 30 18:59:35 OpenWrt daemon.notice openvpn(client_tun)[1636]: LZO compression initialized
Jan 30 18:59:35 OpenWrt daemon.notice openvpn(client_tun)[1636]: Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]
Jan 30 18:59:35 OpenWrt daemon.notice openvpn(client_tun)[1636]: Socket Buffers: R=[114688->131072] S=[114688->131072]
Jan 30 18:59:35 OpenWrt daemon.err openvpn(client_tun)[1636]: RESOLVE: Cannot resolve host address: gb.vpn.airdns.org:443: [HOST_NOT_FOUND] The specified host is unknown.
Jan 30 18:59:35 OpenWrt daemon.notice openvpn(client_tun)[1636]: Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
Jan 30 18:59:35 OpenWrt daemon.err openvpn(client_tun)[1636]: RESOLVE: Cannot resolve host address: gb.vpn.airdns.org:443: [HOST_NOT_FOUND] The specified host is unknown.
Jan 30 18:59:40 OpenWrt daemon.err openvpn(client_tun)[1636]: RESOLVE: Cannot resolve host address: gb.vpn.airdns.org:443: [HOST_NOT_FOUND] The specified host is unknown.
Jan 30 18:59:44 OpenWrt daemon.notice openvpn(client_tap_bridge)[1656]: OpenVPN 2.1.4 mips-openwrt-linux [SSL] [LZO2] [EPOLL] built on Nov 14 2011
Jan 30 18:59:44 OpenWrt daemon.err openvpn(client_tap_bridge)[1656]: MANAGEMENT: Socket bind failed on local address 127.0.0.1:31194: Address already in use
Jan 30 18:59:44 OpenWrt daemon.notice openvpn(client_tap_bridge)[1656]: Exiting
Jan 30 18:59:45 OpenWrt daemon.err openvpn(client_tun)[1636]: RESOLVE: Cannot resolve host address: gb.vpn.airdns.org:443: [HOST_NOT_FOUND] The specified host is unknown.
Jan 30 18:59:50 OpenWrt daemon.err openvpn(client_tun)[1636]: RESOLVE: Cannot resolve host address: gb.vpn.airdns.org:443: [HOST_NOT_FOUND] The specified host is unknown.
Jan 30 18:59:55 OpenWrt daemon.err openvpn(client_tun)[1636]: RESOLVE: Cannot resolve host address: gb.vpn.airdns.org:443: [HOST_NOT_FOUND] The specified host is unknown.
Jan 30 19:00:00 OpenWrt daemon.err openvpn(client_tun)[1636]: RESOLVE: Cannot resolve host address: gb.vpn.airdns.org:443: [HOST_NOT_FOUND] The specified host is unknown.
Jan 30 19:00:05 OpenWrt daemon.err openvpn(client_tun)[1636]: RESOLVE: Cannot resolve host address: gb.vpn.airdns.org:443: [HOST_NOT_FOUND] The specified host is unknown.


#3 Staff

Staff

    Advanced Member

  • Staff
  • PipPipPip
  • 7757 posts

Posted 30 January 2014 - 06:01 PM

Hello!

 

The destination port is wrong (currently set to 1194). Please set it to 443 or 80 or 53.

 

The server IP/name is wrong, there's a ":443" string that must be deleted.

 

We don't know exactly how your device handles "reneg_sec" to renegotiate Data Channel key, i.e. the meaning of "0". By default our servers are configured to renegotiate every 3600 seconds (1 hour). Therefore: if "0" disables this feature, you had better set "3600" otherwise you will lose Perfect Forward Secrecy. Your are free to set lower values to force our servers to perform re-keying more often, but you can NOT set higher values, otherwise you will lose connections after 1 hour because our server will want to change encryption key anyway.

 

Last but not least, your device can't resolve gb.vpn.airdns.org (but that should be due to the wrong name, ":443"), please check your device DNS or insert directly an IP address of a server in place of the name gb.vpn.airdns.org if the problem is not solved after you delete that ":443"

 

Kind regards



#4 syncswim

syncswim

    Member

  • Members
  • PipPip
  • 29 posts

Posted 30 January 2014 - 06:09 PM

seems like it's working, but where to go from here?

 

Jan 30 19:06:41 OpenWrt daemon.err openvpn(client_tun)[2281]: event_wait : Interrupted system call (code=4)
Jan 30 19:06:41 OpenWrt daemon.notice openvpn(client_tun)[2281]: TCP/UDP: Closing socket
Jan 30 19:06:41 OpenWrt daemon.notice openvpn(client_tun)[2281]: SIGTERM[hard,] received, process exiting
Jan 30 19:06:45 OpenWrt daemon.notice openvpn(client_tun)[2495]: OpenVPN 2.1.4 mips-openwrt-linux [SSL] [LZO2] [EPOLL] built on Nov 14 2011
Jan 30 19:06:45 OpenWrt daemon.notice openvpn(client_tun)[2495]: MANAGEMENT: TCP Socket listening on 127.0.0.1:31194
Jan 30 19:06:45 OpenWrt daemon.warn openvpn(client_tun)[2495]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Jan 30 19:06:45 OpenWrt daemon.warn openvpn(client_tun)[2495]: WARNING: file '/lib/uci/upload/cbid.openvpn.client_tun.key' is group or others accessible
Jan 30 19:06:45 OpenWrt daemon.notice openvpn(client_tun)[2495]: LZO compression initialized
Jan 30 19:06:45 OpenWrt daemon.notice openvpn(client_tun)[2495]: Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]
Jan 30 19:06:45 OpenWrt daemon.notice openvpn(client_tun)[2495]: Socket Buffers: R=[114688->131072] S=[114688->131072]
Jan 30 19:06:45 OpenWrt daemon.notice openvpn(client_tun)[2495]: Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
Jan 30 19:06:45 OpenWrt daemon.notice openvpn(client_tun)[2495]: UDPv4 link local: [undef]
Jan 30 19:06:45 OpenWrt daemon.notice openvpn(client_tun)[2495]: UDPv4 link remote: 78.129.153.40:443
Jan 30 19:06:45 OpenWrt daemon.notice openvpn(client_tun)[2495]: TLS: Initial packet from 78.129.153.40:443, sid=23f95931 d58a53ef
Jan 30 19:06:45 OpenWrt daemon.notice openvpn(client_tun)[2495]: VERIFY OK: depth=1, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=airvpn.org_CA/emailAddress=info@airvpn.org
Jan 30 19:06:45 OpenWrt daemon.notice openvpn(client_tun)[2495]: VERIFY OK: nsCertType=SERVER
Jan 30 19:06:45 OpenWrt daemon.notice openvpn(client_tun)[2495]: Validating certificate key usage
Jan 30 19:06:45 OpenWrt daemon.notice openvpn(client_tun)[2495]: ++ Certificate has key usage  00a0, expects 00a0
Jan 30 19:06:45 OpenWrt daemon.notice openvpn(client_tun)[2495]: VERIFY KU OK
Jan 30 19:06:45 OpenWrt daemon.notice openvpn(client_tun)[2495]: Validating certificate extended key usage
Jan 30 19:06:45 OpenWrt daemon.notice openvpn(client_tun)[2495]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Jan 30 19:06:45 OpenWrt daemon.notice openvpn(client_tun)[2495]: VERIFY EKU OK
Jan 30 19:06:45 OpenWrt daemon.notice openvpn(client_tun)[2495]: VERIFY OK: depth=0, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=server/emailAddress=info@airvpn.org
Jan 30 19:06:48 OpenWrt daemon.notice openvpn(client_tun)[2495]: Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Jan 30 19:06:48 OpenWrt daemon.notice openvpn(client_tun)[2495]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jan 30 19:06:48 OpenWrt daemon.notice openvpn(client_tun)[2495]: Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Jan 30 19:06:48 OpenWrt daemon.notice openvpn(client_tun)[2495]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jan 30 19:06:48 OpenWrt daemon.notice openvpn(client_tun)[2495]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Jan 30 19:06:48 OpenWrt daemon.notice openvpn(client_tun)[2495]: [server] Peer Connection Initiated with 78.129.153.40:443


#5 syncswim

syncswim

    Member

  • Members
  • PipPip
  • 29 posts

Posted 30 January 2014 - 06:16 PM

Thanks! Once I put the port in the right place, and fixed  the log errors, it started  smoothly, but shouldn't I have a TUN device somewhere? I currently have no idea how to get all or some traffic through the VPN..



#6 Staff

Staff

    Advanced Member

  • Staff
  • PipPipPip
  • 7757 posts

Posted 30 January 2014 - 07:20 PM

Hello,

 

can you please publish the output of the commands "ifconfig" and "route -n" (after the connection has been established)?

 

Kind regards



#7 syncswim

syncswim

    Member

  • Members
  • PipPip
  • 29 posts

Posted 30 January 2014 - 09:39 PM

hmm, I'm not sure what, if anything, changed since earlier, but it now seems to connect, but actually doesn't

 

OpenVPN 2.1.4 mips-openwrt-linux [SSL] [LZO2] [EPOLL] built on Nov 14 2011
Jan 30 22:34:02 OpenWrt daemon.notice openvpn(client_tun)[4684]: MANAGEMENT: TCP Socket listening on 127.0.0.1:31194
Jan 30 22:34:02 OpenWrt daemon.warn openvpn(client_tun)[4684]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Jan 30 22:34:02 OpenWrt daemon.warn openvpn(client_tun)[4684]: WARNING: file '/lib/uci/upload/cbid.openvpn.client_tun.key' is group or others accessible
Jan 30 22:34:02 OpenWrt daemon.notice openvpn(client_tun)[4684]: LZO compression initialized
Jan 30 22:34:02 OpenWrt daemon.notice openvpn(client_tun)[4684]: Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]
Jan 30 22:34:02 OpenWrt daemon.notice openvpn(client_tun)[4684]: Socket Buffers: R=[114688->131072] S=[114688->131072]
Jan 30 22:34:02 OpenWrt daemon.notice openvpn(client_tun)[4684]: Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
Jan 30 22:34:02 OpenWrt daemon.notice openvpn(client_tun)[4684]: UDPv4 link local: [undef]
Jan 30 22:34:02 OpenWrt daemon.notice openvpn(client_tun)[4684]: UDPv4 link remote: 78.129.153.40:443
Jan 30 22:34:02 OpenWrt daemon.notice openvpn(client_tun)[4684]: TLS: Initial packet from 78.129.153.40:443, sid=361eeae2 0c51e064
Jan 30 22:34:03 OpenWrt daemon.notice openvpn(client_tun)[4684]: VERIFY OK: depth=1, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=airvpn.org_CA/emailAddress=info@airvpn.org
Jan 30 22:34:03 OpenWrt daemon.notice openvpn(client_tun)[4684]: VERIFY OK: nsCertType=SERVER
Jan 30 22:34:03 OpenWrt daemon.notice openvpn(client_tun)[4684]: Validating certificate key usage
Jan 30 22:34:03 OpenWrt daemon.notice openvpn(client_tun)[4684]: ++ Certificate has key usage  00a0, expects 00a0
Jan 30 22:34:03 OpenWrt daemon.notice openvpn(client_tun)[4684]: VERIFY KU OK
Jan 30 22:34:03 OpenWrt daemon.notice openvpn(client_tun)[4684]: Validating certificate extended key usage
Jan 30 22:34:03 OpenWrt daemon.notice openvpn(client_tun)[4684]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Jan 30 22:34:03 OpenWrt daemon.notice openvpn(client_tun)[4684]: VERIFY EKU OK
Jan 30 22:34:03 OpenWrt daemon.notice openvpn(client_tun)[4684]: VERIFY OK: depth=0, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=server/emailAddress=info@airvpn.org
Jan 30 22:34:05 OpenWrt daemon.notice openvpn(client_tun)[4684]: Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Jan 30 22:34:05 OpenWrt daemon.notice openvpn(client_tun)[4684]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jan 30 22:34:05 OpenWrt daemon.notice openvpn(client_tun)[4684]: Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Jan 30 22:34:05 OpenWrt daemon.notice openvpn(client_tun)[4684]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jan 30 22:34:05 OpenWrt daemon.notice openvpn(client_tun)[4684]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Jan 30 22:34:05 OpenWrt daemon.notice openvpn(client_tun)[4684]: [server] Peer Connection Initiated with 78.129.153.40:443
Jan 30 22:34:08 OpenWrt daemon.notice openvpn(client_tun)[4684]: SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Jan 30 22:34:08 OpenWrt daemon.notice openvpn(client_tun)[4684]: AUTH: Received AUTH_FAILED control message
Jan 30 22:34:08 OpenWrt daemon.notice openvpn(client_tun)[4684]: TCP/UDP: Closing socket
Jan 30 22:34:08 OpenWrt daemon.notice openvpn(client_tun)[4684]: SIGTERM[soft,auth-failure] received, process exiting

Could this be because my other machine is already connected to your service, albeit through a different server? I'm loathe to disable the VPN on my other machine until I have to, because it'll mean that my externally available services (Webserver, etc) will not be on the ports I've remapped them to in airvpn admin, and therefore will be unavailable..



#8 Staff

Staff

    Advanced Member

  • Staff
  • PipPipPip
  • 7757 posts

Posted 30 January 2014 - 09:43 PM

Hello!

 

Each account can establish ONE concurrent connection.

 

EDIT: since April 2014, each account can establish THREE concurrent connections.

 

Kind regards



#9 syncswim

syncswim

    Member

  • Members
  • PipPip
  • 29 posts

Posted 30 January 2014 - 10:15 PM

ahh, indeed my client area says 
 
"Last attempted connection failed 15m 2s ago. Reason: Already logged on 'Tauri'."
 
Pretty clear :) Now that I've disabled openvpn on my server, my router connects ok.
 
ifconfig:
 
br-lan    Link encap:Ethernet  HWaddr B0:48:7A:D1:31:D2
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5295371 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5565372 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3661035583 (3.4 GiB)  TX bytes:452566246 (431.6 MiB)

eth0      Link encap:Ethernet  HWaddr B0:48:7A:D1:31:D2
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10817103 errors:0 dropped:0 overruns:93533 frame:0
          TX packets:10620761 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:4209262948 (3.9 GiB)  TX bytes:4028225629 (3.7 GiB)
          Interrupt:4

eth0.1    Link encap:Ethernet  HWaddr B0:48:7A:D1:31:D2
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5152309 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5388536 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3658265503 (3.4 GiB)  TX bytes:281950694 (268.8 MiB)

eth0.2    Link encap:Ethernet  HWaddr B0:48:7A:D1:31:D2
          inet addr:89.78.239.155  Bcast:255.255.255.255  Mask:255.255.252.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5664302 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5232204 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:399490080 (380.9 MiB)  TX bytes:3746272153 (3.4 GiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:5827 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5827 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:404994 (395.5 KiB)  TX bytes:404994 (395.5 KiB)

mon.wlan0 Link encap:UNSPEC  HWaddr B0-48-7A-D1-31-D2-00-00-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:228449 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:30843458 (29.4 MiB)  TX bytes:0 (0.0 B)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.4.63.46  P-t-P:10.4.63.45  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:1 errors:0 dropped:0 overruns:0 frame:0
          TX packets:179 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:265 (265.0 B)  TX bytes:46763 (45.6 KiB)

wlan0     Link encap:Ethernet  HWaddr B0:48:7A:D1:31:D2
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:147369 errors:0 dropped:0 overruns:0 frame:0
          TX packets:239630 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:26007295 (24.8 MiB)  TX bytes:207526924 (197.9 MiB)

route -n 

 

route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.4.49.33      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
78.129.153.40   89.78.236.1     255.255.255.255 UGH   0      0        0 eth0.2
10.4.0.1        10.4.49.33      255.255.255.255 UGH   0      0        0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan
89.78.236.0     0.0.0.0         255.255.252.0   U     0      0        0 eth0.2
0.0.0.0         10.4.49.33      128.0.0.0       UG    0      0        0 tun0
128.0.0.0       10.4.49.33      128.0.0.0       UG    0      0        0 tun0
0.0.0.0         89.78.236.1     0.0.0.0         UG    0      0        0 eth0.2

I lose all internet connectivity when the VPN is up, but it's definitely working. I don't want to waste your time as it's probably explained somewhere how to get it going. For now it would be ok just to have all traffic going through the VPN. This is all a bit beyond me, but I'm guessing I need to bridge tun0 somehow to something? :)



#10 zhang888

zhang888

    Donald Trump of IT/Security

  • Moderators
  • 2219 posts

Posted 30 January 2014 - 10:59 PM

You can try the following command :

 

/usr/sbin/iptables -t nat -A POSTROUTING -o tun+ -j SNAT --to-source $(ifconfig tun0 | grep "inet addr" | awk -F: '{print $2}' | awk '{print $1}')

 

It should work perfectly on any OpenWRT based router.

 

 

I had to make it work this way since AirVPN assigns dynamic IPs on each server, so this command, if entered after the VPN session, will read the correct internal IP of the tun0 interface and then create a firewall rule

to push all the traffic there.

 

 

I didn't find any other way of doing this before, so in case there is more elegant solution, please wait for an official reply from Staff.


Occasional moderator, sometimes BOFH. Opinions are my own, except when my wife disagrees.


#11 Staff

Staff

    Advanced Member

  • Staff
  • PipPipPip
  • 7757 posts

Posted 31 January 2014 - 02:17 AM

@zhang888

 

Hello,

 

your solution is extraordinarily elegant, congratulations. It does not seem related to syncswim problem, though... can you please elaborate? This information can be precious for every OpenWRT user. Why is it necessary on OpenWRT, are there cases for which the VPN server routes push is not processed correctly by an OpenWRT router?

 

EDIT: ok, we see the problem. Does it occur "usually" on OpenWRT?

 

Kind regards



#12 zhang888

zhang888

    Donald Trump of IT/Security

  • Moderators
  • 2219 posts

Posted 31 January 2014 - 02:32 AM

Dear Staff,

I am familiar with his issue since I am an OpenWRT user since many years :)

 

After that iptables command, he will be able to set tun0 as default gateway.


Occasional moderator, sometimes BOFH. Opinions are my own, except when my wife disagrees.


#13 syncswim

syncswim

    Member

  • Members
  • PipPip
  • 29 posts

Posted 31 January 2014 - 08:43 AM

Firstly, thanks guys for your great help!

 

Please excuse my ignorance, but I have a few questions about what's been said.

 

1) Are you saying that there definitely IS a problem with openWRT, in terms of the fact that it does not (or cannot) properly process the server details pushed from the server upon connection to the VPN? Would this be all VPNs, or is the problem specific to AirVPN?

 

2) Zhang888 says AirVPN assigns dynamic IPs on each server'. This I understand, however my previous connections to airvpn (Always to the same server) were always made from my debian box, and actually the IP address I received was always the same, over many many reboots over a year or more. EDIT: Actually I see we're talking about 2 IPs. One for the server and one for tun0, both of which are dynamic. (ALthough again, I'm quite sure the tun- ip on my debian box was always the same).

 

3) If the command suggested by Zhang888 is the only way to make airvpn work with openwrt, it will have to be run after each connection, obviously? How would I make this happen automatically using LUCI? It's not that I'm scared of using the command line (but not very competent), it's more that I want easy control from Luci, and also don't really know what the consequences of combining settings made in Luci with settings made elsewhere wouyld be.

 

4) From my (probably naive) perspective, wouldn't it be possible to define my tun0 permanently and independently of openvpn, with a fixed IP, then simply have openvpn use that to connect to the server? That way tun0 would have the same IP forever.



#14 syncswim

syncswim

    Member

  • Members
  • PipPip
  • 29 posts

Posted 31 January 2014 - 09:14 AM

For instance, using Luci, I connected the VPN, then created a new interface and selected tun0.

 

2014-01-31%2010_09_21-OpenWrt%20-%20Inte

 

 

it seems to be working as it shows it is sending and receiving packets. 

 

Then I disconnected and reconnected the VPN, and tun0 still seemed to be working. Can I proceed this way?



#15 syncswim

syncswim

    Member

  • Members
  • PipPip
  • 29 posts

Posted 31 January 2014 - 09:55 AM

A further update :)

 

Having configured a new firewall rule as per http://wiki.openwrt.org/doc/howto/vpn.client.openvpn.tun I seem to be up and running, but I haven't used the iptables command suggested above.

 

My airvpn status page shows me as connected to Naos server with IP 84.39.117.56. What's my IP shows the same ip when accessed from the win7 machine behind the router, and iplocation.net shows me as in the UK (actually I'm not in the UK).



#16 syncswim

syncswim

    Member

  • Members
  • PipPip
  • 29 posts

Posted 31 January 2014 - 09:58 AM

however after reboot I lose tun0 and the vpn service does not start..



#17 zhang888

zhang888

    Donald Trump of IT/Security

  • Moderators
  • 2219 posts

Posted 31 January 2014 - 11:48 AM

Hi syncswim,

 

1) Are you saying that there definitely IS a problem with openWRT, in terms of the fact that it does not (or cannot) properly process the server details pushed from the server upon connection to the VPN? Would this be all VPNs, or is the problem specific to AirVPN?

 

There are absolutely no "problem" with OpenWRT, at least not something about the software. The problem is more the great amount of varoius and different documentations and howto's.

For instance, the package luci-app-openvpn is broken on all trunks since 2013, because the package "openvpn" is not available anymore and a metapackage called "openvpn-nossl", "openvpn-polarssl" and "openvpn-openssl".

 

luci-app-openvpn depends on "openvpn" which is not called the same way anymore, so without recompiling the package it will not work on newer releases.

 

Here is the duscussion : http://luci.subsignal.org/trac/ticket/489

 

2) Zhang888 says AirVPN assigns dynamic IPs on each server'. This I understand, however my previous connections to airvpn (Always to the same server) were always made from my debian box, and actually the IP address I received was always the same, over many many reboots over a year or more. EDIT: Actually I see we're talking about 2 IPs. One for the server and one for tun0, both of which are dynamic. (ALthough again, I'm quite sure the tun- ip on my debian box was always the same).

 

AirVPN assign dynamic IPs for each server. If you stay on the same server and just reconnect it might still be the same, but it will be easier to just create a rule that will treat the IP as a variable.

I see it as a very big privacy enhancement, and while it was probably easier to assign a static IP per server ^ per customer, but AirVPN chose a very effective IP scheming, for example 10.4.x for port 443, 10.8.xx for 53 etc.

A firewall rule should solve that.

 

3) If the command suggested by Zhang888 is the only way to make airvpn work with openwrt, it will have to be run after each connection, obviously? How would I make this happen automatically using LUCI? It's not that I'm scared of using the command line (but not very competent), it's more that I want easy control from Luci, and also don't really know what the consequences of combining settings made in Luci with settings made elsewhere wouyld be.

 

Definitlly there must be more ways. The thing is, if you do it with Luci - other things might break, so you would probably prefer to know what is going on and do it manually.

You don't have to manually initiate it, just add it to /etc/rc.local, so it will start on each boot.

There are more advantages - you can delete the previous default route, so that if your openvpn connection drop, no traffic will leak and pass on the eth0.2 interface.

 

4) From my (probably naive) perspective, wouldn't it be possible to define my tun0 permanently and independently of openvpn, with a fixed IP, then simply have openvpn use that to connect to the server? That way tun0 would have the same IP forever.

 

I don't think you can control the IP that the server assigns you. It would be better to ask the server for one and to add an iptables rule.

 

 

 

 

 

To summarize, you probbably want to put something like that in your /etc/rc.local:

 

#Start openvpn
openvpn --config /root/openvpn.conf &

#Wait until tun0 becomes available

tunup=0
while [ $tunup ]
do
        echo "Checking tun0..."
        sleep 1
        if ifconfig tun0
        then

##Add iptables rule to the internal IP we got from our VPN
/usr/sbin/iptables -t nat -A POSTROUTING -o tun+ -j SNAT --to-source $(ifconfig tun0 | grep "inet addr" | awk -F: '{print $2}' | awk '{print $1}')

##Drop all traffic in case openvpn gets disconnected in order to prevent leaks
/sbin/route del -net 0.0.0.0 netmask 0.0.0.0 dev eth0.2
                tunup=1
                break
        fi
done

exit 0

Occasional moderator, sometimes BOFH. Opinions are my own, except when my wife disagrees.


#18 Staff

Staff

    Advanced Member

  • Staff
  • PipPipPip
  • 7757 posts

Posted 31 January 2014 - 01:35 PM

@syncswim

 

Just a clarification because it seems there's a little confusion about IP addresses. The IP address of your node in the VPN is DHCP-pushed and it is dynamic and private, see also https://airvpn.org/specs . To be more precise a client tun interface is (with Air configuration) a point-to-point device in a /30 subnet. The IP address on the Internet your packets appear to be coming from is the VPN server exit-IP address (your node is behind a NAT) which is always the same (it is changed only under exceptional circumstances).

 

Kind regards



#19 syncswim

syncswim

    Member

  • Members
  • PipPip
  • 29 posts

Posted 31 January 2014 - 03:49 PM

Thanks again for everyone's help.

 

To summarise, it seems that the final situation is this:

 

Although the openvpn-luci-app for openwrt's luci interface does seem to work ok for me, because of the nature of airvpn I cannot use it to set up a persistant connection without also implementing the /etc/rc.local script above?

 

This is because the tun0 device is created by settings pushed from airvpn, and it has to be this way because of the dynamic ip. Therefore, trying to assign firewall rules etc to an existing tun0 will not work.

 

If the above is generally correct, then even if I don't exactly understand all the technical details, I basically understand the situation and how to resolve it. Thanks again zhang for helping out. I will try this solution and report back.

 

My last question concerns routing only certain types of traffic, or traffic from particular devices through the VPN. I don't really want all traffic to be stopped if the connection drops, because then I will lose all internet connectivity. Actually there are 2-3 devices on my local network that should have their traffic routed through the VPN. Currently only my server connects through the vpn, and I would like to extend this to my media centre so I can access certain geo restricted services, and give up my subscription with unblockus.



#20 herbert.groff

herbert.groff

    Newbie

  • Members
  • Pip
  • 1 posts

Posted 17 April 2015 - 06:42 AM

Any news on this one? I can connect from to AirVPN from my little TP-Link router - a traceroute shows that it is working. But non of the WIFI traffic is routed over tun0. The above commands do not work to redirect the traffic.. any suggestions?







Similar Topics Collapse

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

Servers online. Online Sessions: 13793 - BW: 44323 Mbit/sYour IP: 54.205.211.87Guest Access.