Messages

I know this is like an almost 2 years old post but I still would like to post an update in case anyone is interested: today out of curiosity I installed OPNSense 22.7 and gave it another try after using Ubiquiti UDMP for almost 2 years without issue. And it appears the ipv6 is back working normally with OPNSense with minimal config as before.

I later learned that both Wave G and Comcast provide service in our building through the same RJ45 port in each residential unit so it is probably my ISP messed something up at the switch and caused some advertise "pollution". Perhaps due to different dhcpv6 client is being used between OPNSense and UDMP(the latter uses odhcp6c) that only OPNSense was impacted...

Thanks. Yeah I was already out of idea too. I just don't know why it suddenly stopped working :( I posted two screenshots which are the only config I manually changed, everything else is blank/default.

I will keep this installation intact and keep playing with it and post update if I discover anything new. Thank you again!

Yeah I was using unassisted for SLAAC. I know what you are saying so to make sure it wasn't anything tied to my old OPNsense box broken I spoofed the mac to pretend to be a new router but still didin't work.... Thanks!

hmmm... so I switched up to ubiquiti udm pro and the ipv6 was set up successfully.... Guess it is still some configuration issue of my OPNsense box...

Thanks for the reply. No I wasn't bridging anything: I live in a building that each unit has regular RJ45 port and one simply plugs WAN port into it. My guess is that the optics fiber is terminated in the build then each unit joins the network..

Yeah I was confused as hell too... like why two advertises saying the opposite thing and it does look like the DNS server in 2nd ad belongs to comcast.... (and yes I am on Wave G:)

Forgot to say that I have changed the PD size to /64 and still the same result...

Hi, so I recently my ipv6 stopped working without any configuration change. I have a very simple setup: WAN (igb0) using dhcp6c requesting a /60 from my ISP and LAN(igb1) is tracking it. This used to work just fine however I noticed since some time ago the LAN and all clients in LAN stopped getting any ipv6, the WAN on the other hand still has a working /64 address and I can ping ipv6 google address on the router itself.

I tried to load the config in a live USB running 20.1 (I am running latest 20.7) and still seeing the issue so I don't think it is anything broken in OPNSense at least: (the log is reverse time order: first line being latest)

Code Select Expand


