Yes, I know, you'd think this would be simple. Configure libreswan, establish the tunnel and either mount the smb share or "get" your file using smbclient. Unfortunately, it isn't that simple if you're using a NAT'ed ipsec tunnel as required by your remote endpoint. Since my peer address is on eth0 and my (assigned) NAT'ed address is on tunl0, that creates a slight problem when using smbclient. I attempted to use the interfaces="tunl0=eth0" option in ipsec.conf, but it did not behave as expected. Maybe the "interfaces" option isn't supposed to function like I thought it would, nevertheless, with the tunnel running my problem was now that I couldn't use smbclient.
Why can't you use smbclient, you ask? Well, I needed to connect to the remote party's server and smb share. However, you cannot tell smbclient which interface to use like you can with ping. I was able to confirm connectivity to the remote server via the tunnel by issuing the following in my shell:
$ ping -I tunl0 123.45.67.89
After a few hours of crawling through Google results using different search queries, I decided to develop my own solution. I knew about socat (netcat++) but had never used it; this seemed to be the perfect solution. After some reading and tinkering, I came up with the following command:
$ socat -d -d \
TCP4-LISTEN:139,bind=localhost,reuseaddr \
TCP4:123.45.67.89:139,bind=172.16.100.1
Let's break this down a bit ...
socat -d -d
This tells socat to run and print messages that are fatal, error, warning, or notice.
TCP4-LISTEN:139,bind=localhost,reuseaddr
This portion of the command tells socat to start listening for TCP/IPv4 connections on localhost at port 139. The "reuseaddr" option tells socat to let other sockets bind to the address even if only part of it is being used (i.e., the port we're listening on).
TCP4:123.45.67.89:139,bind=172.16.100.1
The last portion of the command tells socat to proxy TCP/IPv4 connections to port 139 on the remote system. The "bind" option tells socat to use the NAT'ed address that we've assigned to the device tunl0.
With the first half of the problem resolved, I was able to begin using smbclient to connect to the remote Windows server. Since I was going to ultimately script the whole process, I developed the following command using smbclient:
$ smbclient //PDC01/private \
-I 127.0.0.1 \
-U PDC\\MyUser%pass123 \
-c "get thisfile.txt /tmp/thisfile.txt"
Again, let's break this down a bit ...
smbclient //PDC01/private
This starts smbclient and tells it to connect to the smb share "private" on the Windows server named "PDC01".
-I 127.0.0.1
This tells smbclient to connect to 127.0.0.1 (localhost) where we're running our socat proxy.
-U PDC\\MyUser%pass123
This identifies our credentials; since Windows accounts are in the format "NT-Domain\UserName" we have to escape the forward slash, hence the "\\". To include a password for scripting purposes, we separate the account and password with a percent sign.
-c "get thisfile.txt /tmp/thisfile.txt"
This passes the above command to smbclient. Simply, we tell it what remote file to download and the location of where we want to save it.
After the file transfer completes, socat will detect that the TCP session has ended and thus shutdown nicely. With that, we have our solution; I hope this helps anyone that may encounter a similar situation.
If you would like to read more about socat, libreswan or samba, here are their respective websites:
socat: http://www.dest-unreach.org/socat/
libreswan: https://www.libreswan.org/
samba: http://www.samba.org/
Until next time ...
