Solved Port knock, jail, and 15.0-RELEASE problem

K

kjpetrie

When I start my desktop computer (not FreeBSD) it has a postfix instance to receive mail from my FreeBSD server machine which is always on. I want mail which is waiting to be delivered immediately so I can read it. I therefore have a start-up script in my desktop which knocks on a port in my server machine from a specific port on the desktop one.

The incoming postfix server on the FreeBSD machine runs in a jail, so I use pf to pass the knock on to the jail, and the jail uses a while loop running netcat to listen to the port and trigger a flush instruction to postfix.

After upgrading from 13.5-RELEASE to 15.0_RELEASE this has stopped working.

Here is the desktop script (with the ports munged):
Bash: 
#!/bin/bash

# fetch_mail - sends port knock to server to flush mail queue.

sleep 10
touch /tmp/fetch_called
if /bin/ping -c 1 mainserver > /dev/null; then
  /usr/bin/nc -zw 1 -p <nnnn> mainserver <mmmm>
  echo "knocked on mainserver." > /tmp/fetch_called
elif /bin/ping -c 1 backupserver > /dev/null; then
  /usr/bin/nc -zw 1 -p <nnnn> backupserver <mmmm>
  echo "knocked on backupserver." > /tmp/fetch_called
else
  echo "Neither machine could be reached." > /tmp/fetch_called
fi

Here is the pf rule on mainserver:
Code: 
rdr pass on $ext_if inet proto tcp from $SSH_FROM_ADDR port <nnnn> to port <mmmm> -> $MAIL_IN_ADDR port <mmmm>
and here is the crontab entry to run netcat in the jail:
Code: 
@reboot -n while true; do su -m postfix -c "netcat -lnzp <mmmm> 192.168.n.n <nnnn> && /u
sr/local/sbin/postqueue -f" ; done

How do I go about tracking down where the packet is getting stuck?
 
I've looked into it, but it's rather opaque. I can set postfix up to accept ETRN connections, but then I apparently need to use the insecure telnet to signal it manually to send my mail, and that telnet connection has to be to a process running inside a jail. I want something automatic when I start my computer, not an interactive session with the server. I expected the instructions at https://www.postfix.org/ETRN_README.html to end with how to configure the recipient postfix MTA to send the request at start-up, but it didn't. It just leaves telnet instructions. I can't see how that's better than SSH-ing into the server, suing to root and running ezjail-admin console to send a postqueue -f or similar, which is what I have to do while the port-knock isn't getting through.
 
it shouldn't be much work to write a small program to EHLO, STARTTLS, and ETRN to the mailserver when your network comes up. at worst, echo ETRN | openssl s_client -starttls smtp -connect host:port
 
That didn't work, but this seems better:
Bash: 
  /usr/bin/nc -c 'sleep 2;printf "ehlo desktop.localdomain\r\n";sleep 2;printf "etrn master\r\n";sleep 2;printf "quit\r\n"' server.localdomain 25
I know it's a bit crude in just waiting without reading the server's response, but all I want to do is give the server a kick to persuade it to flush.

That produced the following output in the mail log (addresses altered just in case for security):
Code: 
Mar  3 00:12:30 mailin postfix/smtpd[37335]: connect from desktop.localdomain[192.168.n.n]
Mar  3 00:12:36 mailin postfix/smtpd[37335]: disconnect from desktop.localdomain[192.168.n.n] ehlo=1 etrn=1 quit=1 commands=3
There was no queued mail but no errors were reported and we'll see what happens when mail is queued.
 
Turns out I haven't got relay_domains set - using virtual_alias_domains instead! Once I pointed fast_flush_domains to that it worked!

Thanks for all your help.
 
You must log in or register to reply here.
Back
Top