hi Zack and Stuart
thanks for the replies
i will responded to you both in this reply
Zack
---------------------------------------------------------------
>I cannot comment on PPPoE, but I do know you have misspelled
>"persistent" in your dhcpcd.conf(5) file. I don't know if it will help,
it's the correct spelling as in the man page and the example config file
>but you may try explicitly assigning an IAID to pppoe0 and perhaps use
>that same IAID for ia_na and ia_pd. You say you are delegated a /48,
>but you don't state how you know that.
i'm going by the information given to by zen
>You may want to modify your
>ia_pd line and specify the prefix length to be delegated to you as
>well as the prefix lengths you want assigned to em0 and em1. For
>example, something like:
>
>interface pppoe0
> iaid 0
> ia_na 0
> ia_pd 0/::/48 em0/0/64 em1/1/64
> ipv6rs
tried it but no change, ipv6 address only applied to pppoe0 interface
>You may want to include the output of dhcpcd -U pppoe0
doas dhcpcd -U pppoe0
reason=CARRIER
interface=pppoe0
protocol=link
if_configured=true
ifcarrier=up
ifmetric=0
ifwireless=0
ifflags=35153
ifmtu=1492
reason=ROUTERADVERT
interface=pppoe0
protocol=ra
nd1_from=fe80::4afd:8eff:feaa:a4dd
nd1_acquired=821
nd1_now=1433
nd1_hoplimit=64
nd1_flags=O
nd1_lifetime=1800
nd1_source_address=48fd8eaaa4dd
nd1_mtu=1492
nd1_prefix_information1_length=64
nd1_prefix_information1_flags=LA
nd1_prefix_information1_vltime=259200
nd1_prefix_information1_pltime=172800
nd1_prefix_information1_prefix=2a02:8011:d000:57d::
nd1_addr1=2a02:8011:d000:57d:200::1/64
>and perhaps a
>snippet of /var/log/daemon showing the exchange between dhcpcd and your
>ISP.
Jan 22 16:05:15 imhotep dhcpcd[69138]: pppoe0: carrier acquired
Jan 22 16:05:15 imhotep dhcpcd[69138]: pppoe0: IAID 00:00:00:06
Jan 22 16:05:15 imhotep dhcpcd[69138]: pppoe0: IA type 3 IAID 00:00:00:00
Jan 22 16:05:15 imhotep dhcpcd[69138]: pppoe0: IA type 25 IAID 00:00:00:00
Jan 22 16:05:15 imhotep dhcpcd[69138]: pppoe0: soliciting a DHCPv6 lease
Jan 22 16:05:15 imhotep dhcpcd[69138]: pppoe0: soliciting an IPv6 router
Jan 22 16:05:15 imhotep dhcpcd[69138]: pppoe0: Router Advertisement from fe80::4afd:8eff:feaa:a4dd
Jan 22 16:05:15 imhotep dhcpcd[69138]: pppoe0: adding address 2a02:8011:d000:57d:200::1/64
Jan 22 16:05:15 imhotep dhcpcd[69138]: pppoe0: adding route to 2a02:8011:d000:57d::/64
Jan 22 16:05:15 imhotep dhcpcd[69138]: pppoe0: adding default route via fe80::4afd:8eff:feaa:a4dd
>You should probably include /etc/hostname.pppoe0 as well.
cat /etc/hostname.pppoe0
!/bin/sleep 10
inet 0.0.0.0 255.255.255.255 NONE mtu 1500 \
pppoedev bge0 authproto chap \
authname 'username' authkey 'password' up
dest 0.0.0.1
inet6 eui64
!/sbin/route add default -ifp pppoe0 0.0.0.1
>You don't have "pass quick log on em1 all" in your pf(4) rules like you
>do with em0, so you may want to make sure IPv6 communication is not
>being blocked on it.
em1 will be my demiliterized zone
the network is not used yet so i've not configured anything for it yet,
just concentrating on the lan
>Also, you may want to experiment with relaxing
>your ICMPv6 rules, at least temporarily. You appear to be allowing the
>necessary message types; but unless you know ICMPv6 well, you could be
>blocking more than you should. Finally, you may be overly restrictive
>with your DHCPv6 rules. For example, RFC 8415 says nothing about what
>_source_ ports clients and servers MUST use but only the _destination_
>ports-a similar issue was addressed by Florian Obser in dhcpleased(8)
block in log on egress inet6 proto icmp6 all
pass in log $inet6 proto icmp6 all icmp6-type { echorep echoreq unreach }
pass out log quick on egress inet6
pass in log on egress inet6 proto icmp6 all \
icmp6-type { routeradv neighbrsol neighbradv }
pass in log on egress inet6 proto udp \
from fe80::/10 port dhcpv6-server \
to fe80::/10 port dhcpv6-client \
no state
how should i simplify,
should i just remove the fe80::/10 ?
------------------------------------------------------------
Stuart
------------------------------------------------------------
>I doubt it will help, but you shouldn't have "inet6 autoconf" on the
>interfaces where you expect to assign from PD.
have removed it of em0 and em1
>> i have the following in dhcpcd.conf
>
>> ipv6only
>> noipv6rs
>> waitip 6
>> duid
>> persistant
>> vendorclassid
>> option interface_mtu
>> option host_name
>> option rapid_commit
>> require dhcp_server_identifier
>> slaac private
>> script ""
>> allowinterfaces pppoe0 em0 em1
>> interface pppoe0
>> ipv6rs
>> ia_na 1
>> ia_pd 2 em0/1 em1/2
>
>Do you need all of that? Try cutting back to just what's in the example
>in dhcpcd's pkg-readme. It worked with Zen last time I tried it
cat /etc/dhcpcd.conf
ipv6only
noipv6rs
duid
persistent
option rapid_commit
script ""
allowinterfaces pppoe0
interface pppoe0
ia_na 0
ia_pd 0/::/48 em0/0/64 em1/1/64
ipv6rs
>Also don't discount that Zen might have broken your v6 config, I gave up
>using their v6 in the end and shifted it to a tunnel via work instead
>because I got fed up asking them to fix it after 2 or 3 times ..
phoned them, they say that my /64 and my /48 are routed to me.
>> SafeIcmpTypes = "{ echorep, echoreq, unreach }"
>> pass quick log on em0 all
>> pass log inet6 proto icmp6 all icmp6-type $SafeIcmpTypes
>> pass out log inet6 proto udp from any port dhcpv6-client to any port dhcpv6-server no state
>> pass in on egress inet6 proto icmp6 all \
>> icmp6-type { routeradv neighbrsol neighbradv }
>>
>> pass in on egress inet6 proto udp \
>> from fe80::/10 port dhcpv6-server \
>> to fe80::/10 port dhcpv6-client \
>> no state
>
>why the "no state" for these?
https://lipidity.com/openbsd/router/
states
The DHCPv6 request is sent to a multicast address
and the ISP router replies with its own link-local address as the source address,
so state matching doesn't catch it. An explicit pass rule is required for the reply.
and while i'm at it
was wondering about the following
match in all scrub (no-df random-id min-ttl 64 max-mss 1440)
the following page states that PMTU works exactly using DF
should i be using no-df in the scrub rule ?
https://serverfault.com/questions/412083/openbsd-pf-match-in-all-scrub-no-df-causes-https-to-be-unreachable-on-mobile
shadrock
No comments:
Post a Comment