2

I have the following stunnel config on the server:

chroot = /var/run/stunnel
setuid = nobody
setgid = nobody

pid = /stunnel.pid

cert = /etc/stunnel/stunnel.pem
key = /etc/stunnel/stunnel.pem
client = no

[https]
accept = 443
connect = 10051

The client:

chroot = /var/run/stunnel
setuid = nobody
setgid = nobody

pid = /stunnel.pid

cert = /etc/stunnel/stunnel.pem
key = /etc/stunnel/stunnel.pem
client = yes

[https]
accept = 127.0.0.1:10051
connect = 10.0.10.116:443

When I run 'sudo stunnel' on each machine I get no errors. Running the following commands on the client to test the tunnel, I get nothing?

tcpdump port 10051 -n -vvvv

followed by:

echo "blah" > nc localhost 10051

Am I misusing 'tcpdump'? Is there another way to test this? I am using Centos 7. The server Ip address is 10.0.10.116 and the client ip address is 10.0.10.27, this is a test lab setup with self signed certificates.

I should add that if I issue the tcpdump command above with a sudo:

sudo tcpdump port 10051 -n -vvvv

I get the following and then nothing:

tcpdump: NFLOG link-layer type filtering not implemented

Not sure what this is telling me?

Charles Bunn
  • 66
  • 2
  • 6
  • Is this same the question as https://unix.stackexchange.com/questions/394849/stunnel-error-cannot-open-log-file but asked in a different way? Do you (still) need both questions? – roaima Sep 29 '17 at 13:47
  • 1
    Two different issues. The log file was needed for debugging but even when I send it to the foreground it doesn't help. I see nothing from tcpdump when trying to verify that the tunnel is actually working. So first question was to get log file working in background and second is to actually test stunell and make sure the tunnel is working. I now have the first one solved thanks to everyones help but tcpdump is still an issue. – Charles Bunn Sep 29 '17 at 14:07
  • Okay I have made some progress. I scraped the Centos setup as a test and setup two identical Ubuntu servers. I put the above configuration files on the the server and client and now tcpdump replies back 'tcpdump: listening on enp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes' and looks like it is awaiting input. The tried entering the echo command on both the client and server but nothing more happens. I am typing the tcpdump command on the client. Should tcpdump be listening on the Ethernet card or the localhost? – Charles Bunn Oct 03 '17 at 18:52
  • Uh, `echo "blah" > nc localhost 10051` writes `blah localhost 10051` to the _file_ called `nc` – roaima Jan 04 '22 at 23:16
  • I’m voting to close this question because "Typo/Can't be reproduced", see last edit of self-answer - he had forgotten to turn off the firewalling for the port in question. – tink Sep 15 '22 at 22:26

2 Answers2

1

Okay I got it to work with some tweeks. Instead of using tcpdump I decided to try ssh. So I changed the connect on the server to:

...
[https]
accept =  443
connect = 22
...

then I typed

ssh localhost -p 10051

and got back

chuck@scorch:~$ ssh chuck@localhost -p 10051
The authenticity of host '[localhost]:10051 ([127.0.0.1]:10051)' can't be 
established.
ECDSA key fingerprint is SHA256:DcEUrtP7I5KJqaZIfsTK+2lNB8AF00Je97z9obNneac.
Are you sure you want to continue connecting (yes/no)? y
Please type 'yes' or 'no': yes
Warning: Permanently added '[localhost]:10051' (ECDSA) to the list of known 
hosts.
chuck@localhost's password:
Welcome to Ubuntu 17.04 (GNU/Linux 4.10.0-19-generic x86_64)
 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage
 * What are your preferred Linux desktop apps?  Help us set the default
desktop apps in Ubuntu 18.04 LTS:
- https://ubu.one/apps1804

11 packages can be updated.
8 updates are security updates.


Last login: Tue Oct  3 15:36:24 2017 from 10.0.10.60
chuck@ion:~$

Notice the login now says 'ion', I am on the server via ssh ported vis https. The log shows

2017.10.03 15:38:00 LOG7[0]: Service [https] started
2017.10.03 15:38:00 LOG7[0]: Option TCP_NODELAY set on local socket
2017.10.03 15:38:00 LOG5[0]: Service [https] accepted connection from   
10.0.10.27:36976
2017.10.03 15:38:00 LOG6[0]: Peer certificate not required
2017.10.03 15:38:00 LOG7[0]: TLS state (accept): before/accept 
initialization
2017.10.03 15:38:00 LOG7[0]: Get session callback
2017.10.03 15:38:00 LOG7[0]: SNI: no virtual services defined
2017.10.03 15:38:00 LOG7[0]: New session callback
2017.10.03 15:38:00 LOG7[0]:      1 server accept(s) requested
2017.10.03 15:38:00 LOG7[0]:      1 server accept(s) succeeded
2017.10.03 15:38:00 LOG7[0]:      0 server renegotiation(s) requested
2017.10.03 15:38:00 LOG7[0]:      0 session reuse(s)
2017.10.03 15:38:00 LOG7[0]:      0 internal session cache item(s)
2017.10.03 15:38:00 LOG7[0]:      0 internal session cache fill-up(s)
2017.10.03 15:38:00 LOG7[0]:      1 internal session cache miss(es)
2017.10.03 15:38:00 LOG7[0]:      0 external session cache hit(s)
2017.10.03 15:38:00 LOG7[0]:      0 expired session(s) retrieved
2017.10.03 15:38:00 LOG6[0]: TLS accepted: new session negotiated
2017.10.03 15:38:00 LOG6[0]: No peer certificate received
2017.10.03 15:38:00 LOG6[0]: Negotiated TLSv1.2 ciphersuite ECDHE-RSA-
AES256-GCM-SHA384 (256-bit encryption)
2017.10.03 15:38:00 LOG7[0]: Compression: null, expansion: null
2017.10.03 15:38:00 LOG6[0]: failover: round-robin, starting at entry #1
2017.10.03 15:38:00 LOG6[0]: s_connect: connecting 127.0.0.1:22
2017.10.03 15:38:00 LOG7[0]: s_connect: s_poll_wait 127.0.0.1:22: waiting 10 
seconds
2017.10.03 15:38:00 LOG5[0]: s_connect: connected 127.0.0.1:22
2017.10.03 15:38:00 LOG6[0]: persistence: 127.0.0.1:22 cached
2017.10.03 15:38:00 LOG5[0]: Service [https] connected remote server from 
127.0.0.1:54818
2017.10.03 15:38:00 LOG7[0]: Option TCP_NODELAY set on remote socket
2017.10.03 15:38:00 LOG7[0]: Remote descriptor (FD=9) initialized

So I know it works on Ubuntu. I noticed during the install of stunnel it automatically created an 'stunnel4' user, group and service. So I guess I need to try that on Centos and see what happens.

I finally got it to work on Centos. It turns out I thought I had turned the firewall off but I had not. Adding the appropriate ports to the firewall fixed the problem. However I still cannot get tcpdump to work...

Charles Bunn
  • 66
  • 2
  • 6
1

What if try tcpdump with '-i lo' to snif on loopback interface:

tcpdump -i lo -n -v port 10051
tonioc
  • 2,019
  • 13
  • 12