Re: OpenSMTPd: Ignoring /etc/hosts file?

2021-09-12 Thread Aisha Tammy 
Has been reported previously - 
https://github.com/OpenSMTPD/OpenSMTPD/issues/1115

The link also contains a workaround which may be useful for you.

Best,
Aisha

On 9/12/21 5:28 PM, Simon Hoffmann wrote:

Hey yall,

in my smtpd.conf file I have "relay smtps://host.domain.tld"

host.domain.tld does resolve to a public IP, and this needs to be a public IP on
public DNS.
However, OpenSMTPd needs to relay to the local IP address of the smarthost.
Since I have no DNS server running on that network, and i dont want to setup a 
DNS
server only for OpenSMTPd, I added an enty to /etc/hosts, assigning the local 
IP to
the FQDN.
When i ping the FQDN it correctly resolves to the internal IP of the smarthost.
However, OpenSMTPd ignores the entry in /etc/hosts and still tries to connect 
to the
public IP of the host.

Is this known that OpenSMTPd ingores /etc/hosts? Or is this a problem on Debian?
Is there a workaround? Specifying "relay smtps://192.168.158.1" will not work, 
as the
private IP is not part of the Cert.
Can I force OpenSMTPd to use the internal IP? Can I disable Cert checking for 
the
smarthost?

Thanks!

System details:

root@mx01:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye
root@mx01:~# smtpd -h
version: OpenSMTPD 6.8.0p2
usage: smtpd [-dFhnv] [-D macro=value] [-f file] [-P system] [-T trace]

root@mx01:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens192
iface ens192 inet dhcp


Any info else you need?

Cheers,

Simon

[no subject]

2021-09-12 Thread Edisson Calderon 

subscribe misc

OpenSMTPd: Ignoring /etc/hosts file?

2021-09-12 Thread Simon Hoffmann 

Hey yall, 

in my smtpd.conf file I have "relay smtps://host.domain.tld"

host.domain.tld does resolve to a public IP, and this needs to be a public IP on
public DNS.
However, OpenSMTPd needs to relay to the local IP address of the smarthost.
Since I have no DNS server running on that network, and i dont want to setup a 
DNS
server only for OpenSMTPd, I added an enty to /etc/hosts, assigning the local 
IP to
the FQDN.
When i ping the FQDN it correctly resolves to the internal IP of the smarthost.
However, OpenSMTPd ignores the entry in /etc/hosts and still tries to connect 
to the
public IP of the host.

Is this known that OpenSMTPd ingores /etc/hosts? Or is this a problem on Debian?
Is there a workaround? Specifying "relay smtps://192.168.158.1" will not work, 
as the
private IP is not part of the Cert. 
Can I force OpenSMTPd to use the internal IP? Can I disable Cert checking for 
the
smarthost?

Thanks!

System details:

root@mx01:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye
root@mx01:~# smtpd -h
version: OpenSMTPD 6.8.0p2
usage: smtpd [-dFhnv] [-D macro=value] [-f file] [-P system] [-T trace]

root@mx01:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens192
iface ens192 inet dhcp


Any info else you need?

Cheers, 

Simon


signature.asc
Description: PGP signature

Re: npppd - changing clients' route table

2021-09-12 Thread Radek 
Sorry for the late reply, adding ":framed-ip-netmask=255.255.255.0:" doesn't 
solve the problem. Tested on Win10.

On Mon, 22 Feb 2021 14:55:52 +0900 (JST)
YASUOKA Masahiko  wrote:

