Very Basic IPv6 security question.

RobbieTT

@JKnott said in Very Basic IPv6 security question.:

As has been mentioned, start simple and go from there, as you get things working.

Cannot argue with that.

️

Gertjan

@JKnott said in Very Basic IPv6 security question.:

Because I know that I will receive "2a01:cb19:xO7:a6dc" as a prefix, I "hard coded" it.

Is that address from Rogers?

No. I'm living in the original, old world, not the recent one ;)
To be exact : 2a01:cb19:907:a6dc
ISP Orange, France.

@RobbieTT said in Very Basic IPv6 security question.:

Just so we are all on the same page

Managed, for myself.
I'm doing my best to give Android devices a hard time on my networks.
I'm joking of course, I don't have any Android devices so I'm not in the need of the SLAAC thing.
( or am I saying the same thing differently ? )

JKnott

@Gertjan said in Very Basic IPv6 security question.:

No. I'm living in the original, old world, not the recent one ;)
To be exact : 2a01:cb19:907:a6dc
ISP Orange, France.

Sorry, I was getting posters mixed up. I thought I was replying to @guardian, who is on Rogers.

guardian

@RobbieTT said in Very Basic IPv6 security question.:

@guardian

You are not configured for it to work just yet. For the Interfaces / WAN I would start by checking the boxes below and you will also have to determine what the prefix delegation size is from your ISP. A nice fat /48 is typical (as I have on the example below), with some ISPs trimming this down to a /56 (as it is still massive). Hopefully you don't just have a /64 but I understand that there are some ISPs that are that dumb/restrictive (particularly in the US it seems).

More to do after that on your LAN(s)/VLANs, DHCPv6 Server and Router Advertisements but the above is as good as any starting point. That and reading the section in the pfSense manual.

️

@RobbieTT - Thanks very much - when I made these changes I now have IPv6 Connectivity being passed through to the VLAN, and hence the laptop. 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? FYI I can ping this address successfully from the Diagnostics menu and also from the shell, so I'm wondering if the process got hung somehow (how do I restart it?).

For the benefit of anyone who comes after me, (for Rogers Canada in July 2023) the deligation is "only" 56, and here is how I am set up now on the WAN:

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.