Hi all, having an issue with stunnel not routing any trafic; vpn works fine without stunnel, but if openvpn is connected via stunnel, I cannot ping anything at all?
Anyone come across this before?
- Are you saying that you establish an OpenVPN connection on top of a stunnel?
- If so, why?
1 Like
I have actually successfully done this -- it can be useful to bypass certain types of blocks such as the GFW of China.
@cantenna - can you provide more details, please?
- Do you control both ends of the setup (i.e. OpenVPN server on a device/service at a remote location and also your local client device)?
- Did you modify your OpenVPN config to account for the stunnel encapsulation?
Post your server and client configs (assuming both sides are OpenWrt):
/etc/config/stunnel
/etc/config/network
/etc/config/openvpn (or wherever your server side OpenVPN config is located)
/etc/config/firewall
2 Likes
Do you control both ends of the setup?
Yes
Did you modify your OpenVPN config to account for the stunnel encapsulation?
Don't think so... Don't recall see any mention of doing so anywhere either...
I have connected from both my Arch laptop and S8+ successfully.
On the android device, if I use ports other than 443 or 80 I get a "address already in use..." yet, I am still able to connect, just nothing routes. If I use ports 443 or 80 I don't get the "address already in use message but instead get a permission error for trying to bind to port 443 or port 80.
Also, here is my relevant system log entries;
Fri Oct 12 18:39:31 2018 daemon.notice stunnel: LOG5[ui]: stunnel 5.50 on arm-openwrt-linux-gnu platform
Fri Oct 12 18:39:31 2018 daemon.notice stunnel: LOG5[ui]: Compiled/running with OpenSSL 1.0.2p 14 Aug 2018
Fri Oct 12 18:39:31 2018 daemon.notice stunnel: LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI
Fri Oct 12 18:39:31 2018 daemon.notice stunnel: LOG5[ui]: Reading configuration from file /etc/stunnel/stunnel.conf
Fri Oct 12 18:39:31 2018 daemon.notice stunnel: LOG5[ui]: UTF-8 byte order mark not detected
Fri Oct 12 18:39:31 2018 daemon.notice stunnel: LOG5[ui]: FIPS mode disabled
Fri Oct 12 18:39:31 2018 daemon.notice stunnel: LOG5[ui]: Configuration successful
Fri Oct 12 18:39:31 2018 daemon.notice stunnel: LOG5[ui]: Binding service [cloudstunnel] to :::443: Address in use (98)
Fri Oct 12 18:39:31 2018 daemon.notice stunnel: LOG5[ui]: Switched to chroot directory: /stunnel/
BTW, thank you for the help.
###FIREWALL###
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
config rule
option target 'ACCEPT'
option name 'OpenVPN Server 3000 TCP'
option src '*'
option proto 'tcp'
option dest_port '3000'
config rule
option src 'lan'
option proto 'udp'
option dest_port '137-138'
option target 'ACCEPT'
config rule
option src 'lan'
option proto 'tcp'
option dest_port '139'
option target 'ACCEPT'
config rule
option src 'lan'
option proto 'tcp'
option dest_port '445'
option target 'ACCEPT'
config rule
option _name 'Don'\''t track NETBIOS Service'
option src 'lan'
option src_port '137-139'
option dest 'lan'
option target 'NOTRACK'
config rule
option _name 'Don'\''t track NETBIOS Service'
option src 'lan'
option dest 'lan'
option dest_port '137-139'
option target 'NOTRACK'
config rule
option _name 'Don'\''t track Windows Filesharing'
option src 'lan'
option src_port '445'
option dest 'lan'
option target 'NOTRACK'
config rule
option _name 'Don'\''t track Windows Filesharing'
option src 'lan'
option dest 'lan'
option dest_port '445'
option target 'NOTRACK'
config defaults
option syn_flood '1'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option disable_ipv6 '1'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option network 'lan'
config include
option path '/etc/firewall.user'
config include 'miniupnpd'
option type 'script'
option path '/usr/share/miniupnpd/firewall.include'
option family 'any'
option reload '1'
config forwarding
option dest 'wan'
option src 'lan'
###OPENVPNSERVCFG###
config openvpn 'cloudserv3000'
option keepalive '10 120'
option port '3000'
option cipher 'AES-256-CBC'
option client_to_client '1'
option verb '5'
option ca '/etc/luci-uploads/cbid.openvpn.cloudservtap3000.ca'
option key '/etc/luci-uploads/cbid.openvpn.cloudservtap3000.key'
option cert '/etc/luci-uploads/cbid.openvpn.cloudservtap3000.cert'
option dh '/etc/luci-uploads/cbid.openvpn.cloudservtap3000.dh'
option tls_auth '/etc/openvpn/tlsauth3000.key'
option key_direction '0'
option mode 'server'
option route_gateway '192.168.1.1'
option persist_tun '1'
option persist_key '1'
option mute_replay_warnings '1'
option tls_server '1'
option ifconfig_noexec '1'
option ifconfig_pool_persist '/tmp/ipp.txt'
list push 'dhcp-option DNS 192.168.1.1'
list push 'route 192.168.1.0 255.255.255.192'
list push 'redirect-gateway def1'
option dev 'tap0'
option server_bridge '192.168.1.1 255.255.255.192 192.168.1.51 192.168.1.62'
option proto 'tcp4'
option tun_mtu '1500'
option mssfix_max '1460'
option fast_io '1'
option client_config_dir '/etc/openvpn/ccd'
option enabled '1'
###STUNNELSERVCFG###
chroot = /stunnel/
pid = /stunnel.pid
options = NO_SSLv2
options = NO_SSLv3
setuid = nobody
setgid = nogroup
[cloudstunnel]
accept = 443
connect = 127.0.0.1:3000
verify = 2
cert = /etc/stunnel/cert-server.pem
key = /etc/stunnel/key-server.pem
CAfile = /etc/stunnel/cert-client.pem
###STUNNELCLIENTCFG###
[cloudstunnel]
client=yes
accept=127.0.0.1:3029
connect=192.168.1.1:443
cert=/etc/stunnel/cert-client.pem
key=/etc/stunnel/key-client.pem
###OPENVPNCLIENTCFG###
remote 127.0.0.1 3029
proto tcp
client
dev tap0
resolv-retry infinite
pull
nobind
persist-key
persist-tun
float
cipher AES-256-CBC
auth-nocache
remote-cert-tls server
verify-x509-name server name
tls-version-min 1.2
script-security 2
tun-mtu 1500
Have you successfully connected through OpenVPN (on its own, not using stunnel) from outside your network and proven that the OpenVPN configuration works properly (for LAN and/or internet access through the tunnel)?
I would do a bunch of stuff differently than you have (for example, I wouldn't use TAP). It is important to note that TAP is not supported on iOS and Android.
I see a lot of things in the OpenVPN configs (both sides) that just don't look right -- for example, you're mixing tap and tun directives, you've got odd bridging stuff going on, and so on.
All of that said, if your OpenVPN connection is actually working, then we can address stunnel issues...
It looks like your OpenVPN connection is listening on TCP 3000 and that you want stunnel listening on port 443 (from the outside).
On the server side, change your stunnel so that it is listening on port 443 and will connect to the OpenVPN server on port 3000. It should be changed as follows:
accept = 443
connect = 3000
You also need to update the firewall to include a rule that accepts port 443 (for stunnel)
On the client side, stunnel should look like this:
accept=3029
connect=<fqdn_or_ip-address_of_server>:443
Especially because of your TAP configuration, you need to test these things from outside your network (at another location or via cellular) or else you won't really know if it is connecting properly. In the client stunnel config, that also means that you need your external/public IP address or FQDN.
2 Likes
OpenVPN works fine without stunnel and the client app I use on Android supports TAP and tap functions as expected i.e. can rout samba and dlna.
Regarding mixing, you mean "option persist_tun '1'" & "persist-tun" yea, that was a mistake... :)
I am testing this from cellular with ddns as server ip, I just remove it for public posting.
Thanks for the advise will test and advise.
UPDATE: just got it working... with TUN! Long live TUN!!
Thanks guys
1 Like
@cantenna - I'm glad you got it working.
If you have a moment, please provide more details about what you changed -- this will be helpful for future readers of this thread.
Specifically, you mentioned that you changed to TUN -- was that the only change? Or did you also change the configs of the other components (stunnel, firewall, other OpenVPN settings)? Please be specific so that this thread can be used by others to troubleshoot/learn.
Thanks!
3 Likes
Hi psherman,
Stunnel works configured as stated above just fine although, one thing that tripped me up; in the logs across all platforms kept seeing "already binded." Being past tense, this led me to believe that it was trying to do something it couldn't because it had already been done... And when things weren't working, I spent a lot of time trying to do stunnel without this message...
Anyways, turns out that message can be ignored entirely. I think the intent of the dev there is to just say "binded" in present tense.
Other than that, I just followed the numerous vpn tun tutorials already available on google and openwrt including one that you helped out on regarding routing all traffic to across the vpn found here;
Other noteworthy mentioning which may help others;
-stunnel issues came down to a routing vpn issue.
-couldn't get it to work with TAP
-I used CCD
-I used topology
-And used proper firewall config to route all traffic over vpn
1 Like
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.