Messages

clearing the states seems to have done it.

I did go back and create an alias and applied it to the NAT rule.  Personally I would have thought "block rules" applied to an interface would have been processed before NAT, I guess there is a reason it isn't. I need to look at the documentation to see what the processing order is.

Thanks, I knew this shouldn't have been very difficult.

Jeff

With the NAT disabled I do see much of the traffic being blocked but not all of it...

Code Select Expand

# tcpdump "tcp[tcpflags] & (tcp-ack) = 0" and port 443 and net 170.239.160.0/24 -n -c20
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp6s0f0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
16:08:41.852675 IP 170.239.160.240.18672 > 172.18.19.2.https: Flags [S], seq 1368460929, win 64240, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
16:08:41.854005 IP 170.239.160.240.18672 > 172.18.19.2.https: Flags [S], seq 1368460929, win 64240, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
16:08:41.854053 IP 170.239.160.240.18672 > 172.18.19.2.https: Flags [S], seq 1368460929, win 64240, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
16:08:44.481879 IP 170.239.160.4.51266 > 172.18.19.2.https: Flags [S], seq 465277211, win 65535, options [mss 1460,sackOK,TS val 2434516034 ecr 0,nop,wscale 8], length 0
16:08:44.481880 IP 170.239.160.4.51266 > 172.18.19.2.https: Flags [S], seq 465277211, win 65535, options [mss 1460,sackOK,TS val 2434516034 ecr 0,nop,wscale 8], length 0
16:08:44.483950 IP 170.239.160.4.51266 > 172.18.19.2.https: Flags [S], seq 465277211, win 65535, options [mss 1460,sackOK,TS val 2434516034 ecr 0,nop,wscale 8], length 0
16:08:44.852749 IP 170.239.160.4.51266 > 172.18.19.2.https: Flags [S], seq 465277211, win 65535, options [mss 1460,sackOK,TS val 2434516034 ecr 0,nop,wscale 8], length 0
16:08:49.442890 IP 170.239.160.37.57579 > 172.18.19.2.https: Flags [S], seq 3965481071, win 29200, options [mss 1460,sackOK,TS val 1886380011 ecr 0,nop,wscale 5], length 0
16:08:49.443691 IP 170.239.160.37.57579 > 172.18.19.2.https: Flags [S], seq 3965481071, win 29200, options [mss 1460,sackOK,TS val 1886380011 ecr 0,nop,wscale 5], length 0


I disabled the NAT rule temporarily (image attached) and the traffic continues

This should be a no brainer, I have two rules applied to my wan interface, I have put them at the very top to block 170.239.160.0/22 & 187.108.240.0/20 (see attached image).

Traffic is not being blocked, there is a NAT rule forwarding all incoming traffic on port 443 to 172.18.19.2

If I run a tcpdump on the 172.18.19.2 system I see the following -

Code Select Expand

