Re: Conundrum with pf
On Mon, Aug 20, 2018 at 09:21:54PM +, Walt wrote: > I don't really remember for sure from the last time I did a fresh install, > but I think that /etc/sysctl.conf isn't there by default -- if you need it, > you have to create it yourself. > > Walt > Having done multiple fresh installs over the last few months as I got my home network in shape, I can confirm that /etc/sysct.conf is not present by default and needs to be created manually if needed. -- Jon Tabor tab...@obsolete.site http://obsolete.site 'There is a saying: There is no such thing as overkill. There is only “Open fire!” and “Reloading!”' ― John Ringo, The Hot Gate
Re: Conundrum with pf
On August 20, 2018 3:58 PM, Jay Hart wrote: > Well, turned out that was indeed the issue, but only because [for some > reason] sysctl.conf did not > exist on the box...which I think instead of deleting the backup file, I must > have by mistake > deleted /etc/sysctl.conf. A quick copy over and all is well. > > I was tired yesterday and got to the point I wasn't thinking straight, so I > posted to the list to > see if the issue could be narrowed down a bit... > > dhcpd would not start due to it looking at the wrong interface, a result of > not editing > rc.conf.local properly... > > All is well and new box is online... 48 hour minimum test started now... > > THANK YOU, THANK YOU, THANK YOU!!! > > Jay I don't really remember for sure from the last time I did a fresh install, but I think that /etc/sysctl.conf isn't there by default -- if you need it, you have to create it yourself. Walt
Re: Conundrum with pf
>>> 2. I have a fully working pf.conf file on my current server, copied it >>> over to my new server and >>> made a few corrections since the interfaces are different, but thats >>> about it. The problem is >>> this: the new router boots up and dhclient goes and gets a lease, and >>> I have an ip address. I can >>> ping external to the box and also can do a wget and download a file, >>> so I know the box is online. >>> My internal network though, can't see a thing past the external >>> interface, can't ping, or resolve >>> anything. > > it sounds like the new box needs to have the ip forwarding sysctl > enabled (theres another one for ipv6) > > that can be verified if "net.inet.ip.forwarding=1" is in > /etc/sysctl.conf > > might be a good idea to review all the little details on this page: > https://www.openbsd.org/faq/pf/example1.html > > Well, turned out that was indeed the issue, but only because [for some reason] sysctl.conf did not exist on the box...which I think instead of deleting the backup file, I must have by mistake deleted /etc/sysctl.conf. A quick copy over and all is well. I was tired yesterday and got to the point I wasn't thinking straight, so I posted to the list to see if the issue could be narrowed down a bit... dhcpd would not start due to it looking at the wrong interface, a result of not editing rc.conf.local properly... All is well and new box is online... 48 hour minimum test started now... THANK YOU, THANK YOU, THANK YOU!!! Jay
Re: Conundrum with pf
>>> 2. I have a fully working pf.conf file on my current server, copied it >>> over to my new server and >>> made a few corrections since the interfaces are different, but thats >>> about it. The problem is >>> this: the new router boots up and dhclient goes and gets a lease, and >>> I have an ip address. I can >>> ping external to the box and also can do a wget and download a file, >>> so I know the box is online. >>> My internal network though, can't see a thing past the external >>> interface, can't ping, or resolve >>> anything. > > it sounds like the new box needs to have the ip forwarding sysctl > enabled (theres another one for ipv6) > > that can be verified if "net.inet.ip.forwarding=1" is in > /etc/sysctl.conf > > might be a good idea to review all the little details on this page: > https://www.openbsd.org/faq/pf/example1.html > I just might have missed the ip forwarding step. I'll check that and the details on the page you suggested and get back to you. Thanks, Jay
Re: Conundrum with pf
2. I have a fully working pf.conf file on my current server, copied it over to my new server and made a few corrections since the interfaces are different, but thats about it. The problem is this: the new router boots up and dhclient goes and gets a lease, and I have an ip address. I can ping external to the box and also can do a wget and download a file, so I know the box is online. My internal network though, can't see a thing past the external interface, can't ping, or resolve anything. it sounds like the new box needs to have the ip forwarding sysctl enabled (theres another one for ipv6) that can be verified if "net.inet.ip.forwarding=1" is in /etc/sysctl.conf might be a good idea to review all the little details on this page: https://www.openbsd.org/faq/pf/example1.html
Re: Conundrum with pf
Not a pf magician, but think I found a typo below that could be the problem.
On Aug 19, 2018 6:51 PM, Jay Hart wrote:
>
> Hello all,
>
> I finally got my "new" server online, still have to disable inteldrm to get
> it to boot though.
>
> Ran into two issues upon initial bootup:
>
> 1. DHCPD failed to start, trying to troubleshoot that one.
>
> 2. I have a fully working pf.conf file on my current server, copied it over
> to my new server and
> made a few corrections since the interfaces are different, but thats about
> it. The problem is
> this: the new router boots up and dhclient goes and gets a lease, and I have
> an ip address. I can
> ping external to the box and also can do a wget and download a file, so I
> know the box is online.
> My internal network though, can't see a thing past the external interface,
> can't ping, or resolve
> anything. The resolv.conf files look ok (they match the old box files). My
> thinking is that for
> some reason, pf doesn't like my current config file. Both boxes are fully
> patched 6.3 versions.
> One is 32-bit, the other is 64-bit.
>
> On the new router, re0 is the external interface, re1 is internal interface.
> Assuming with DHCPD
> enabled, it would monitor the internal interface for dhcp requests from my
> internal machines. If
> the internal interface was having a problem initializing, would that prevent
> dhcpd from starting
> up. I'm wondering if both interfaces can be enabled at the same time. They
> SHOULD be able to, but
> with this motherboard, who knows...
>
> I'm posting my pf.conf file, other suggestions that could help me narrow the
> scope of the problem
> are appreciated.
>
> # $OpenBSD: pf.conf,v 1.54 2014/08/23 05:49:42 deraadt Exp $
> #
> # See pf.conf(5) and /etc/examples/pf.conf
>
> int_if = "re0"
Should that be "re1"
> www_ad = "192.168.1.99"
> icmp_types="echoreq"
> NoRouteIPs = "{127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8}"
>
> set block-policy return
> set loginterface egress
> set skip on lo
>
> #Protection
> antispoof quick for { lo $int_if }
Don't remember what antispoof does but if you do it on your egress if re0 it
will probably do bad stuff.
> block in quick on egress from $NoRouteIPs to any
> block out quick on egress from any to $NoRouteIPs
>
> #filter rules and anchor for ftp-proxy
> anchor "ftp-proxy/*"
>
> #rule needed to redirect ftp connection for ftp-proxy
> pass in quick inet proto tcp to port ftp divert-to 127.0.0.1 port 8021
>
> #match rules
> match out on egress inet from !(egress) to any nat-to (egress:0)
>
> block in log
> pass out quick
>
> #next rule passes http-https traffic to the web/email server
> pass in on egress inet proto tcp from any to (egress) port {80 443} rdr-to
> $www_ad synproxy state
>
> #traceroute rule (for IPv4)
> pass out on egress inet proto udp to port 33433:33626
>
> #next rule redirects smtp traffic to the email server
> pass in on egress inet proto tcp from any to (egress) port 25 rdr-to $www_ad
>
> #pass in certain types of ICMP traffic
> pass in inet proto icmp all icmp-type $icmp_types
>
>
Re: Conundrum with pf
The pf.conf file below is from my working router. If you read my post, and
then look at the
interfaces, you will then tell me that is wrong. This works on my current
router, but not the new
one, even though the interfaces are correct for that box, ad pf.conf has been
updated to reflect
that.
TIA,
Jay
> Hello all,
>
> I finally got my "new" server online, still have to disable inteldrm to get
> it to boot though.
>
> Ran into two issues upon initial bootup:
>
> 1. DHCPD failed to start, trying to troubleshoot that one.
>
> 2. I have a fully working pf.conf file on my current server, copied it over
> to my new server and
> made a few corrections since the interfaces are different, but thats about
> it. The problem is
> this: the new router boots up and dhclient goes and gets a lease, and I have
> an ip address. I can
> ping external to the box and also can do a wget and download a file, so I
> know the box is online.
> My internal network though, can't see a thing past the external interface,
> can't ping, or resolve
> anything. The resolv.conf files look ok (they match the old box files). My
> thinking is that for
> some reason, pf doesn't like my current config file. Both boxes are fully
> patched 6.3 versions.
> One is 32-bit, the other is 64-bit.
>
> On the new router, re0 is the external interface, re1 is internal interface.
> Assuming with DHCPD
> enabled, it would monitor the internal interface for dhcp requests from my
> internal machines. If
> the internal interface was having a problem initializing, would that prevent
> dhcpd from starting
> up. I'm wondering if both interfaces can be enabled at the same time. They
> SHOULD be able to, but
> with this motherboard, who knows...
>
> I'm posting my pf.conf file, other suggestions that could help me narrow the
> scope of the problem
> are appreciated.
>
> # $OpenBSD: pf.conf,v 1.54 2014/08/23 05:49:42 deraadt Exp $
> #
> # See pf.conf(5) and /etc/examples/pf.conf
>
> int_if = "re0"
> www_ad = "192.168.1.99"
> icmp_types="echoreq"
> NoRouteIPs = "{127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8}"
>
> set block-policy return
> set loginterface egress
> set skip on lo
>
> #Protection
> antispoof quick for { lo $int_if }
> block in quick on egress from $NoRouteIPs to any
> block out quick on egress from any to $NoRouteIPs
>
> #filter rules and anchor for ftp-proxy
> anchor "ftp-proxy/*"
>
> #rule needed to redirect ftp connection for ftp-proxy
> pass in quick inet proto tcp to port ftp divert-to 127.0.0.1 port 8021
>
> #match rules
> match out on egress inet from !(egress) to any nat-to (egress:0)
>
> block in log
> pass out quick
>
> #next rule passes http-https traffic to the web/email server
> pass in on egress inet proto tcp from any to (egress) port {80 443} rdr-to
> $www_ad synproxy state
>
> #traceroute rule (for IPv4)
> pass out on egress inet proto udp to port 33433:33626
>
> #next rule redirects smtp traffic to the email server
> pass in on egress inet proto tcp from any to (egress) port 25 rdr-to $www_ad
>
> #pass in certain types of ICMP traffic
> pass in inet proto icmp all icmp-type $icmp_types
>
>
>
Conundrum with pf
Hello all,
I finally got my "new" server online, still have to disable inteldrm to get it
to boot though.
Ran into two issues upon initial bootup:
1. DHCPD failed to start, trying to troubleshoot that one.
2. I have a fully working pf.conf file on my current server, copied it over to
my new server and
made a few corrections since the interfaces are different, but thats about it.
The problem is
this: the new router boots up and dhclient goes and gets a lease, and I have an
ip address. I can
ping external to the box and also can do a wget and download a file, so I know
the box is online.
My internal network though, can't see a thing past the external interface,
can't ping, or resolve
anything. The resolv.conf files look ok (they match the old box files). My
thinking is that for
some reason, pf doesn't like my current config file. Both boxes are fully
patched 6.3 versions.
One is 32-bit, the other is 64-bit.
On the new router, re0 is the external interface, re1 is internal interface.
Assuming with DHCPD
enabled, it would monitor the internal interface for dhcp requests from my
internal machines. If
the internal interface was having a problem initializing, would that prevent
dhcpd from starting
up. I'm wondering if both interfaces can be enabled at the same time. They
SHOULD be able to, but
with this motherboard, who knows...
I'm posting my pf.conf file, other suggestions that could help me narrow the
scope of the problem
are appreciated.
# $OpenBSD: pf.conf,v 1.54 2014/08/23 05:49:42 deraadt Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf
int_if = "re0"
www_ad = "192.168.1.99"
icmp_types="echoreq"
NoRouteIPs = "{127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8}"
set block-policy return
set loginterface egress
set skip on lo
#Protection
antispoof quick for { lo $int_if }
block in quick on egress from $NoRouteIPs to any
block out quick on egress from any to $NoRouteIPs
#filter rules and anchor for ftp-proxy
anchor "ftp-proxy/*"
#rule needed to redirect ftp connection for ftp-proxy
pass in quick inet proto tcp to port ftp divert-to 127.0.0.1 port 8021
#match rules
match out on egress inet from !(egress) to any nat-to (egress:0)
block in log
pass out quick
#next rule passes http-https traffic to the web/email server
pass in on egress inet proto tcp from any to (egress) port {80 443} rdr-to
$www_ad synproxy state
#traceroute rule (for IPv4)
pass out on egress inet proto udp to port 33433:33626
#next rule redirects smtp traffic to the email server
pass in on egress inet proto tcp from any to (egress) port 25 rdr-to $www_ad
#pass in certain types of ICMP traffic
pass in inet proto icmp all icmp-type $icmp_types
