Messages

1

17.7 Legacy Series / Re: Failed: IPv6 fragmented packet delivery

« on: October 14, 2017, 08:09:00 pm »

Phoenix,

Thank you, that is what I was looking for.

This seems to be local to my configuration as I had other people in the United States on the same ISP but non OPNsense users report their results and it worked for them too.

So... something in my Opnsense configuration OR something local to the region for my ISP which seems unlikely. If anyone has any ideas, I'd love to hear them.

Thanks!

2

17.7 Legacy Series / Re: Failed: IPv6 fragmented packet delivery

« on: October 14, 2017, 07:29:11 pm »

Phoenix,

First and foremost, thank you for helping me out.

I have a few questions:

for the website check I too get Green for the first check:

ICMP path MTU packet delivery
✓ All good! ICMP path MTU message was successfully delivered to you.

It's the second check I see fail:

IP fragmented packet delivery
✗ The request timed out. Looks like IP fragments failed to be delivered to you.

Second, their webpage is a not 100% correct, the curl command you ran was IPv4

curl -v -s http://icmpcheck.popcount.org/frag -o /dev/null
* Hostname was NOT found in DNS cache
*   Trying 139.162.188.91...

Can you run curl and tcpdump using the ipv6 hostname?

curl -v -s http://icmpcheckv6.popcount.org/frag -o /dev/null

Note: I see your tcpdump results seem to show IPv6 so I am a touch confused

...
08:29:26.318081 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > 2a01:e0a:6e:c111:be5f:f4ff:fe62:99c5: frag (0|512) 80 > 35338: Flags [.], seq 998043207:998043687, ack 1367675351, win 232, options [nop,nop,TS val 1675060106 ecr 23061848], length 480: HTTP
08:29:26.318109 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > 2a01:e0a:6e:c111:be5f:f4ff:fe62:99c5: frag (512|512)
...

Thank you!

3

17.7 Legacy Series / Failed: IPv6 fragmented packet delivery

« on: October 14, 2017, 08:14:17 am »

Greetings,

In the United States using Xfinity Internet I see failed IP fragmented packet delivery over IPv6 using OPNsense 17.7.5.

You can run a test here:

http://icmpcheckv6.popcount.org/

Reference:
https://blog.cloudflare.com/ip-fragmentation-is-broken/

Could someone else using OPNsense 17.7.x with a IPv6 connection run the test at http://icmpcheckv6.popcount.org/ and report your results? Specifically I see:

IP fragmented packet delivery
✗ The request timed out. Looks like IP fragments failed to be delivered to you.

If I use curl + tcpdump I see:

Code: [Select]