> Hi,
> 
> On Sun, 21 Feb 2021 19:18:48 +0100
> Radek  wrote:
> >> The interface which terminate the tunnel has "192.168.4.254".
> >> Right?
> > Do you mean the other end of the tunnel? It is 10.109.4.254
> > interface pppx0 address 10.109.4.254 ipcp IPCP
> 
> Sorry, "192.168.4.244" should have been "10.109.4.254".
> 
> >> How about if you configure the npppd-users
> >> 
> >> rdk:
> >>   :password=pasword:\
> >>   :framed-ip-address=10.109.4.254:\
> >>   :framed-ip-netmask=255.255.255.0:
> >> 
> >> The server (npppd) will configure a route for 10.109.4.0/24 to the PPP
> >> session authenticated by the above "rdk".
> > I have tried to configure npppd-users with netmask /24, but it doesnt make 
> > any changes. Still have all traffic to 10.0.0.0/8 going across the tunnel 
> > to 10.109.4.254(VPN), but I need to push the traffic to 10.109.3.0/24 
> > through the tunnel (via 10.109.4.254) and the rest of 10.0.0.0/8 through 
> > default gw or sometimes some traffic to 10.0.0.0/8 through another tunnel 
> > at the same time. Now if the PPP tunnel is established the VPN catches all 
> > the 10.0.0.0/8 traffic.
> > 
> > The VPN client (Windows7/10) is configured to NOT use the VPN as remote gw.
> > 
> > Example:
> > I have a public, static IP. There is configured route to 10.55.0.0/24 at 
> > the ISP's side and I dont need any VPN tunnel to access 10.55.. 
> > Somewhere over the rainbow is a router with LAN 10.109.3.0/24 and npppd.
> > If I use the PPP tunnel I can acces 10.109.3.0/24 but at the same time I 
> > can't access 10.55.0.0/24 because all 10.0.0.0/8 goes across the tunnel.
> 
> The route to the natural netmask of the tunnel address, 10.0.0.0/8 in
> this case, is configured by Windows automatically.  I don't know a way
> to stop or override this.  But by using another addresses for the
> tunnel, you can avoid the problem.  Also we can use dhcpd(8) to push
> routes configuration.
> 
> For example,
> 
> 1. Use 192.168.255.0/24 for the tunnel to avoid the conflict on
>10.0.0.0/8.
> 
>ipcp IPCP {
>   pool-address 192.168.255.1-192.168.255.32
> :
>interface pppx0 address 192.168.255.254 ipcp IPCP
>---
>rdk:
> :password=pasword:\
> :framed-ip-address=192.168.255.32:
> 
> 2. Configure dhcpd
> 
>/etc/dhcpd-l2tp.conf
>
>subnet 192.168.255.0 netmask 255.255.255.0 {
>  option classless-ms-static-routes 10.109.3.0/24 192.168.255.254;
>  option classless-static-routes10.109.3.0/24 192.168.255.254;
>}
>---
>   
>$ doas /usr/sbin/dhcpd -u255.255.255.255 -c /etc/dhcpd-l2tp.conf
> 
> > On Sun, 21 Feb 2021 23:18:19 +0900 (JST)
> > YASUOKA Masahiko  wrote:
> > 
> >> Hello,
> >> 
> >> On Sat, 20 Feb 2021 21:14:24 +0100
> >> Radek  wrote:
> >> > I have a router with VPN server (npppd). LAN net is 10.109.3.0/24, gw 
> >> > 10.109.3.254, the VPN net is 10.109.4.0/24, gw 10.109.4.254.
> >> > If the client is conencted to VPN all client's traffic to 10.0.0.0/8 
> >> > goes via 10.109.4.254
> >> > 
> >> > client> route print 
> >> > Network Destination   Netmask  Gateway  Interface Metric
> >> >   0.0.0.0  0.0.0.0   192.168.1.1
> >> > 192.168.1.101 20
> >> > 10.0.0.0  255.0.0.0 10.109.4.254  
> >> > 10.109.4.1 21
> >> > 10.109.4.1  255.255.255.255 On-link
> >> > 10.109.4.1276
> >> > [...]
> >> 
> >> The interface which terminate the tunnel has "192.168.4.254".
> >> Right?
> >> 
> >> > $ cat /etc/npppd/npppd-users
> >> > rdk:\
> >> > :password=pasword:\
> >> > :framed-ip-address=10.109.4.1:
> >> > #:framed-ip-netmask=255.255.255.0:
> >> 
> >> How about if you configure the npppd-users
> >> 
> >> rdk:
> >>   :password=pasword:\
> >>   :framed-ip-address=10.109.4.254:\
> >>   :framed-ip-netmask=255.255.255.0:
> >> 
> >> ?
> >> 
> >> The server (npppd) will configure a route for 10.109.4.0/24 to the PPP
> >> session authenticated by the above "rdk".
> >> 
> >> 
> >> On Sat, 20 Feb 2021 21:14:24 +0100
> >> Radek  wrote:
> >> > Hi, 
> >> > I have a router with VPN server (npppd). LAN net is 10.109.3.0/24, gw 
> >> > 10.109.3.254, the VPN net is 10.109.4.0/24, gw 10.109.4.254.
> >> > If the client is conencted to VPN all client's traffic to 10.0.0.0/8 
> >> > goes via 10.109.4.254
> >> > 
> >> > client> route print 
> >> > Network Destination   Netmask  Gateway  Interface Metric
> >> >   0.0.0.0  0.0.0.0   192.168.1.1
> >> > 192.168.1.101 20
> >> > 10.0.0.0  255.0.0.0 10.109.4.254  
> >> > 10.109.4.1 21
> >> > 10.109.4.1  255.255.255.255 On-link
> >> > 10.109.4.1276
> >> > [...]
> >> > 
> >> > I need to redirect the traffic to 10.109.4.

Re: Timestamps missing on httpd's error log

2021-09-12 Thread Stuart Henderson 
On 2021-09-10, i...@protonmail.com  wrote:
> Is there any particular reason why this issue is being ignored?
>
> https://www.mail-archive.com/bugs@openbsd.org/msg15344.html
>

Probably just nobody who read it at the time was interested enough to work on 
it,
especially given that the workaround given of using syslog is not too bad.


-- 
Please keep replies on the mailing list.