2020-12-14T10:02:38 dhcp6c[3635] dhcp6c REQUEST on igb0 - running newipv6
2020-12-14T10:02:38 dhcp6c[49330] dhcp6c REQUEST on igb0
2020-12-14T10:02:38 dhcp6c[86377] executes /var/etc/dhcp6c_wan_script.sh
2020-12-14T10:02:38 dhcp6c[86377] reset a timer on igb0, state=INIT, timeo=0, retrans=541
2020-12-14T10:02:38 dhcp6c[86377] remove an IA: PD-0
2020-12-14T10:02:38 dhcp6c[86377] IA PD-0 is invalidated
2020-12-14T10:02:38 dhcp6c[86377] status code for PD-0: no prefixes
2020-12-14T10:02:38 dhcp6c[86377] make an IA: PD-0
2020-12-14T10:02:38 dhcp6c[86377] nameserver[1] 2001:558:feed::2
2020-12-14T10:02:38 dhcp6c[86377] nameserver[0] 2001:558:feed::1
2020-12-14T10:02:38 dhcp6c[86377] Received REPLY for REQUEST
2020-12-14T10:02:38 dhcp6c[86377] get DHCP option DNS, len 32
2020-12-14T10:02:38 dhcp6c[86377] preference: 255
2020-12-14T10:02:38 dhcp6c[86377] get DHCP option preference, len 1
2020-12-14T10:02:38 dhcp6c[86377] DUID: 00:02:00:00:d2:6d:93:a8:41:89:93:2b:dd:28
2020-12-14T10:02:38 dhcp6c[86377] get DHCP option client ID, len 14
2020-12-14T10:02:38 dhcp6c[86377] DUID: 00:01:00:01:27:67:68:10:5c:7d:7d:2a:5a:a1
2020-12-14T10:02:38 dhcp6c[86377] get DHCP option server ID, len 14
2020-12-14T10:02:38 dhcp6c[86377] status code: no prefixes
2020-12-14T10:02:38 dhcp6c[86377] get DHCP option status code, len 67
2020-12-14T10:02:38 dhcp6c[86377] IA_PD: ID=0, T1=0, T2=0
2020-12-14T10:02:38 dhcp6c[86377] get DHCP option IA_PD, len 83
2020-12-14T10:02:38 dhcp6c[86377] receive reply from fe80::10:18ff:fe0c:757%igb0 on igb0
2020-12-14T10:02:38 dhcp6c[86377] reset a timer on igb0, state=REQUEST, timeo=0, retrans=937
2020-12-14T10:02:38 dhcp6c[86377] send request to ff02::1:2%igb0
2020-12-14T10:02:38 dhcp6c[86377] set IA_PD
2020-12-14T10:02:38 dhcp6c[86377] set status code
2020-12-14T10:02:38 dhcp6c[86377] set option request (len 4)
2020-12-14T10:02:38 dhcp6c[86377] set elapsed time (len 2)
2020-12-14T10:02:38 dhcp6c[86377] set server ID (len 14)
2020-12-14T10:02:38 dhcp6c[86377] set client ID (len 14)
2020-12-14T10:02:38 dhcp6c[86377] a new XID (960387) is generated
2020-12-14T10:02:38 dhcp6c[86377] Sending Request
2020-12-14T10:02:38 dhcp6c[86377] server ID: 00:01:00:01:27:67:68:10:5c:7d:7d:2a:5a:a1, pref=255
2020-12-14T10:02:38 dhcp6c[86377] get DHCP option DNS, len 32
2020-12-14T10:02:38 dhcp6c[86377] preference: 255
2020-12-14T10:02:38 dhcp6c[86377] get DHCP option preference, len 1
2020-12-14T10:02:38 dhcp6c[86377] DUID: 00:02:00:00:d2:6d:93:a8:41:89:93:2b:dd:28
2020-12-14T10:02:38 dhcp6c[86377] get DHCP option client ID, len 14
2020-12-14T10:02:38 dhcp6c[86377] DUID: 00:01:00:01:27:67:68:10:5c:7d:7d:2a:5a:a1
2020-12-14T10:02:38 dhcp6c[86377] get DHCP option server ID, len 14
2020-12-14T10:02:38 dhcp6c[86377] status code: no prefixes
2020-12-14T10:02:38 dhcp6c[86377] get DHCP option status code, len 67
2020-12-14T10:02:38 dhcp6c[86377] IA_PD: ID=0, T1=0, T2=0
2020-12-14T10:02:38 dhcp6c[86377] get DHCP option IA_PD, len 83
2020-12-14T10:02:38 dhcp6c[86377] receive advertise from fe80::10:18ff:fe0c:757%igb0 on igb0
2020-12-14T10:02:38 dhcp6c[86377] reset timer for igb0 to 0.997628
2020-12-14T10:02:38 dhcp6c[86377] server ID: 00:03:00:01:58:97:bd:19:62:80, pref=-1
2020-12-14T10:02:38 dhcp6c[86377] get DHCP option domain search list, len 25
2020-12-14T10:02:38 dhcp6c[86377] get DHCP option DNS, len 32
2020-12-14T10:02:38 dhcp6c[86377] IA_PD prefix: 2604:4080:11ac:8bb0::/60 pltime=1800 vltime=137593572298256
2020-12-14T10:02:38 dhcp6c[86377] get DHCP option IA_PD prefix, len 25
2020-12-14T10:02:38 dhcp6c[86377] IA_PD: ID=0, T1=900, T2=1440
2020-12-14T10:02:38 dhcp6c[86377] get DHCP option IA_PD, len 41
2020-12-14T10:02:38 dhcp6c[86377] DUID: 00:02:00:00:d2:6d:93:a8:41:89:93:2b:dd:28
2020-12-14T10:02:38 dhcp6c[86377] get DHCP option client ID, len 14
2020-12-14T10:02:38 dhcp6c[86377] DUID: 00:03:00:01:58:97:bd:19:62:80
2020-12-14T10:02:38 dhcp6c[86377] get DHCP option server ID, len 10
2020-12-14T10:02:38 dhcp6c[86377] receive advertise from fe80::5a97:bdff:fe19:62bf%igb0 on igb0
2020-12-14T10:02:38 dhcp6c[86377] reset a timer on igb0, state=SOLICIT, timeo=0, retrans=1029
2020-12-14T10:02:38 dhcp6c[86377] send solicit to ff02::1:2%igb0
2020-12-14T10:02:38 dhcp6c[86377] set IA_PD
2020-12-14T10:02:38 dhcp6c[86377] set IA_PD prefix
2020-12-14T10:02:38 dhcp6c[86377] set option request (len 4)
2020-12-14T10:02:38 dhcp6c[86377] set elapsed time (len 2)
2020-12-14T10:02:38 dhcp6c[86377] set client ID (len 14)
2020-12-14T10:02:38 dhcp6c[86377] a new XID (e121c) is generated
2020-12-14T10:02:38 dhcp6c[86377] Sending Solicit
2020-12-14T10:02:38 dhcp6c[86377] got an expected reply, sleeping.
2020-12-14T10:02:38 dhcp6c[86377] removing server (ID: 00:03:00:01:58:97:bd:19:62:80)
2020-12-14T10:02:38 dhcp6c[86377] removing server (ID: 00:01:00:01:27:67:68:10:5c:7d:7d:2a:5a:a1)
2020-12-14T10:02:38 dhcp6c[86377] removing an event on igb0, state=REQUEST
2020-12-14T10:02:38 dhcp6c[86377] script "/var/etc/dhcp6c_wan_script.sh" terminated
2020-12-14T10:02:35 dhcp6c[59994] dhcp6c REQUEST on igb0 - running newipv6
2020-12-14T10:02:35 dhcp6c[44275] dhcp6c REQUEST on igb0
2020-12-14T10:02:35 dhcp6c[86377] executes /var/etc/dhcp6c_wan_script.sh