curl -v -s http://icmpcheckv6.popcount.org/frag -o /dev/null
*   Trying 2a01:7e01::f03c:91ff:fe16:a2e9...
* TCP_NODELAY set
* Connected to icmpcheckv6.popcount.org (2a01:7e01::f03c:91ff:fe16:a2e9) port 80 (#0)
> GET /frag HTTP/1.1
> Host: icmpcheckv6.popcount.org
> User-Agent: curl/7.55.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Sat, 14 Oct 2017 05:49:38 GMT
< Content-Type: text/plain; charset=utf-8
< Connection: close
< Transfer-Encoding: chunked
<
{ [14 bytes data]
* Recv failure: Connection reset by peer
* stopped the pause stream!
* Closing connection 0


Code: [Select]

tcpdump -ni igb0 '(ip[6] & (1<<5)) != 0 or (ip[7] != 0) or (ip[6] & ((1<<5)-1) != 0) or ip6[6] == 44'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on igb0, link-type EN10MB (Ethernet), capture size 262144 bytes
01:49:38.585841 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > xxx: frag (0|512) 80 > 47493: Flags [.], seq 87111905:87112385, ack 4046851107, win 224, options [nop,nop,TS val 1674343770 ecr 2705732609], length 480: HTTP
01:49:38.616794 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > xxx: frag (0|512) 80 > 47493: Flags [.], seq 1428:1908, ack 1, win 224, options [nop,nop,TS val 1674343770 ecr 2705732609], length 480: HTTP
01:49:38.647635 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > xxx: frag (0|512) 80 > 47493: Flags [.], seq 2856:3336, ack 1, win 224, options [nop,nop,TS val 1674343770 ecr 2705732609], length 480: HTTP
01:49:38.678546 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > xxx: frag (0|512) 80 > 47493: Flags [.], seq 4284:4764, ack 1, win 224, options [nop,nop,TS val 1674343770 ecr 2705732609], length 480: HTTP
01:49:38.709258 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > xxx: frag (0|512) 80 > 47493: Flags [.], seq 5712:6192, ack 1, win 224, options [nop,nop,TS val 1674343770 ecr 2705732609], length 480: HTTP
01:49:38.739918 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > xxx: frag (0|512) 80 > 47493: Flags [P.], seq 7140:7620, ack 1, win 224, options [nop,nop,TS val 1674343770 ecr 2705732609], length 480: HTTP
01:49:39.004806 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > xxx: frag (0|512) 80 > 47493: Flags [P.], seq 7140:7620, ack 1, win 224, options [nop,nop,TS val 1674343896 ecr 2705732747], length 480: HTTP
01:49:39.405000 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > xxx: frag (0|512) 80 > 47493: Flags [.], seq 0:480, ack 1, win 224, options [nop,nop,TS val 1674344016 ecr 2705732747], length 480: HTTP
01:49:40.205523 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > xxx: frag (0|512) 80 > 47493: Flags [.], seq 0:480, ack 1, win 224, options [nop,nop,TS val 1674344256 ecr 2705732747], length 480: HTTP
01:49:41.805125 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > xxx: frag (0|512) 80 > 47493: Flags [.], seq 0:480, ack 1, win 224, options [nop,nop,TS val 1674344736 ecr 2705732747], length 480: HTTP
01:49:45.111728 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > xxx: frag (0|512) 80 > 47493: Flags [.], seq 0:480, ack 1, win 224, options [nop,nop,TS val 1674345728 ecr 2705732747], length 480: HTTP
01:49:51.511640 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > xxx: frag (0|512) 80 > 47493: Flags [.], seq 0:480, ack 1, win 224, options [nop,nop,TS val 1674347648 ecr 2705732747], length 480: HTTP
01:50:04.311778 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > xxx: frag (0|512) 80 > 47493: Flags [.], seq 0:480, ack 1, win 224, options [nop,nop,TS val 1674351488 ecr 2705732747], length 480: HTTP
01:50:30.338806 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > xxx: frag (0|512) 80 > 47493: Flags [.], seq 0:480, ack 1, win 224, options [nop,nop,TS val 1674359296 ecr 2705732747], length 480: HTTP
01:51:21.539176 IP6 2a01:7e01::f03c:91ff:fe16:a2e9 > xxx: frag (0|512) 80 > 47493: Flags [.], seq 0:480, ack 1, win 224, options [nop,nop,TS val 1674374656 ecr 2705732747], length 480: HTTP

Thank you!

4

15.7 Legacy Series / Re: Missing RRD Graphs

« on: December 23, 2015, 01:44:28 pm »

I too miss the RRD graphs and would enable them if that was an option. What do I miss?

1. It was very easy to see 5m, 1h, 1d, 30d, 365d graphs.

2. Traffic Graphs: I like the table stats below the graph (maximum, average, current, period, 95th percentile)
 * I realize you can enable "show tables" but you don't get the measurement per sec (MB/s), period or 95th percentile

Note: RRD graphs are not important enough for me to bring up on separate infrastructure in my home network.

5

15.7 Legacy Series / [SOLVED] Re: Firewall rule: "Default deny rule IPv6"

« on: December 11, 2015, 09:38:17 pm »

release 15.7.22 seems to have solved this problem, big thanks to Franco for helping me work through the issue.

6

15.7 Legacy Series / Re: Firewall rule: "Default deny rule IPv6"

« on: November 30, 2015, 06:10:13 pm »

Good morning giovino,

1. I suspect during some upgrade the bit behind "Allow IPv6" got flipped even though the UI still said it was "checked". If I could reproduce it we could call it a bug but I'm guessing i cannot so we'll write it off as a ghost in the machine.

Question: is this fix persistent after reboot? The only way this makes a little sense is that it's not and the reload actually triggered something else that allowed traffic to flow. We've seen such behaviour with OpenVPN traffic not passing until a reload took place.

franco.. you are brilliant! I rebooted the router and sure enough IPv6 traffic was being blocked and the "Allow IPv6" box was checked. I unchecked -> save -> rechecked -> saved.. IPv6 traffic was flowing again. This also makes sense as I thought I had seen this and fixed it once before but wasn't sure what I did as I "pushed" too many buttons

I'll create a github issue and reference this thread. Thank you!

2. Being able to click the "X" in the firewall log viewer is not obvious, once I saw there was a rule blocking IPv6 traffic it at least gave me a clue why I was seeing IPv6 traffic being blocked in the firewall logs. It would be nice if there was a better visual clue for seeing the rule/data "behind" the "X".

Full ack, that always annoyed me too. Added a ticket: https://github.com/opnsense/core/issues/487

Discussing how it could be improved would help. Any ideas?

Maybe have a "?" icon? Disregarding how many pixels are available for the moment...

If it says Action: Block with a "?" icon.. it would be more intuitive to _me_ that I should click that for more information.

3. It would be nice if there was a clue in the firewall rules page that indicates that the "Allow IPv6" box isn't checked OR a rule has been applied to block IPv6 traffic. It's a big leap to see IPv6 traffic being blocked, going to the firewall rules page and seeing no rules that would block said traffic and then realizing that one needs to go to "System: Settings: Networking" to verify "Allow IPv6" is checked.

The option turned off while still showing checked in the GUI is an impossible solution, so if we pin down (1) correctly this will likely not be the case. Besides, IPv6 is enabled by default so it works out of the box (I know, except this bug).

I like mf's suggestion (e.g. do not hide the implicit rules behind the scene). Of course this is probably easier said than done

7

15.7 Legacy Series / [SOLVED] Firewall rule: "Default deny rule IPv6"

« on: November 29, 2015, 09:11:25 pm »

Greetings,

I am sharing this experience as more of an FYI for others that may search the forums and less than a bug report as I wouldn't know how reproduce it.

Back ground:

My ISP provides me with an IPv4 address and a IPv6 address. I have configured the opnsense router WAN interface with "IPv4 Configuration Type": "DHCP and "IPv6 Configuration Type": "DHCPv6". I started using opnsense at version 15.7.11 and have upgraded each version since.

I recently started witnessing "slow networking" which I eventually traced back to my LAN blocking outbound IPv6. I think it was "slow" as ipv6 was timing out (being blocked) and the device (Internet) that was "slow" would fall back to ipv4.

Example Firewall Logs:

             Time                     If     Source                              Destination                      Proto
<block> Nov 29 01:01:16   LAN  [<ipv6 address>]:52068    [<ipv6 address]:443        TCP:S

I was rather confused by this as I know I had rules allowing IPv6 outbound.

Example Firewall rules:

            Proto     Source    Port       Destination   Port       Gateway Schedule   Description
<pass> IPv6 *   LAN net    *         *                     *            *                           LAN allow all IPv6

While browsing the logs through:

Status -> System Logs -> Firewall (filter: Block + LAN)

I eventually click the "X" under Act and see:

The rule that triggered this action is:
@5 block drop in log inet6 all label "Default deny rule IPv6"

That gets me thinking.. huh there's an option somewhere that (not in the firewall rules) speaks to this. I go hunting and find this:

System: Settings: Networking -> Allow IPv6

I found this setting checked, I unchecked it, clicked save. I then rechecked it and clicked save again.

Once I did this, the router stops blocking IPv6 outbound LAN traffic. (problem fixed)

Having fixed the problem I have some comments:

1. I suspect during some upgrade the bit behind "Allow IPv6" got flipped even though the UI still said it was "checked". If I could reproduce it we could call it a bug but I'm guessing i cannot so we'll write it off as a ghost in the machine.

2. Being able to click the "X" in the firewall log viewer is not obvious, once I saw there was a rule blocking IPv6 traffic it at least gave me a clue why I was seeing IPv6 traffic being blocked in the firewall logs. It would be nice if there was a better visual clue for seeing the rule/data "behind" the "X".

3. It would be nice if there was a clue in the firewall rules page that indicates that the "Allow IPv6" box isn't checked OR a rule has been applied to block IPv6 traffic. It's a big leap to see IPv6 traffic being blocked, going to the firewall rules page and seeing no rules that would block said traffic and then realizing that one needs to go to "System: Settings: Networking" to verify "Allow IPv6" is checked.

</comments>

A big thank you to everyone involved with OPNsense!

-g