Re: 5.8 Stable kernel panic

[Donald Allen]

Solved -- my error. I completely forgot that I had used config to make
a kernel from the Stable kernel, disabling devices that don't exist in
this machine, or so I thought. Fortunately, when I installed it, I
saved the stock Stable kernel.

I took your suggestion and downloaded a current snapshot and booted
the cd. Plugging and unplugging the USB disk caused no trouble. Then I
tried the 5.8 install disk. Worked fine. That's when I remembered the
config'ed kernel. So I booted the system with the stock Stable kernel
and that worked fine, too, not surprisingly.

So thank you for your help and sorry for the false alarm.

/Don Allen

On 11/12/15, Stefan Sperling  wrote:
> On Thu, Nov 12, 2015 at 12:53:06PM -0500, Donald Allen wrote:
>> fdisk and disklabel output below.
>>
>> I should note that the panic is reproducible. I rebooted the problem
>> system and tried plugging and unplugging the USB drive and it panicked
>> again. The HP laptop, running the 5.8 install cd system, exhibits no
>> such problems. Plug the same drive in and I get a device address
>> normally in dmesg. Unplug it, no problem. So it appears there is
>> something about the USB hardware in the problem machine that is
>> confusing the OpenBSD driver. I should note that I've run Linux and
>> FreeBSD on the same machine with no USB issues of this kind with the
>> same drive.
>
> Please try -current. ddb in -current should show a trace by default.

Re: Will mmap and the read buffer cache be unified, anyone working with it?

[Stuart Henderson]

On 2015-05-23, Tinker  wrote:
> On 2015-05-23 16:42, Stuart Henderson wrote:
>> On 2015-05-22, Tinker  wrote:
>>> Okay there's msync(). So this really doesn't look like a problem but 
>>> let
>>> me think.
>> 
>> It is a problem because it's not needed on the majority of other OS
>> where most upstream testing is done, so even programs which try to do
>> the right thing will often silently corrupt data on OpenBSD.
>> 
>> We definitely had problems with Cyrus imapd in the past. Dovecot 
>> disables
>> some things on OpenBSD as a result. OpenLDAP MDB has had issues. And
>> I suspect this may be involved in problems we saw in NSD prior to
>> disabling the database in the default config.
>
> Agreed.
>
> (Also SQLite has mmap disabled on OpenBSD for this reason, and is maaybe 
> ~30% slower for this reason. I guess in a way this is just a silly 
> architectural detail, but it "can" require unified caching because all 
> other OS:es implement it.)

Since the thread came up again, I'll add a few more for the archives:
tokyocabinet and kyotocabinet have problems which look very like they're
related to this too, they do have code meant to work in this case but
there are problems that show up in regression tests.

Re: 5.8 freezes on Shuttle DS87, anybody else?

[Stuart Henderson]

On 2015-11-11, Harald Dunkel  wrote:
> Hi folks,
>
> below you can find the trace and ps for the frozen system,
> as well as the output of dmesg.
>
> Hope this helps. Please mail if I can help to track down this
> problem.

Trace for other CPUs might help (ddb{0} shows that you are on cpu 0;
"mach ddbcpu 1" etc switches to another one). Also the line marked '*'
in ps output (indicating the currently-running process) from other
CPUs.

Re: Will mmap and the read buffer cache be unified, anyone working with it?

[Stuart Henderson]

On 2015-11-11, Tinker  wrote:
> But LMDB doesn't even compile on OpenBSD in mmap mode, does it, or did 
> you fix it last months?

I haven't tried standalone LMDB but last time I tried OpenLDAP with MDB
enabled (using MDB_WRITEMAP) it did build, but had failures at runtime.

npppd and pf

[Jeremy]

I'm adding more functionality to my firewall (OpenBSD 5.7) and have been 
trying to configure PPTP VPN access for my Windows users. I have got npppd 
running using the config below and can successfully authenticate and 
establish a connection.

I am able to connect to the VPN from a windows PC but I can't reach the 
internal hosts on the network.
I suspect I have some conflicts over my internal subnet and various pf rules. 
If I remove the antispoof rule, I am able to ping the firewall on its IP and
that of the pppx0 interface (192.168.7.128)
My internal em0 is on 192.168.7.0/24 which will overlap the pppx0 interface but 
I 
am expecting my VPN users to appear on the same subnet. Is this valid ?