So it seems that I was able to get a /60 PD based on this line:

Code Select Expand


2020-12-14T10:02:38 dhcp6c[86377] IA_PD prefix: 2604:4080:11ac:8bb0::/60 pltime=1800 vltime=137593572298256


However no ipv6 for LAN (igb1) and I wonder if these two lines are related:

Code Select Expand


2020-12-14T10:02:38 dhcp6c[86377] IA PD-0 is invalidated
2020-12-14T10:02:38 dhcp6c[86377] status code for PD-0: no prefixes


Doing tcpdump on the router has the following interesting communication:

Code Select Expand


root@OPNsense:~ # tcpdump -i igb0 -n -vv '(udp port 546 or 547) or icmp6'
tcpdump: listening on igb0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:07:10.559447 IP6 (hlim 1, next-header UDP (17) payload length: 89) fe80::4262:31ff:fe08:8c1c.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=afd2bb (client-ID vid 0000d26d93a84189) (elapsed-time 0) (option-request DNS-server DNS-search-list) (IA_PD IAID:0 T1:0 T2:0 (IA_PD-prefix ::/60 pltime:4294967295 vltime:4294967295)))
10:07:10.561580 IP6 (class 0xe0, hlim 255, next-header UDP (17) payload length: 154) fe80::5a97:bdff:fe19:62bf.547 > fe80::4262:31ff:fe08:8c1c.546: [udp sum ok] dhcp6 advertise (xid=afd2bb (server-ID hwaddr type 1 5897bd196280) (client-ID vid 0000d26d93a84189) (IA_PD IAID:0 T1:900 T2:1440 (IA_PD-prefix 2604:4080:11ac:8bb0::/60 pltime:1800 vltime:3600)) (DNS-server 2607:f060:2::1 2607:f060:2:1::1) (DNS-search-list users.condointernet.net.))
10:07:10.566420 IP6 (flowlabel 0x6a592, hlim 64, next-header UDP (17) payload length: 176) fe80::10:18ff:fe0c:757.547 > fe80::4262:31ff:fe08:8c1c.546: [udp sum ok] dhcp6 advertise (xid=afd2bb (IA_PD IAID:0 T1:0 T2:0 (status-code NoPrefixAvail)) (server-ID hwaddr/time type 1 time 661088272 5c7d7d2a5aa1) (client-ID vid 0000d26d93a84189) (preference 255) (DNS-server 2001:558:feed::1 2001:558:feed::2))


