Re: pf changes port on udp nat-to and rdr-to reply packets (RTP stream)
Because of this "Remember that static-port means you can't have two
machines behind the same NAT using the same source port and destination.",
you should instead probably use "binat-to" as a good practice.
This will help force you to not be able to accidentally reuse the same
public IP for another internal server.
SIP uses a lot of ports, and so it really does need its own public IP with
a one to one mapping to the private IP.
If you have remote SIP phone clients that need to run over the gateway too
(not just a SIP trunk), the following helped us keep client
registrations alive;
set timeout { udp.first 1200, udp.single 600, udp.multiple 1800 }
Cheers, Andy.
On Thu, Jun 9, 2016 at 11:40 PM, Stuart Henderson
wrote:
> On 2016-06-09, Markus Wernig wrote:
> > On 06/09/2016 08:03 PM, Bryan Vyhmeister wrote:
> >> On Thu, Jun 9, 2016, at 10:48 AM, Markus Wernig wrote:
> >>> Short question:
> >>> How do I prevent pf from changing the source port of outgoing natted
> udp
> >>> packets?
> >>
> >> Did you look at static-port in pf.conf(5)?
> >
> > Argh! I had overlooked that. Shame. Works now.
>
> Remember that static-port means you can't have two machines behind
> the same NAT using the same source port and destination.
>
> If it's OK to change the source port as long as it ends up within
> a certain port range, you can do something like 'nat-to $address port
> 8000:9000'.
>
>
--
*Download our latest free guide here
Re: /usr/ and wxallowed
On Thu, Jun 09, 2016 at 08:45:25PM +0100, Kevin Chadwick wrote: > Yep, I have no idea why someone wouldn't. I like having nosuid > on less trusted /usr/local. > > It pretty much removes the need to do the security technique of find > suid, like is recommended on Linux almost by "default"? I forget if it > is the default mount option for /usr/local or not (breaks sudo btw)? No it's not, there are quite a few ports with suid programs, not all of them games.
Re: smtpd and syslog
Trying to find a problem with smtpd used rcctl change the standard configuration to rcctl get smtpd smtpd_class=daemon smtpd_flags=-T all -v smtpd_timeout=30 smtpd_user=root and restarted smtpd I expected more detailed logging to occur in maillog There did not appear to be any extra messages in maillog. But in /var/log/messages the following appeared Jun 10 13:41:45 gateway sendsyslog: dropped 10 messages, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 2 messages, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 1 message, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 2 messages, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 1 message, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 1 message, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 2 messages, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 1 message, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 2 messages, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 1 message, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 1 message, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 2 messages, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 1 message, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 2 messages, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 1 message, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 1 message, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 2 messages, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 1 message, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 2 messages, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 1 message, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 1 message, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 2 messages, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 1 message, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 2 messages, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 1 message, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 1 message, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 2 messages, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 1 message, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 2 messages, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 1 message, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 1 message, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 2 messages, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 1 message, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 2 messages, error 55 Jun 10 13:41:45 gateway sendsyslog: dropped 1 message, error 55 Jun 10 13:41:45 gateway last message repeated 4 times and continues at about the same rate until smtpd is stopped and the flags reset further details I was actually running opensmtpd-201606062303p1 with opensmtpd-extras-201606062304
Re: smtpd and syslog
The trace messages are logged at the debug level. You'll need to edit /etc/syslog.conf and change: mail.info /var/log/maillog to: mail.debug /var/log/maillog Then you should see the trace information. - todd
FW: smtpd and syslog
The problem isn't so much that the trace message were missing. I assumed that they only occurred when smtpd -d was used. As a result I didn't immediately update the smtpd_flags using rcctl. It is nice to know why the trace entries were no showing up. But what bothered me was the thousands of lines in /var/log/messages saying sendsyslog: dropped 2 messages, error 55 when I first noticed I had forgot that I had modified smtd_flags and had no idea why my log files were filling up. I had no success trying to find what error 55 was. There was no hint as to what the source of the problem was. I did not know of any approach to find the cause, other than guessing that it was smtpd. -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Todd C. Miller Sent: Friday, June 10, 2016 2:47 PM To: Peter Fraser Cc: m...@opensmtpd.org; 'misc@openbsd.org' Subject: Re: smtpd and syslog The trace messages are logged at the debug level. You'll need to edit /etc/syslog.conf and change: mail.info /var/log/maillog to: mail.debug /var/log/maillog Then you should see the trace information. - todd
Re: FW: smtpd and syslog
On Fri, 10 Jun 2016 19:20:23 -, Peter Fraser wrote: > But what bothered me was the thousands of lines in /var/log/messages > saying > > sendsyslog: dropped 2 messages, error 55 > > when I first noticed I had forgot that I had modified smtd_flags > and had no idea why my log files were filling up. > I had no success trying to find what error 55 was. Look in /usr/include/sys/errno.h #define ENOBUFS 55 /* No buffer space available */ > There was no hint as to what the source of the problem was. > I did not know of any approach to find the cause, other than > guessing that it was smtpd. It used to be that syslog messages were silently dropped when syslogd was out of buffers. These days the kernel at least logs this condition. It would be hard for the kernel to provide more information without trying to parse the log messages that were dropped. - todd
FW: FW: smtpd and syslog
it had to have known that it maillog.debug, without parsing it and that information would have help a lot -Original Message- From: Todd C. Miller [mailto:todd.mil...@courtesan.com] Sent: Friday, June 10, 2016 3:35 PM To: Peter Fraser Cc: 'misc@openbsd.org' Subject: Re: FW: smtpd and syslog On Fri, 10 Jun 2016 19:20:23 -, Peter Fraser wrote: > But what bothered me was the thousands of lines in /var/log/messages > saying > > sendsyslog: dropped 2 messages, error 55 > > when I first noticed I had forgot that I had modified smtd_flags and > had no idea why my log files were filling up. > I had no success trying to find what error 55 was. Look in /usr/include/sys/errno.h #define ENOBUFS 55 /* No buffer space available */ > There was no hint as to what the source of the problem was. > I did not know of any approach to find the cause, other than guessing > that it was smtpd. It used to be that syslog messages were silently dropped when syslogd was out of buffers. These days the kernel at least logs this condition. It would be hard for the kernel to provide more information without trying to parse the log messages that were dropped. - todd
Random delay on incoming SMTP connection to OpenSMTPD
Hi, Is it somehow possible to add a random delay of between 5-10 seconds upon a new incomming connection to OpenSMTPD on OpenBSD? I am asking this because I sometime have 20 mails all arriving at the same time and then spamassassin is really slow because it spawns 20 processes and uses all my memory, at the end it simply times out and does not do the job... ThanksML
Re: Random delay on incoming SMTP connection to OpenSMTPD
Well right now I have max-children on 50, so you mean lowering this value to something like 10? But then if I receive 20 simultaneous incoming SMTP connection, what will happen to the 10 others?Will they fail/timeout or simply wait? On Friday, June 10, 2016 11:01 PM, Devin Reade wrote: Seems like the wrong solution. How about altering spamassassin's max-children parameter instead?
Re: Random delay on incoming SMTP connection to OpenSMTPD
--On Friday, June 10, 2016 09:04:07 PM + ML mail wrote: Well right now I have max-children on 50, so you mean lowering this value to something like 10? But then if I receive 20 simultaneous incoming SMTP connection, what will happen to the 10 others?Will they fail/timeout or simply wait? You're going to have to check the spamassassin docs because I don't recall offhand. Or test empirically. The idea, if you've got too many simultaneous scans going on, is to reduce the number of scans to something your machine can handle without tuning it so low that mail starts getting rejected. I use MailScanner as part of the mix so during bursts messages get accepted into a disk queue and then scanned at a reasonable rate. As long as the average scan rate exceeds the average receive rate, everything is fine. What you're going to have to check, though, is if spamassassin will queue things when it gets busy or if just doesn't accept the connection. If you tune things down and can't find a workable midpoint between rejecting too much and thrashing your machine, it argues that you either need a beefier machine or less processing per message. Either way, trying random delays in smtpd doesn't feel like the right answer. Devin
Re: Random delay on incoming SMTP connection to OpenSMTPD
Would filter-pause not work for you? Sent from my iPhone > On Jun 10, 2016, at 4:04 PM, ML mail wrote: > > Well right now I have max-children on 50, so you mean lowering this value to something like 10? But then if I receive 20 simultaneous incoming SMTP connection, what will happen to the 10 others?Will they fail/timeout or simply wait? > > >On Friday, June 10, 2016 11:01 PM, Devin Reade wrote: > > > Seems like the wrong solution. How about altering spamassassin's max-children parameter instead?
Re: Random delay on incoming SMTP connection to OpenSMTPD
Seems like the wrong solution. How about altering spamassassin's max-children parameter instead?
