Very Basic IPv6 security question.
-
@johnpoz said in Very Basic IPv6 security question.:
very true.. But what would be needed to be able to ping something you monitoring that has gua. Is a gua to send the answer back too.
Also possible the link local address might not even answer ping, etc.
Clearly it should respond to ICMP6 (it is an IPv6 requirement) but ISPs...
In my example above I didn't set anything manually as the link-local for the gateway comes via the RA and pfSense adopts it:
Jul 20 18:43:40 rtsold 67156 Received RA specifying route fe80::xxx:xxxx:xxxx:x100 for interface wan(pppoe0)
I'm a bit of a purist, keeping the gateway monitor limited to the gateway, rather than the wider internet. One of my servers runs a GUA ping graph via PingPlotter 24/7, to monitor the broader upstream connectivity.
️
-
@RobbieTT said in Very Basic IPv6 security question.:
Clearly it should respond to ICMP6
ICMP sure - but not the "ping" echo request of ICMP.. that is not actually "required" for IPv6 to function... But I believe the rfc says to allow them.. And pfsense does..
# IPv6 ICMP is not auxiliary, it is required for operation # See man icmp6(4) # 1 unreach Destination unreachable # 2 toobig Packet too big # 128 echoreq Echo service request # 129 echorep Echo service reply # 133 routersol Router solicitation # 134 routeradv Router advertisement # 135 neighbrsol Neighbor solicitation # 136 neighbradv Neighbor advertisement pass quick inet6 proto ipv6-icmp from any to any icmp6-type {1,2,135,136} ridentifier 1000000107 keep state # Allow only bare essential icmpv6 packets (NS, NA, and RA, echoreq, echorep) pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type {129,133,134,135,136} ridentifier 1000000108 keep state pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {129,133,134,135,136} ridentifier 1000000109 keep state pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type {128,133,134,135,136} ridentifier 1000000110 keep state pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type {128,133,134,135,136} ridentifier 1000000111 keep state pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {128,133,134,135,136} ridentifier 1000000112 keep state pass in quick inet6 proto ipv6-icmp from :: to ff02::/16 icmp6-type {128,133,134,135,136} ridentifier 1000000113 keep state
https://www.rfc-editor.org/rfc/rfc4890#section-4.3.1
4.3.1. Traffic That Must Not Be Dropped Error messages that are essential to the establishment and maintenance of communications: o Destination Unreachable (Type 1) - All codes o Packet Too Big (Type 2) o Time Exceeded (Type 3) - Code 0 only o Parameter Problem (Type 4) - Codes 1 and 2 only Appendix A.4 suggests some more specific checks that could be performed on Parameter Problem messages if a firewall has the necessary packet inspection capabilities. Connectivity checking messages: o Echo Request (Type 128) o Echo Response (Type 129) For Teredo tunneling [RFC4380] to IPv6 nodes on the site to be possible, it is essential that the connectivity checking messages are allowed through the firewall. It has been common practice in IPv4 networks to drop Echo Request messages in firewalls to minimize the risk of scanning attacks on the protected network. As discussed in Section 3.2, the risks from port scanning in an IPv6 network are much less severe, and it is not necessary to filter IPv6 Echo Request messages.
But as you stated - not all ISPs follow the RFCs ;) and they could have some rate limiting on it, etc.
If you read this part of the RFC
A.5. ICMPv6 Echo Request and Echo Response Echo Request (Type 128) uses unicast addresses as source addresses, but may be sent to any legal IPv6 address, including multicast and anycast addresses [RFC4443]. Echo Requests travel end-to-end. Similarly, Echo Responses (Type 129) travel end-to-end and would have a unicast address as destination and either a unicast or anycast address as source. They are mainly used in combination for monitoring and debugging connectivity. Their only role in establishing communication is that they are required when verifying connectivity through Teredo tunnels [RFC4380]: Teredo tunneling to IPv6 nodes on the site will not be possible if these messages are blocked. It is not thought that there is a significant risk from scanning attacks on a well-designed IPv6 network (see Section 3.2), and so connectivity checks should be allowed by default.
So ok you won't be able to do teredo if you block them.. But that is pretty much dead..
But I read
It is not thought that there is a significant risk from scanning attacks on a well-designed IPv6 network (see Section 3.2), and so connectivity checks should be allowed by default.
But does that mean its required to allow - I don't think so, other than teredo..
-
RFC6919 clarifies the hierarchy of language used for the required standards. Essential reading for networking engineers at ISPs:
https://datatracker.ietf.org/doc/html/rfc6919
️
-
@JKnott said in Very Basic IPv6 security question.:
@guardian said in Very Basic IPv6 security question.:
For some reason the connection monitor isn't working - it was working before, but then everything else wasn't working, so it didn't matter. Is there a way to fix it?
What address are you using? It has to be a global address, not link local.
The address in brackets is the monitor address, which is the Google DNS IPv6 equivalent of 8.8.8.8.
It was workiing before I made the last round of changes that I documented in my last post. My internet connection started to work as it was supposed to, but the monitor just stopped. at some point.
I even tried to reboot my phone, and nothing changed.
-
@guardian what did you not understand about you can not ping a gua from link local?
You can for sure use a link-local as a transit network. But you can not monitor some gua address out on the internet without having a gua address.
-
@johnpoz said in Very Basic IPv6 security question.:
@guardian what did you not understand about you can not ping a gua from link local?
You can for sure use a link-local as a transit network. But you can not monitor some gua address out on the internet without having a gua address.
Since he's on Rogers, he should have a WAN GUA. In my own testing, I've determined that a link local monitor address won't work, as the gateway address doesn't respond to pings. It's been so long since I set up my own system that I forgot that was why I couldn't use a link local address. However, a monitor address is not necessary for a working system. There's also the IPv4 one that should work.
-
@johnpoz said in Very Basic IPv6 security question.:
@guardian what did you not understand about you can not ping a gua from link local?
You can for sure use a link-local as a transit network. But you can not monitor some gua address out on the internet without having a gua address.
@johnpoz I understand you can not ping a gua from link local - what I don't understand is what pfSense is actually doing, and how the gateway monitor gets set up or what address the pings get sent from. Ping/traceroute work from the menu, (but the actual address used isn't shown), but the pinger isn't working and I had no idea why. There was a point (when I didn't have a working system), that I had a working pinger - I believe it was before I set up prefix delegation - I think the router was being issued a single /64 - but I can't remember.
@JKnott said in Very Basic IPv6 security question.:
@johnpoz said in Very Basic IPv6 security question.:
@guardian what did you not understand about you can not ping a gua from link local?
You can for sure use a link-local as a transit network. But you can not monitor some gua address out on the internet without having a gua address.
Since he's on Rogers, he should have a WAN GUA. In my own testing, I've determined that a link local monitor address won't work, as the gateway address doesn't respond to pings. It's been so long since I set up my own system that I forgot that was why I couldn't use a link local address. However, a monitor address is not necessary for a working system. There's also the IPv4 one that should work.
@JKnott, @johnpoz is there a way forward, or should I just disable the montior and hide it from the dashbord?
I notice the same thing with IPv4, that the monitor is using internal addresses. Is there some way to display my public IP on the dashboard? (if not, no big deal, but it would be "nice" to have.).
-
@guardian said in Very Basic IPv6 security question.:
Is there some way to display my public IP on the dashboard?
Does your wan have a public IPv4 address? Or are you behind a nat?
For you IPv6 - not getting a gua, do you have this set?
If you actually have public IPv4 and IPv6 address - they would be shown on what your gateway is and the actual interfaces
-
@guardian said in Very Basic IPv6 security question.:
@JKnott, @johnpoz is there a way forward, or should I just disable the montior and hide it from the dashbord?
I notice the same thing with IPv4, that the monitor is using internal addresses. Is there some way to display my public IP on the dashboard? (if not, no big deal, but it would be "nice" to have.).
You can add the interfaces widget to the dashboard. As for your monitor, as I mentioned you don't need it. Normally pfSense will use the gateway as the monitor address. That works for IPv4, but with Rogers, on IPv6, it doesn't work, because the Rogers gateway doesn't respond to ping. As I mentioned earlier, I just ran a traceroute to Google and picked the first GUA that turned up.
-
@johnpoz said in Very Basic IPv6 security question.:
@guardian said in Very Basic IPv6 security question.:
Is there some way to display my public IP on the dashboard?
Does your wan have a public IPv4 address? Or are you behind a nat?
For you IPv6 - not getting a gua, do you have this set?
If you actually have public IPv4 and IPv6 address - they would be shown on what your gateway is and the actual interfaces
@johnpoz, @JKnott - TLDR; Pinger working now thanks--and IPv6 still OK!
I have a public IPv4 address, but the pinger widget displays the gateway (x.x.x.1) address even though the pinger is working.
I turned off the setting you suggested. I had it set because it was part of the settings recommended earlier that got my IPv6 connectivity working. It turns out that this setting wasn't a necessary part of the changes, so turnng if off got the pinger working again without causing problems. I guess that link local address and the x.x.x1 adress are technically the gateway -- but with multiple L3 addresses on an interface showing though it still shows a link-local address in the widget.
@JKnott said in Very Basic IPv6 security question.:
You can add the interfaces widget to the dashboard. As for your monitor, as I mentioned you don't need it. Normally pfSense will use the gateway as the monitor address. That works for IPv4, but with Rogers, on IPv6, it doesn't work, because the Rogers gateway doesn't respond to ping.
@JKnott thanks for the suggestion about the Interfaces widget, that gives me what I want.
As I mentioned earlier, I just ran a traceroute to Google and picked the first GUA that turned up.
Isn't that a bit risky in this day of infrastructure as code? I don't think the public IP is going to change anytime soon, but what about the path to it?
-
@guardian said in Very Basic IPv6 security question.:
Isn't that a bit risky in this day of infrastructure as code? I don't think the public IP is going to change anytime soon, but what about the path to it?
That address is still on my ISP's network, so it likely won't change. As long as it's there, along the path or not, it will work. Regardless, the worst that could happen is the monitor stops working. Big deal..
I have a public IPv4 address, but the pinger widget displays the gateway (x.x.x.1) address even though the pinger is working.
By default, the gateway address is used. However, as I mentioned, that didn't work on IPv6 with Rogers, as the IPv6 gateway doesn't respond to pings. If it did, the link local address would have worked, with or without a WAN GUA.
You're discovering some of the ways IPv6 differs from IPv4. With IPv4, you don't have the link local address to use for routing etc.. You also don't need a WAN GUA, something you couldn't get away with on IPv4.
-
@JKnott said in Very Basic IPv6 security question.:
You also don't need a WAN GUA, something you couldn't get away with on IPv4.
Says who? You can for sure do the same thing with IPv4.. You can use 169.254 as a transit, you can use any rfc1918 as transit - the transit network doesn't have to route to use it as transit network.. See it all the time actually..
Where it makes less sense to do with is IPv6 - where you have a bajillion pretty much unlimited IP space.. Unlike with IPv4.. Not putting a gua on the transist in IPv6 is pretty stupid to be honest.. Why should you not make it routeable when you don't have to worry about running out of IP space to use ;)
-
@johnpoz said in Very Basic IPv6 security question.:
. You can use 169.254 as a transit, you can use any rfc1918 as transit - the transit network doesn't have to route to use it as transit network.. See it all the time actually..
I was referring to WAN addresses. My ISP used to use some RFC1918 addresses internally. I saw them when I did a traceroute.
@johnpoz said in Very Basic IPv6 security question.:
Not putting a gua on the transist in IPv6 is pretty stupid to be honest..
Maybe the ISP doesn't want to "waste" a whole /65 to support it.
I don't have a problem with using the link local addresses for routing. In fact, you don't even need any address, with a point to point link. All you need is the interface.
-
Hi, sorry for open this topic after 1 year :/
I have disable all IPv6 on my system, and also added
Have been running like this for a long time. Until I notice when i do a "DNS Lookup"
It takes almost 20 seconds to you get any answer. And why?
As you can see the Name server that not respond is ::1 (IPv6 localhost)So when i change this to YES.
And do another DNS Lookup its answer right away.
And now ::1 responds also
I don't know if this is an bug or not. But it is quite annoying when you have to wait almost 20 seconds for every DNS lookup. :) -
If you have anything, including DNS, that points to an IPv6 address (such as a name server) and you disable bits of IPv6 then yes, you will have a problem. To stop using IPv6 you have to be meticulous in removing all uses of it.
I've no idea why anyone wants to remove the more modern IP system that is IPv6 from their network - it is clearly beyond my brain. I guess there must be a reason somewhere but the future that is IPv6 will get you at some point... .
Almost all my traffic is IPv6 these days, what little IPv4 there is seems to be confined to some servers and services in the US. Weird.
️
-
@RobbieTT
Hi, yeah I know the IPv6 is the future, but right now my system are only using IPv4 for many years. And after upgrading to 24.03 or something, somtning new appears
And I don't know how to get ride of it :) Even i'm sure I have disable all IPv6 settings. -
@MoonKnight
no sweat!
Just ignore that...it's just IPv6`s way of saying: Home is where 127.0.0.1 AND ::1 are...
:) -
hehe :) I know, but I believe this is an bug. Not that ::1 is there, but DNS Lookup is so slow if you disable all IPv6. And because of that, DNS Lookup still useIPv6 for dns lookup. :/
I was hoping maybe some others have found the same "issue" :) -
@johnpoz said in Very Basic IPv6 security question.:
@JKnott I think it is at the root of the question. Trying to lock down IPv6 is much harder than just IPv4 because of temp IPv6 address. With IPv4 if a device has address 1.2..3.4 it can't just randomly use 1.2.3.5 to make a connection..
You could still do static IPv6 assignments I did that and there was no longer temps showing up
-
@MoonKnight that is just a loopback