# tcpdump "tcp[tcpflags] & (tcp-ack) = 0" and port 443 -n -c20
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp6s0f0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
15:29:40.702817 IP 187.108.247.245.25743 > 172.18.19.2.https: Flags [S], seq 3175197668, win 16384, options [mss 1452,sackOK,TS val 2883870863 ecr 0,nop,wscale 6], length 0
15:29:40.702818 IP 187.108.247.245.25743 > 172.18.19.2.https: Flags [S], seq 3175197668, win 16384, options [mss 1452,sackOK,TS val 2883870863 ecr 0,nop,wscale 6], length 0
15:29:40.703251 IP 187.108.247.245.25743 > 172.18.19.2.https: Flags [S], seq 3175197668, win 16384, options [mss 1452,sackOK,TS val 2883870863 ecr 0,nop,wscale 6], length 0
15:29:40.898930 IP 179.106.77.68.14350 > 172.18.19.2.https: Flags [S], seq 1585738757, win 65535, options [mss 1460,sackOK,TS val 1946498062 ecr 0,nop,wscale 5], length 0
15:29:40.914092 IP 187.108.249.81.30930 > 172.18.19.2.https: Flags [S], seq 1291127091, win 65535, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
15:29:40.914092 IP 187.108.249.81.30930 > 172.18.19.2.https: Flags [S], seq 1291127091, win 65535, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
15:29:40.914413 IP 187.108.249.81.30930 > 172.18.19.2.https: Flags [S], seq 1291127091, win 65535, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
15:29:41.074932 IP 187.108.247.245.25743 > 172.18.19.2.https: Flags [S], seq 3175197668, win 16384, options [mss 1452,sackOK,TS val 2883870863 ecr 0,nop,wscale 6], length 0
15:29:41.179480 IP 179.106.76.240.18672 > 172.18.19.2.https: Flags [S], seq 1368460929, win 64240, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
15:29:41.179481 IP 179.106.76.240.18672 > 172.18.19.2.https: Flags [S], seq 1368460929, win 64240, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
15:29:41.180150 IP 179.106.76.240.18672 > 172.18.19.2.https: Flags [S], seq 1368460929, win 64240, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
15:29:41.286667 IP 187.108.249.81.30930 > 172.18.19.2.https: Flags [S], seq 1291127091, win 65535, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
15:29:41.550143 IP 170.239.161.23.249 > 172.18.19.2.https: Flags [S], seq 2311986662, win 65535, options [mss 1412,sackOK,TS val 501677817 ecr 0,nop,wscale 7], length 0
15:29:41.550200 IP 170.239.161.23.249 > 172.18.19.2.https: Flags [S], seq 2311986662, win 65535, options [mss 1412,sackOK,TS val 501677817 ecr 0,nop,wscale 7], length 0
15:29:41.550249 IP 170.239.161.23.249 > 172.18.19.2.https: Flags [S], seq 2311986662, win 65535, options [mss 1412,sackOK,TS val 501677817 ecr 0,nop,wscale 7], length 0
15:29:41.551891 IP 179.106.76.240.18672 > 172.18.19.2.https: Flags [S], seq 1368460929, win 64240, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
15:29:41.893931 IP 179.106.73.138.16542 > 172.18.19.2.https: Flags [S], seq 2137856657, win 65535, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
15:29:41.895644 IP 179.106.73.138.16542 > 172.18.19.2.https: Flags [S], seq 2137856657, win 65535, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
15:29:41.895645 IP 179.106.73.138.16542 > 172.18.19.2.https: Flags [S], seq 2137856657, win 65535, options [mss 1452,nop,wscale 6,nop,nop,sackOK], length 0
15:29:41.921318 IP 170.239.161.23.249 > 172.18.19.2.https: Flags [S], seq 2311986662, win 65535, options [mss 1412,sackOK,TS val 501677817 ecr 0,nop,wscale 7], length 0
20 packets captured
22 packets received by filter
0 packets dropped by kernel


If I look at the live view, I see the traffic is listed as pass but it is on the inside interface with the label of "let out anything from the firewall host itself" which is one of the automatically generated rules.  I don't think this traffic should ever have made it this far, it should be blocked at the outside/wan interface.

As I said this shouldn't be very difficult, so what did I do wrong?

Jeff

I like the announcement widget on the dashboard however in my opinion it needs to include the date of the announcement as well.

never said the script was pretty, but for right now until a better solution is identified and deployed this is remains a workable option, at least for me at the moment.

I've come up with a not so elegant solution based upon a posting I found elsewhere directed towards pfsense.  If I enable log level debug under "interfaces -> Settings" I can get the IA_PD address to appear in the files in /var/log/system/, I found it doesn't always show in "latest.log" so I simply cat all the files run it through grep and take the last IA_PD entry found and apply that address to the WAN interface.

After a reboot I simply run the script eg "./assign_ip6.sh <wan interface>" and the script will apply the last address from the assigned prefix to the wan interface. (ugly script attached)

I'm sure somebody can figure out a better way to put IA_PD and clean up the script, but at least it solves the problem for now, if not a little (ok very) kludgy.

Jef

Where you ever successful?  If so what was the final solution?  I too get a delegated /56 but no address assigned to the WAN interface, yes everything works with a link local on the wan interface unless I need/want to source something from the firewall itself.

Thanks, Jeff

a little drastic but it did solve the problem, at least I was able to restore individual portions of the configuration without causing a problem, restoring the complete configuration will trigger the problem.

I found I was able to trigger the issue once when creating vlan's on my inside interface.

I really wish I know what was triggering the failure.

Next issue, the ISP (Verizon FiOS) doesn't issue a IPv6 address to the WAN interface, it instead relies on a link-local address, just a /56 prefix, is there a way to automatically assign a /64 to the WAN interface? I would like all my systems behind the opnsense device to query unbound for dns and let unbound do the query to the outside, I'm assuming it wants to use the WAN interface's address.

I've been trying to get IPv6 working with Verizon FiOS and I actually received a /56 prefix along with a link local address on my wan interface.  I'm successfully able to apply an IPv6 address to my LAN interfaces (utilizing 3 vlans on the lan interface) by tracking the WAN interface and specifying an IPv6 prefix ID, however the connectivity only works for a few seconds and then stops working.  If I do a simple tcpdump on my wan interface "tcpdump -igb4 ipv6" I see the following:

11:11:52.450942 IP6 2600:4040:af10::1 > ff02::1:ff6d:f468: ICMP6, neighbor solicitation, who has fe80::20e:b6ff:fe6d:f468, length 32
11:11:52.846407 IP6 fe80::20e:b6ff:fe6d:f468 > ff02::1:ff1c:a00c: ICMP6, neighbor solicitation, who has fe80::8aa2:5eff:fe1c:a00c, length 32
11:11:52.852941 IP6 fe80::20e:b6ff:feb0:6dc2.546 > ff02::1:2.547: dhcp6 request
11:11:53.002705 IP6 fe80::20e:b6ff:feb0:6dc2.546 > ff02::1:2.547: dhcp6 solicit
11:11:53.846201 IP6 fe80::20e:b6ff:fe6d:f468 > ff02::1:ff1c:a00c: ICMP6, neighbor solicitation, who has fe80::8aa2:5eff:fe1c:a00c, length 32
11:11:54.012969 IP6 fe80::20e:b6ff:feb0:6dc2.546 > ff02::1:2.547: dhcp6 request
11:11:54.362938 IP6 fe80::20e:b6ff:feb0:6dc2.546 > ff02::1:2.547: dhcp6 solicit
11:11:54.846199 IP6 fe80::20e:b6ff:fe6d:f468 > ff02::1:ff1c:a00c: ICMP6, neighbor solicitation, who has fe80::8aa2:5eff:fe1c:a00c, length 32
11:11:55.372914 IP6 fe80::20e:b6ff:feb0:6dc2.546 > ff02::1:2.547: dhcp6 request
11:11:55.456058 IP6 2600:4040:af10::1 > ff02::1:ff6d:f468: ICMP6, neighbor solicitation, who has fe80::20e:b6ff:fe6d:f468, length 32

This repeats continuously in rapid succession and never stops.

I have configured IPv6 for a friend utilizing the same hardware and was successful with the configuration and I noted that that setup does not generate the continuous stream of requests and solicits. 

I attempted to back everything out and have gone so far as to disable every IPv6 setting on the firewall that I could find and the firewall continues to send the same IPv6 request and solicit packets.  I have tried reinstalling the software and then reimporting my configuration and the solicits and requests start all over again.  My next attempt will be to simply recreate the configuration from scratch and not import my configuration.

One thing to note, I originally was using IPv6 over hurricane electric via GIT tunnel, could this be causing me grief?  I've deleted all the remnants of this configuration from the GUI.

Where is this coming from?  Why can I not stop it?

Jeff

I have IPv6 turned off on the WAN interface with the IPv6 Configuration Type is set to "None" however I see that every second I have the router sending out dhcpv6 requests, why?

21:40:24.255657 IP6 fe80::20e:b6ff:feb0:6dc2.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 request
21:40:24.335396 IP6 fe80::20e:b6ff:feb0:6dc2.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
21:40:25.345685 IP6 fe80::20e:b6ff:feb0:6dc2.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 request
21:40:25.615473 IP6 fe80::20e:b6ff:feb0:6dc2.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
21:40:26.625721 IP6 fe80::20e:b6ff:feb0:6dc2.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 request
21:40:26.995474 IP6 fe80::20e:b6ff:feb0:6dc2.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
21:40:28.005709 IP6 fe80::20e:b6ff:feb0:6dc2.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 request
21:40:28.625461 IP6 fe80::20e:b6ff:feb0:6dc2.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit


Current version is OPNsense 22.7.2-amd64 and there currently no updates available.

Thanks, Jeff

I like many others have run into a problem with using an IPv6 tunnel broker and Netflix where Netflix rejects the IPv6 connection.

I attempted to configure and DNS server on the firewall and everything was working fine until I attempted to use the command in bind "filter-aaaa-on-v4 yes;" it turns out that in order to use the command bind has to be built with the option "--enable-filter-aaaa".  The supplied version of bind9 for OPNsense doesn't have that option compiled in.

I'm not necessarily against recompiling bind however given the choice I would rather stay with the pre-built programs as it will make my life a lot easier in the future when it comes time to upgrading.

In case I was going about this the wrong way I was simply going to use unbound to query bind on port 10053 for anything in the netflix.com domain and allow bind to filter out the aaaa responses.

Jeff

I have enabled a gif interface for use with Hurricane Electric for IPv6 connectivity.  I have noticed in the dmesg logs thousands of the message:

gif0: link state changed to UP
gif0: link state changed to DOWN

The IPv6 connectivity appears to be working fine however

Software on my unit from the dashboard page is:

OPNsense 19.1.1-amd64
FreeBSD 11.2-RELEASE-p8-HBSD
OpenSSL 1.0.2q 20 Nov 2018

Suggestions as to what I might need to change to correct the issue?

Thanks,
Jeff