Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - giovino

#1
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
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:

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

It's the second check I see fail:

Quote
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

Quote
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?

Quote
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

Quote
...
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
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:

Quote
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:


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



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
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
release 15.7.22 seems to have solved this problem, big thanks to Franco for helping me work through the issue.
#6
Quote from: franco on November 30, 2015, 07:25:28 AM
Good morning giovino,

Quote from: giovino on November 29, 2015, 09:11:25 PM
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!

Quote from: franco on November 30, 2015, 07:25:28 AM
Quote from: giovino on November 29, 2015, 09:11:25 PM
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.

Quote from: franco on November 30, 2015, 07:25:28 AM
Quote from: giovino on November 29, 2015, 09:11:25 PM
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
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