Very Basic IPv6 security question.

JKnott

@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.

RobbieTT

@JKnott

If it is the first hop to the ISP's node then link local (fe80) would be fine or even expected. Beyond that it would need a global target to ping against.

2023-07-22 at 13.59.38.png

JKnott

@RobbieTT

In my experience, it didn't work with the link local address. I did a traceroute to Google and used the first global address that turned up.

JKnott

@JKnott

I just tried again, using the default route fe80::217:10ff:fe9. While it is accepted, the dashboard shows packet loss.

RobbieTT

@JKnott
Understood - just clarifying that a global address is not always needed for a gateway to node hop.

️

johnpoz

@RobbieTT said in Very Basic IPv6 security question.:

global address is not always needed for a gateway to node hop.

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.

JKnott

@johnpoz said in Very Basic IPv6 security question.:

Also possible the link local address might not even answer ping, etc.

That appears to be the case here.

RobbieTT

@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.

️

johnpoz

@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..

RobbieTT

@johnpoz

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

️

guardian

@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.

johnpoz

@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.

JKnott

@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.

guardian

@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.).

johnpoz

@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

JKnott

@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.

guardian

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

JKnott

@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.

johnpoz

@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 ;)

JKnott

@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.