Again I am not sure if the NoPrefixAvail status-code is responsible... Is it possible or is there anyway to prove that my ISP changed something causing my ipv6 configuration stop working? Thanks!

So I was confused by this for a long long time too and until recently I came upon your post and the following discussion. I did some experiment by dumping the pf command on my set up (identical to you, a LAN and a guest VLAN) and I think what @hbc said in the first reply is very correct: out is almost only used in blocking outbound traffic from WAN port.

In short: in or out is relative to the firewall box itself, not the specific interface the rule is set on. Therefore if you are playing with rules blocking between your LAN and another VLAN, "out" will never be matched since the traffic does not go out of the firewall itself.

Here is a quote from "Building firewall with OpenBSD and pf" and hope it can clarify the confusion:

8.1.3 Inbound or Outbound (in, out)?

The next required keyword that appears after either the block (followed by optional drop, return-icmp, return-icmp6, return-rst,or return keywords) or the pass keyword is the direction keyword.There are two direction keywords you can use: in or out. They are known to cause some confusion, especially when the firewall is equipped with more than one network interface, and when NAT rules are used along with filtering rules.The key to understanding when a packet matches either the in or the out rule is remembering that these directions are relative to the firewall itself. Ifa packet is sent from an external host to the firewall, it matches the in rule on the firewall external interface; when it is sent from the firewall itself, it matches the out on the external interface. Similarly, packets sent from internal hosts to the firewall and destined to external hosts will match in rules on the interface connecting your private network segment to the firewall and out rules on the firewall external interface.

Ok so after reading the book "Building firewall with OpenBSD and pf" and did some experiment on my opnsense box, I think in some sense both quotes are correct. Here is a quote from the book regarding "direction"

8.1.3 Inbound or Outbound (in, out)?

The next required keyword that appears after either the block (followed by optional drop, return-icmp, return-icmp6, return-rst,or return keywords) or the pass keyword is the direction keyword.There are two direction keywords you can use: in or out. They are known to cause some confusion, especially when the firewall is equipped with more than one network interface, and when NAT rules are used along with filtering rules.The key to understanding when a packet matches either the in or the out rule is remembering that these directions are relative to the firewall itself. Ifa packet is sent from an external host to the firewall, it matches the in rule on the firewall external interface; when it is sent from the firewall itself, it matches the out on the external interface. Similarly, packets sent from internal hosts to the firewall and destined to external hosts will match in rules on the interface connecting your private network segment to the firewall and out rules on the firewall external interface.

I think my original confusion was that, exactly as the book says, "in" and "out" is relevant to the firewall as a system, not the interface the traffic is passing. So the online manual in this sense can certainly be interpreted as "the traffic originates from interface IF1 because that is where the traffic is received by the firewall box"

[receiving]

Hi, thanks for reading my post :) I am using OPNsense 20.1.7-amd64 and I notice that in the Firewall->Rules->LAN (could be any interface), if I edit any rule and also click the small "i" icon next to "Direction" tab, an instructional message appears:

Direction of the traffic. The default policy is to filter inbound traffic, which sets the policy to the interface originally receiving the traffic.

However if I read the online manual https://docs.opnsense.org/manual/firewall.html, it says

our default is to filter on incoming direction. In which case you would set the policy on the interface where the traffic originates from.

I think if I understood it correctly, the one on the web interface sounds correct and the online manual perhaps is a little misleading. Should this be fixed? Thanks :)