I can ping the connected client on its IP 192.168.7.118 from the firewall.
I can occasionally ping some other hosts on the internal network but this
seems somewhat random and most of the time I can't reach any hosts. 
(I'm running dhcpd on this box too if that makes a difference.)

I've scanned the man pages for npppd and pf but I think I'm missing something
more fundamental. Could someone please take a quick look and see if there is 
anything obvious.

Thanks in advance.

=
#cat /etc/npppd/npppd.conf 
tunnel PPTP protocol pptp 
ipcp IPCP { 
pool-address 192.168.7.95-192.168.7.127 
dns-servers 192.168.7.1 8.8.8.8 
} 
interface pppx0 address 192.168.7.128 ipcp IPCP 
authentication LOCAL type local { 
users-file "/etc/npppd/npppd-users" 
}
bind tunnel from PPTP authenticated by LOCAL to pppx0


=
# ifconfig pppx0
pppx0: flags=8051 mtu 1400
description: jeremy
priority: 0
groups: pppx
inet 192.168.7.128 --> 192.168.7.118 netmask 0x



# cat /etc/pf.conf
#   $OpenBSD: pf.conf,v 1.54 2014/08/23 05:49:42 deraadt Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf

# macros
int_if="em0"
ext_if="em1"

tcp_services="{ 22, 113 }"
udp_services="{ 161 }"
mail_services="{ 25, 587, 993, 995 }"
web_services="{ 80, 443 }"
vpn_pptp="{ 1723 }"

icmp_types="echoreq"

web_server = "192.168.7.77"
mail_server = "192.168.7.77"

# options
set block-policy return
set loginterface egress
set skip on lo

# FTP Proxy rules
anchor "ftp-proxy/*"
pass in quick on $int_if inet proto tcp to any port ftp divert-to 127.0.0.1 
port 8021

# match rules
match in all scrub (no-df random-id max-mss 1440)
match out on egress inet from $int_if:network to any nat-to (egress:0)

# filter rules
block in log

pass out quick
antispoof quick for { lo $int_if }

# Allow access to services running on the firewall
pass in on egress inet proto tcp from any to (egress) port $tcp_services flags 
S/SA keep state
pass in on egress inet proto udp from any to (egress) port $udp_services

# VPN Rules
pass in quick inet proto gre all
pass in log on pppx
pass in quick on egress inet proto tcp from any to (egress) port $vpn_pptp

# Redirect traffic to the interior servers
pass in on egress inet proto tcp to (egress) port $web_services  rdr-to 
$web_server synproxy state
pass in on egress inet proto tcp to (egress) port $mail_services rdr-to 
$mail_server

pass in inet proto icmp all icmp-type $icmp_types

pass in on $int_if
===

asking for advice about low-power soc computer

[Imre Oolberg]

Hi!

So far i have used OpenBSD either on older servers or on ordinary older 
PC's for packet filtering etc. Now i would like to give it a try and use 
more-or-less contemporary so to say SoC form-factor board (i think this 
is what i need because among other things i need to have clamav and it 
better has 2 G ram). For me it is easier to choose from what local it 
shop has (actually they put such computer together on demand) and as i 
understand broadly speaking i have those choices


1. mini-itx or micro-atx, i would prefer micro-atx because it has more 
PCIe slots in case i need for example extra NIC ports (although mini-itx 
also has at least one pci or pcie)
2. j1800 and j1900 processors which are in itselt more of a desktop 
stuff and older; or n3050 which are mobile and newer, i would prefer 
which one works better with OpenBSD


I would be thankful if you could comment on running OpenBSD on these 
three processors based for example on these specific boards (or suggest 
something else which is known to work)


1. asrock q1900m - http://www.asrock.com/mb/Intel/Q1900M/
2. gigabyte ga-n3050N-d3h - 
http://www.gigabyte.com/products/product-page.aspx?pid=#ov

3. asus j1800i-A - https://www.asus.com/Motherboards/J1800IA/

I looked over misc achive also and i saw people having more or less 
success running openbsd on all of them. And if it wasnt already asked 
enough, please comment if for example there is respectable indication 
online somewhere that says OpenBSD runs on j1800-IC is it then most 
probable that it runs also on j1800-IA (diagonally looking i see some 
more io ports on j1800-ic model).



Best regards,

Imre

Ipsec tunnel not starting after update to recent snapshot

[Theodore Wynnychenko]

Hello

I recently updated to the 11-9 amd64 snapshot.
I had started following current, and, in general, seem to be doing fine.

But, after this last update, an IPSEC tunnel that I have been using
for months/years all of a sudden is not coming up with a system reboot.

I have not changed the ipsec.conf files in a really long time.  So, I
did not included them, but can if necessary.  The important point (I
think) is that I am using some FQDN with dynamic ip's.

What I have noticed is that the "dynamic" side of the tunnel seems to
be trying to connect, but the "passive" side refuses to accept the
connection.

On the passive side, I get this:
...
Nov 10 10:21:46 xxx isakmpd[12622]: attribute_unacceptable:
ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC
Nov 10 10:21:46 xxx isakmpd[12622]: message_negotiate_sa: no
compatible proposal found
Nov 10 10:21:46 xxx isakmpd[12622]: dropped message from a.b.c.d port
500 due to notification type NO_PROPOSAL_CHOSEN
...
So, I understand this is because isakmpd is "falling back" to a
default 3DES setting, and the AES proposal from the dynamic side of
the tunnel is being rejected.

This led me to the dmesg on the passive host:
...
starting early daemons: syslogd pflogd ntpd isakmpd.
no IP address found for ipsec1.FQDN.com /etc/ipsec.conf: 40: could not
parse host specification
no IP address found for ipsec1.FQDN.com /etc/ipsec.conf: 41: could not
parse host specification
no IP address found for ipsec2.FQDN.com /etc/ipsec.conf: 42: could not
parse host specification
no IP address found for ipsec2.FQDN.com /etc/ipsec.conf: 43: could not
parse host specification
ipsecctl: Syntax error in config file: ipsec rules not loaded
...

So, I reload the ipsec.conf file manually - "ipsecctl -f
/etc/ipsec.conf" - and the tunnel goes up.

Now, on the dynamic host, there is no issue loading ipsec at boot -
dmesg for the dynamic host:
...
starting early daemons: syslogd pflogd ntpd isakmpd.
starting RPC daemons:.
...

As I said, no changes to ipsec.conf, and it was working last week
before the current snapshot.
I don't see anything in 'following current' about changes to ipsec
configuration.

Also, both ends of the tunnel point to the same resolver (openDNS)
during the boot up process.  If it was an issue with the resolver, I
would have expected a problem on both ends of the tunnel.

The confusing thing to me is why a line like: "ike passive esp from
$local_ip to $remote_gw srcid $local_id dstid $remote_id"
is failing during boot with "could not parse host specification."

But, a line like: "ike dynamic esp from $local_ip to $remote_gw srcid
$local_id dstid $remote_id"
works without an issue.

So, am I missing something, or is this a bug?  And, if so, what should I do?

Thanks
Ted W.

Re: state of SSD by OpenBSD

[Nick Holland]

On 11/12/15 21:01, Alceu Rodrigues de Freitas Junior wrote:
> Hi there,
> 
> How is the current status of SSD disks support by OpenBSD?

Work great.  Always has.

> I did some research on Google about but didn't find any definitive
> answer. I did find some references about lacking of support for TRIM

(*grumble*)

> Is there any real risk (of reducing the durability of a SSD disk) by
> using FFS? I found references of setting partitions with noatime
> option, but that's all.

reducing compared to what?

(noatime is a huge performance gain.  atime is a feature looking for a
need, I suspect).

I've got some mechanical disks that are over 15 years old in production
("Why?"  "Because I shut down the older stuff").  I don't think you will
be seeing that with modern drives -- of any technology.  Get used to it.
 (same goes for the rest of the computer hw).

Cycle your disks through at a reasonable rate (i.e., put into
non-critical applications after three to five years or so), and you will
have nothing special to worry about.  Same goes for mechanical disks.
By that time, the old drive will be small in storage, huge in size, slow
and probably of an obsolete interface and you won't worry about tossing it.

SSDs are just like mechanicals for administrators.
You must have a backup.
You must have a repair plan.
NOTHING is different here.

And if you deploy a lot of SSDs, you will probably find most of your
failures have nothing to do with write fatigue.  Some models are good,
some are crap, you can't say which is which until after they are out of
production.

SSDs have a failure mode mechanicals don't.  Mechanicals have a bunch of
failure modes SSDs don't.  Both fail from other things more often than
the obvious things people like to fret about.  If the fear of an SSD
failing causes you to manage your systems better, it's all good.  If
failures aren't part of your system design, try again.

Nothing different here.

Nick.

state of SSD by OpenBSD

[Alceu Rodrigues de Freitas Junior]

Hi there,

How is the current status of SSD disks support by OpenBSD?

I did some research on Google about but didn't find any definitive
answer. I did find some references about lacking of support for TRIM
(for example
http://www.tedunangst.com/flak/post/lessons-learned-about-TRIM) but
they are also outdated.

Is there any real risk (of reducing the durability of a SSD disk) by
using FFS? I found references of setting partitions with noatime
option, but that's all.

Thanks,

Alceu

DHCP during install of current/amd64

[Jan Stary]

I just reinstalled an IBM x346 with current/amd64
from install58.iso (dmesg bellow).

During the network setup stage, the dhclient on bge0 sent out a number of
DHCPDISCOVER's and was repeatedly answered with a DHCPOFFER, which it
never accepted. Log of the DHCP server (itself a current/amd64) below.
Other DHCP clients of that server are just fine,
including the laptop where I am writing this.

Is anybody else seeing this with the latest snapshot?

Jan


Nov 12 16:12:20 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via em0
Nov 12 16:12:20 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
00:14:5e:69:2f:b2 via em0
Nov 12 16:12:20 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via em0
Nov 12 16:12:20 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
00:14:5e:69:2f:b2 via em0
Nov 12 16:12:23 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via em0
Nov 12 16:12:23 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
00:14:5e:69:2f:b2 via em0
Nov 12 16:12:23 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via em0
Nov 12 16:12:23 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
00:14:5e:69:2f:b2 via em0
Nov 12 16:12:25 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via em0
Nov 12 16:12:25 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
00:14:5e:69:2f:b2 via em0
Nov 12 16:13:01 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via em0
Nov 12 16:13:01 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
00:14:5e:69:2f:b2 via em0
Nov 12 16:13:01 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via em0
Nov 12 16:13:01 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
00:14:5e:69:2f:b2 via em0
Nov 12 16:13:01 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via em0
Nov 12 16:13:01 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
00:14:5e:69:2f:b2 via em0
Nov 12 16:13:04 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via em0
Nov 12 16:13:04 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
00:14:5e:69:2f:b2 via em0
Nov 12 16:13:12 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via em0
Nov 12 16:13:12 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
00:14:5e:69:2f:b2 via em0
Nov 12 16:13:23 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via em0
Nov 12 16:13:23 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
00:14:5e:69:2f:b2 via em0
Nov 12 16:13:40 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via em0
Nov 12 16:13:40 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
00:14:5e:69:2f:b2 via em0
Nov 12 16:13:59 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via em0
Nov 12 16:13:59 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
00:14:5e:69:2f:b2 via em0

Re: DHCP during install of current/amd64

[Jan Stary]

On Nov 12 16:21:41, h...@stare.cz wrote:
> I just reinstalled an IBM x346 with current/amd64
> from install58.iso (dmesg bellow).
> 
> During the network setup stage, the dhclient on bge0 sent out a number of
> DHCPDISCOVER's and was repeatedly answered with a DHCPOFFER, which it
> never accepted.

Trying to do a manual dhclient bge0 says

Can't find free bpf: No such file or directory

And on a second run, it behaves as before,
i.e. DISCOVER, OFFER, DISCOVER, ...

And then fails on bpf again.
Same happens on bge1.

Would this be a sign of a HW failuere?

Jan


> Log of the DHCP server (itself a current/amd64) below.
> Other DHCP clients of that server are just fine,
> including the laptop where I am writing this.
> 
> Is anybody else seeing this with the latest snapshot?
> 
>   Jan
> 
> 
> Nov 12 16:12:20 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via 
> em0
> Nov 12 16:12:20 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> 00:14:5e:69:2f:b2 via em0
> Nov 12 16:12:20 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via 
> em0
> Nov 12 16:12:20 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> 00:14:5e:69:2f:b2 via em0
> Nov 12 16:12:23 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via 
> em0
> Nov 12 16:12:23 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> 00:14:5e:69:2f:b2 via em0
> Nov 12 16:12:23 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via 
> em0
> Nov 12 16:12:23 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> 00:14:5e:69:2f:b2 via em0
> Nov 12 16:12:25 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via 
> em0
> Nov 12 16:12:25 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> 00:14:5e:69:2f:b2 via em0
> Nov 12 16:13:01 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via 
> em0
> Nov 12 16:13:01 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> 00:14:5e:69:2f:b2 via em0
> Nov 12 16:13:01 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via 
> em0
> Nov 12 16:13:01 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> 00:14:5e:69:2f:b2 via em0
> Nov 12 16:13:01 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via 
> em0
> Nov 12 16:13:01 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> 00:14:5e:69:2f:b2 via em0
> Nov 12 16:13:04 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via 
> em0
> Nov 12 16:13:04 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> 00:14:5e:69:2f:b2 via em0
> Nov 12 16:13:12 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via 
> em0
> Nov 12 16:13:12 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> 00:14:5e:69:2f:b2 via em0
> Nov 12 16:13:23 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via 
> em0
> Nov 12 16:13:23 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> 00:14:5e:69:2f:b2 via em0
> Nov 12 16:13:40 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via 
> em0
> Nov 12 16:13:40 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> 00:14:5e:69:2f:b2 via em0
> Nov 12 16:13:59 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 via 
> em0
> Nov 12 16:13:59 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> 00:14:5e:69:2f:b2 via em0

Re: DHCP during install of current/amd64

[Jan Stary]

On Nov 12 16:33:02, h...@stare.cz wrote:
> On Nov 12 16:21:41, h...@stare.cz wrote:
> > I just reinstalled an IBM x346 with current/amd64
> > from install58.iso (dmesg bellow).
> > 
> > During the network setup stage, the dhclient on bge0 sent out a number of
> > DHCPDISCOVER's and was repeatedly answered with a DHCPOFFER, which it
> > never accepted.
> 
> Trying to do a manual dhclient bge0 says
> 
>   Can't find free bpf: No such file or directory
> 
> And on a second run, it behaves as before,
> i.e. DISCOVER, OFFER, DISCOVER, ...
> 
> And then fails on bpf again.
> Same happens on bge1.

And the same happens with booting into the installed bsd.rd

Jan

> 
> 
> > Log of the DHCP server (itself a current/amd64) below.
> > Other DHCP clients of that server are just fine,
> > including the laptop where I am writing this.
> > 
> > Is anybody else seeing this with the latest snapshot?
> > 
> > Jan
> > 
> > 
> > Nov 12 16:12:20 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > via em0
> > Nov 12 16:12:20 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > 00:14:5e:69:2f:b2 via em0
> > Nov 12 16:12:20 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > via em0
> > Nov 12 16:12:20 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > 00:14:5e:69:2f:b2 via em0
> > Nov 12 16:12:23 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > via em0
> > Nov 12 16:12:23 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > 00:14:5e:69:2f:b2 via em0
> > Nov 12 16:12:23 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > via em0
> > Nov 12 16:12:23 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > 00:14:5e:69:2f:b2 via em0
> > Nov 12 16:12:25 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > via em0
> > Nov 12 16:12:25 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > 00:14:5e:69:2f:b2 via em0
> > Nov 12 16:13:01 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > via em0
> > Nov 12 16:13:01 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > 00:14:5e:69:2f:b2 via em0
> > Nov 12 16:13:01 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > via em0
> > Nov 12 16:13:01 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > 00:14:5e:69:2f:b2 via em0
> > Nov 12 16:13:01 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > via em0
> > Nov 12 16:13:01 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > 00:14:5e:69:2f:b2 via em0
> > Nov 12 16:13:04 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > via em0
> > Nov 12 16:13:04 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > 00:14:5e:69:2f:b2 via em0
> > Nov 12 16:13:12 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > via em0
> > Nov 12 16:13:12 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > 00:14:5e:69:2f:b2 via em0
> > Nov 12 16:13:23 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > via em0
> > Nov 12 16:13:23 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > 00:14:5e:69:2f:b2 via em0
> > Nov 12 16:13:40 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > via em0
> > Nov 12 16:13:40 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > 00:14:5e:69:2f:b2 via em0
> > Nov 12 16:13:59 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > via em0
> > Nov 12 16:13:59 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > 00:14:5e:69:2f:b2 via em0

Re: DHCP during install of current/amd64

[Einfach Jemand]

On Thu, Nov 12, 2015 at 04:41:28PM +0100, Jan Stary wrote:
> On Nov 12 16:33:02, h...@stare.cz wrote:
> > On Nov 12 16:21:41, h...@stare.cz wrote:
> > > I just reinstalled an IBM x346 with current/amd64
> > > from install58.iso (dmesg bellow).
> > > 
> > > During the network setup stage, the dhclient on bge0 sent out a number of
> > > DHCPDISCOVER's and was repeatedly answered with a DHCPOFFER, which it
> > > never accepted.
> > 
> > Trying to do a manual dhclient bge0 says
> > 
> > Can't find free bpf: No such file or directory
> > 
> > And on a second run, it behaves as before,
> > i.e. DISCOVER, OFFER, DISCOVER, ...
> > 
> > And then fails on bpf again.
> > Same happens on bge1.
> 
> And the same happens with booting into the installed bsd.rd
> 
>   Jan
> 
> > 
> > 
> > > Log of the DHCP server (itself a current/amd64) below.
> > > Other DHCP clients of that server are just fine,
> > > including the laptop where I am writing this.
> > > 
> > > Is anybody else seeing this with the latest snapshot?
> > > 
> > >   Jan
> > > 
> > > 
> > > Nov 12 16:12:20 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > > via em0
> > > Nov 12 16:12:20 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > > 00:14:5e:69:2f:b2 via em0
> > > Nov 12 16:12:20 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > > via em0
> > > Nov 12 16:12:20 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > > 00:14:5e:69:2f:b2 via em0
> > > Nov 12 16:12:23 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > > via em0
> > > Nov 12 16:12:23 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > > 00:14:5e:69:2f:b2 via em0
> > > Nov 12 16:12:23 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > > via em0
> > > Nov 12 16:12:23 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > > 00:14:5e:69:2f:b2 via em0
> > > Nov 12 16:12:25 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > > via em0
> > > Nov 12 16:12:25 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > > 00:14:5e:69:2f:b2 via em0
> > > Nov 12 16:13:01 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > > via em0
> > > Nov 12 16:13:01 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > > 00:14:5e:69:2f:b2 via em0
> > > Nov 12 16:13:01 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > > via em0
> > > Nov 12 16:13:01 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > > 00:14:5e:69:2f:b2 via em0
> > > Nov 12 16:13:01 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > > via em0
> > > Nov 12 16:13:01 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > > 00:14:5e:69:2f:b2 via em0
> > > Nov 12 16:13:04 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > > via em0
> > > Nov 12 16:13:04 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > > 00:14:5e:69:2f:b2 via em0
> > > Nov 12 16:13:12 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > > via em0
> > > Nov 12 16:13:12 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > > 00:14:5e:69:2f:b2 via em0
> > > Nov 12 16:13:23 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > > via em0
> > > Nov 12 16:13:23 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > > 00:14:5e:69:2f:b2 via em0
> > > Nov 12 16:13:40 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > > via em0
> > > Nov 12 16:13:40 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > > 00:14:5e:69:2f:b2 via em0
> > > Nov 12 16:13:59 biblio dhcpd[12819]: DHCPDISCOVER from 00:14:5e:69:2f:b2 
> > > via em0
> > > Nov 12 16:13:59 biblio dhcpd[12819]: DHCPOFFER on 192.168.111.6 to 
> > > 00:14:5e:69:2f:b2 via em0
> 

Hi,

this might be related to 

http://marc.info/?t=14472951942=1=2

(openbsd-bugs: Recent checkin to bge broke my Broadcom ethernet)

HTH
rru

Re: 5.8 Stable kernel panic

[Donald Allen]

fdisk and disklabel output below.

I should note that the panic is reproducible. I rebooted the problem
system and tried plugging and unplugging the USB drive and it panicked
again. The HP laptop, running the 5.8 install cd system, exhibits no
such problems. Plug the same drive in and I get a device address
normally in dmesg. Unplug it, no problem. So it appears there is
something about the USB hardware in the problem machine that is
confusing the OpenBSD driver. I should note that I've run Linux and
FreeBSD on the same machine with no USB issues of this kind with the
same drive.

Disk: sd1 geometry: 38913/255/63 [625142448 Sectors]
Offset: 0 Signature: 0xAA55
Starting Ending LBA Info:
 #: id  C   H   S -  C   H   S [   start:size ]
---
 0: A6  0   0   2 -  38912 254  63 [   1:   625137344 ] OpenBSD
 1: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
 2: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
 3: 00  0   0   0 -  0   0   0 [   0:   0 ] unused

# /dev/rsd1c:
type: SCSI
disk: SCSI disk
label: External USB HDD
duid: b87faac679619765
flags:
bytes/sector: 512# /dev/rsd1c:
type: SCSI
disk: SCSI disk
label: External USB HDD
duid: b87faac679619765
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 38913
total sectors: 625142448
boundstart: 1
boundend: 625142448
drivedata: 0

16 partitions:
#size   offset  fstype [fsize bsize  cpg]
  a:6251423991  4.2BSD   4096 327681
  c:6251424480  unused
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 38913
total sectors: 625142448
boundstart: 1
boundend: 625142448
drivedata: 0

16 partitions:
#size   offset  fstype [fsize bsize  cpg]
  a:6251423991  4.2BSD   4096 327681
  c:6251424480  unused

On Thu, Nov 12, 2015 at 12:01 PM, Donald Allen  wrote:
> I am running 5.8 Stable. I plugged in one of my Toshiba USB disks with
> the intention of beginning to backup the system. dmesg | tail did not
> provide a device address; the line that mentioned the device said 'not
> configured'. Without a device address, I couldn't mount the root
> partition. So I removed the USB connector and the kernel panicked:
>
> "Toshiba External USB HDD" rev 2.00/1.32 addr 2 at uhub2 port 4 not configured
> uvm_fault(0x81904280, 0x0, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped at usb_detach+0x20: movq 0(%rax),%rdi
> ddb{0}>
>
> Trying to type at the ddb prompt (hoping to get a stack trace) got no 
> response.
>
> I had previously attempted to set this disk up on this machine and had
> been able to create an A6 MBR partition and create a disklabel with an
> 'a' partition, but when I tried to create a file-system, newfs hung. I
> tried booting the 5.8 install cd on another machine (an old HP
> laptop), plugged in the drive (I had to run MAKEDEV to create
> /dev/sd1*) and was able to run newfs without trouble. I will send
> fdisk and disklabel output for the USB disk in a separate message.
>
>  0x00: apic 3 int 20, version 1.0, legacy support
> ehci1 at pci0 dev 19 function 2 "ATI SB700 USB2" rev 0x00: apic 3 int 21
> usb2 at ehci1: USB revision 2.0
> uhub2 at usb2 "ATI EHCI root hub" rev 2.00/1.00 addr 1
> "ATI SBx00 SMBus" rev 0x42 at pci0 dev 20 function 0 not configured
> "ATI SBx00 HD Audio" rev 0x40 at pci0 dev 20 function 2 not configured
> "ATI SB700 ISA" rev 0x40 at pci0 dev 20 function 3 not configured
> ppb3 at pci0 dev 20 function 4 "ATI SB600 PCI" rev 0x40
> pci4 at ppb3 bus 4
> ohci2 at pci0 dev 20 function 5 "ATI SB700 USB" rev 0x00: apic 3 int
> 18, version 1.0, legacy support
> ohci3 at pci0 dev 22 function 0 "ATI SB700 USB" rev 0x00: apic 3 int
> 22, version 1.0, legacy support
> ehci2 at pci0 dev 22 function 2 "ATI SB700 USB2" rev 0x00: apic 3 int 23
> usb3 at ehci2: USB revision 2.0
> uhub3 at usb3 "ATI EHCI root hub" rev 2.00/1.00 addr 1
> pchb1 at pci0 dev 24 function 0 "AMD AMD64 10h HyperTransport" rev 0x00
> pchb2 at pci0 dev 24 function 1 "AMD AMD64 10h Address Map" rev 0x00
> pchb3 at pci0 dev 24 function 2 "AMD AMD64 10h DRAM Cfg" rev 0x00
> pchb4 at pci0 dev 24 function 3 "AMD AMD64 10h Misc Cfg" rev 0x00
> pchb5 at pci0 dev 24 function 4 "AMD AMD64 10h Link Cfg" rev 0x00
> usb4 at ohci0: USB revision 1.0
> uhub4 at usb4 "ATI OHCI root hub" rev 1.00/1.00 addr 1
> usb5 at ohci1: USB revision 1.0
> uhub5 at usb5 "ATI OHCI root hub" rev 1.00/1.00 addr 1
> usb6 at ohci2: USB revision 1.0
> uhub6 at usb6 "ATI OHCI root hub" rev 1.00/1.00 addr 1
> usb7 at ohci3: USB revision 1.0
> uhub7 at usb7 "ATI OHCI root hub" rev 1.00/1.00 addr 1
> isa0 at mainbus0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> 

Re: 5.8 Stable kernel panic

[Donald Allen]

One more thing: it just occurred to me to try a different USB drive,
to see if the issue was specific to the Toshiba drive. I have a 1TB
Seagate USB drive. I tried plugging it in and unplugging -- same
thing, kernel panic.

Re: 5.8 Stable kernel panic

[Stefan Sperling]

On Thu, Nov 12, 2015 at 12:53:06PM -0500, Donald Allen wrote:
> fdisk and disklabel output below.
> 
> I should note that the panic is reproducible. I rebooted the problem
> system and tried plugging and unplugging the USB drive and it panicked
> again. The HP laptop, running the 5.8 install cd system, exhibits no
> such problems. Plug the same drive in and I get a device address
> normally in dmesg. Unplug it, no problem. So it appears there is
> something about the USB hardware in the problem machine that is
> confusing the OpenBSD driver. I should note that I've run Linux and
> FreeBSD on the same machine with no USB issues of this kind with the
> same drive.

Please try -current. ddb in -current should show a trace by default.

5.8 Stable kernel panic

[Donald Allen]

I am running 5.8 Stable. I plugged in one of my Toshiba USB disks with
the intention of beginning to backup the system. dmesg | tail did not
provide a device address; the line that mentioned the device said 'not
configured'. Without a device address, I couldn't mount the root
partition. So I removed the USB connector and the kernel panicked:

"Toshiba External USB HDD" rev 2.00/1.32 addr 2 at uhub2 port 4 not configured
uvm_fault(0x81904280, 0x0, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at usb_detach+0x20: movq 0(%rax),%rdi
ddb{0}>

Trying to type at the ddb prompt (hoping to get a stack trace) got no response.

I had previously attempted to set this disk up on this machine and had
been able to create an A6 MBR partition and create a disklabel with an
'a' partition, but when I tried to create a file-system, newfs hung. I
tried booting the 5.8 install cd on another machine (an old HP
laptop), plugged in the drive (I had to run MAKEDEV to create
/dev/sd1*) and was able to run newfs without trouble. I will send
fdisk and disklabel output for the USB disk in a separate message.

 0x00: apic 3 int 20, version 1.0, legacy support
ehci1 at pci0 dev 19 function 2 "ATI SB700 USB2" rev 0x00: apic 3 int 21
usb2 at ehci1: USB revision 2.0
uhub2 at usb2 "ATI EHCI root hub" rev 2.00/1.00 addr 1
"ATI SBx00 SMBus" rev 0x42 at pci0 dev 20 function 0 not configured
"ATI SBx00 HD Audio" rev 0x40 at pci0 dev 20 function 2 not configured
"ATI SB700 ISA" rev 0x40 at pci0 dev 20 function 3 not configured
ppb3 at pci0 dev 20 function 4 "ATI SB600 PCI" rev 0x40
pci4 at ppb3 bus 4
ohci2 at pci0 dev 20 function 5 "ATI SB700 USB" rev 0x00: apic 3 int
18, version 1.0, legacy support
ohci3 at pci0 dev 22 function 0 "ATI SB700 USB" rev 0x00: apic 3 int
22, version 1.0, legacy support
ehci2 at pci0 dev 22 function 2 "ATI SB700 USB2" rev 0x00: apic 3 int 23
usb3 at ehci2: USB revision 2.0
uhub3 at usb3 "ATI EHCI root hub" rev 2.00/1.00 addr 1
pchb1 at pci0 dev 24 function 0 "AMD AMD64 10h HyperTransport" rev 0x00
pchb2 at pci0 dev 24 function 1 "AMD AMD64 10h Address Map" rev 0x00
pchb3 at pci0 dev 24 function 2 "AMD AMD64 10h DRAM Cfg" rev 0x00
pchb4 at pci0 dev 24 function 3 "AMD AMD64 10h Misc Cfg" rev 0x00
pchb5 at pci0 dev 24 function 4 "AMD AMD64 10h Link Cfg" rev 0x00
usb4 at ohci0: USB revision 1.0
uhub4 at usb4 "ATI OHCI root hub" rev 1.00/1.00 addr 1
usb5 at ohci1: USB revision 1.0
uhub5 at usb5 "ATI OHCI root hub" rev 1.00/1.00 addr 1
usb6 at ohci2: USB revision 1.0
uhub6 at usb6 "ATI OHCI root hub" rev 1.00/1.00 addr 1
usb7 at ohci3: USB revision 1.0
uhub7 at usb7 "ATI OHCI root hub" rev 1.00/1.00 addr 1
isa0 at mainbus0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
uhub8 at uhub1 port 2 "vendor 0x0409 product 0x005a" rev 2.00/1.00 addr 2
uhub9 at uhub8 port 2 "vendor 0x2001 product 0xf103" rev 2.00/1.00 addr 3
uhub10 at uhub8 port 3 "vendor 0x0557 product 0x7000" rev 1.10/1.00 addr 4
uhidev0 at uhub10 port 1 configuration 1 interface 0 "ATEN SW2-RA
V1.0.072" rev 1.10/1.00 addr 5
uhidev0: iclass 3/1
ukbd0 at uhidev0
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev1 at uhub10 port 1 configuration 1 interface 1 "ATEN SW2-RA
V1.0.072" rev 1.10/1.00 addr 5
uhidev1: iclass 3/1
uhid at uhidev1 not configured
softraid0 at root
scsibus1 at softraid0: 256 targets
root on rd0a swap on rd0b dump on rd0b
syncing disks...
OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4188626944 (3994MB)
avail mem = 4057788416 (3869MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xbc27e018 (58 entries)
bios0: vendor American Megatrends Inc. version "1903" date 07/11/2013
bios0: ASUSTeK COMPUTER INC. M5A97 LE R2.0
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG HPET BGRT SSDT
acpi0: wakeup devices SBAZ(S4) PS2K(S3) PS2M(S3) UAR1(S4) P0PC(S4)
UHC1(S4) UHC2(S4) UHC4(S4) UHC6(S4) UHC7(S4) PC02(S4) PC03(S4)
PC04(S4) PC05(S4) PC06(S4) PC07(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Athlon(tm) II X2 250 Processor, 3010.51 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,NODEID,ITSC
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu0: AMD erratum 721 detected and fixed
cpu0: smt 0, core 0, package 0
mtrr: 

Re: npppd and pf

[Imre Oolberg]

Hi!

I must apologize i didt read thru your text attentiatively but i 
believe it is because of arp. Although i am just an user of npppd i run 
it already for some time and i think it works very well. Here are my 
notes, see if there are some use for them, hope Google translates it, 
http://www.auul.pri.ee/wiki/L2TP/IPSec_serveri_kasutamine_operatsioonis%C3%BCsteemiga_OpenBSD#ARP_proxy



Imre


On 2015-11-13 01:18, Jeremy wrote:
I'm adding more functionality to my firewall (OpenBSD 5.7) and have 
been
trying to configure PPTP VPN access for my Windows users. I have got 
npppd

running using the config below and can successfully authenticate and
establish a connection.

I am able to connect to the VPN from a windows PC but I can't reach 
the

internal hosts on the network.
I suspect I have some conflicts over my internal subnet and various
pf rules.
If I remove the antispoof rule, I am able to ping the firewall on its 
IP and

that of the pppx0 interface (192.168.7.128)
My internal em0 is on 192.168.7.0/24 which will overlap the pppx0
interface but I
am expecting my VPN users to appear on the same subnet. Is this valid 
?


I can ping the connected client on its IP 192.168.7.118 from the 
firewall.
I can occasionally ping some other hosts on the internal network but 
this

seems somewhat random and most of the time I can't reach any hosts.
(I'm running dhcpd on this box too if that makes a difference.)

I've scanned the man pages for npppd and pf but I think I'm missing 
something
more fundamental. Could someone please take a quick look and see if 
there is

anything obvious.

Thanks in advance.

=
#cat /etc/npppd/npppd.conf
tunnel PPTP protocol pptp
ipcp IPCP {
pool-address 192.168.7.95-192.168.7.127
dns-servers 192.168.7.1 8.8.8.8
}
interface pppx0 address 192.168.7.128 ipcp IPCP
authentication LOCAL type local {
users-file "/etc/npppd/npppd-users"
}
bind tunnel from PPTP authenticated by LOCAL to pppx0


=
# ifconfig pppx0
pppx0: flags=8051 mtu 1400
description: jeremy
priority: 0
groups: pppx
inet 192.168.7.128 --> 192.168.7.118 netmask 0x



# cat /etc/pf.conf
#   $OpenBSD: pf.conf,v 1.54 2014/08/23 05:49:42 deraadt Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf

# macros
int_if="em0"
ext_if="em1"

tcp_services="{ 22, 113 }"
udp_services="{ 161 }"
mail_services="{ 25, 587, 993, 995 }"
web_services="{ 80, 443 }"
vpn_pptp="{ 1723 }"

icmp_types="echoreq"

web_server = "192.168.7.77"
mail_server = "192.168.7.77"

# options
set block-policy return
set loginterface egress
set skip on lo

# FTP Proxy rules
anchor "ftp-proxy/*"
pass in quick on $int_if inet proto tcp to any port ftp divert-to
127.0.0.1 port 8021

# match rules
match in all scrub (no-df random-id max-mss 1440)
match out on egress inet from $int_if:network to any nat-to 
(egress:0)


# filter rules
block in log

pass out quick
antispoof quick for { lo $int_if }

# Allow access to services running on the firewall
pass in on egress inet proto tcp from any to (egress) port
$tcp_services flags S/SA keep state
pass in on egress inet proto udp from any to (egress) port 
$udp_services


# VPN Rules
pass in quick inet proto gre all
pass in log on pppx
pass in quick on egress inet proto tcp from any to (egress) port 
$vpn_pptp


# Redirect traffic to the interior servers
pass in on egress inet proto tcp to (egress) port $web_services
rdr-to $web_server synproxy state
pass in on egress inet proto tcp to (egress) port $mail_services
rdr-to $mail_server

pass in inet proto icmp all icmp-type $icmp_types

pass in on $int_if
===