T-Mobile cellular service on a netgear LM1200 modem no ipv6 gateway

JKnott

@ddbnj said in T-Mobile cellular service on a netgear LM1200 modem no ipv6 gateway:

First, the modem is working as an ip4 gateway

In general, you want a modem to be in bridge mode, not gateway. If it's in gateway mode, it won't provide DHCPv6-PD, which pfsense needs to provide IPv6 on the LAN side. Can you put that modem in bridge mode?

dem

@jknott said in T-Mobile cellular service on a netgear LM1200 modem no ipv6 gateway:

Can you put that modem in bridge mode?

The LM1200 is in bridge mode by default.

ddbnj

@jknott @dem

Thank you both.

The modem is set to bridge mode. The pfsense ipv4 interface for the modem has the same address as listed on the modem webgui. The ipv6 address is different, link local I believe. The modem webgui has the address beginning with 2607:

If I change the gateway monitoring address to an IPv6 DNS server, the gateway reports up status. This leads me to believe that the ipv6 address being pinged by pfsense is either incorrect or not responding to ping.

If I manually ping the IP address from the modem webgui from pfsense - diagnostics-ping it works.

Despite the modem being in bridge mode, pfsense only reports the link local address in the gateway module. Am I missing a interface configuration so that it more resembles the bridge configuration that is working on IPv4?

Thanks,

Devan

dem

If I change the gateway monitoring address to an IPv6 DNS server, the gateway reports up status. This leads me to believe that the ipv6 address being pinged by pfsense is either incorrect or not responding to ping.

I don't remember if the default gateway responds to pings, but using an external address such as a DNS server for gateway monitoring is a common thing to do. If the gateway shows as up this way then it looks like things are working, but wait and see what happens the first time T-Mobile disconnects and then reconnects with another IPv6 address and gateway.

dem

Despite the modem being in bridge mode, pfsense only reports the link local address in the gateway module.

I believe it's correct to see an fe80 address for the gateway.

ddbnj

Just for the visual people:

Is there a way to pull the modem IP address and monitor that? Do all ipv6 modems behave the same way with the gateway reporting being down unless you change the monitoring IP?

dem

Is there a way to pull the modem IP address and monitor that?

The pfSense Manual discusses why you might want to monitor an address further upstream from the modem:

By default the gateway monitoring daemon will ping the gateway IP address. This is not always desirable, especially in the case where the gateway IP address is local, such as on a cable modem or fiber CPE. In those cases it makes more sense to ping something farther upstream, such as an ISP DNS server or a server on the Internet. Another case is when an ISP is prone to upstream failures, so pinging a host on the Internet is a more accurate test to determine if a WAN is usable rather than testing the link itself. Some popular choices include Google public DNS servers, or popular web sites such as Google or Yahoo. If the IP address specified in this box is not directly connected, a static route is added to ensure that traffic to the Monitor IP address leaves via the expected gateway. Each gateway must have a unique Monitor IP address.

Do all ipv6 modems behave the same way with the gateway reporting being down unless you change the monitoring IP?

I think it's the T-Mobile gateway not responding to pings rather than the modem.

ddbnj

@dem

I am not that familiar setting up static IPv6 addresses for my LAN so I decided to try track interface for the LAN. In order for that to work, I have to switch to DHCPv6 for the modem interface.

After setting up DHCPv6 on pfsense and assist for RA also on LAN, one of my NAS devices is no longer accessible. I'll have to manually reboot it when I get on site.

Anything blaringly wrong with this setup? I can still ping ipv6.google.com from the pfsense firewall.

-Devan

dem

@ddbnj
If your T-Mobile LTE connection is like mine your IPv6 address and gateway will change often, sometimes multiple times a day. With a tracking interface this will cause your entire LAN to renumber itself every time the address changes, potentially breaking any existing IPv6 connections.

Look at how many gateways my pfSense still has in its NDP table from recent address changes:

ndp -a | grep igb2 | grep -v permanent
fe80::2928:581a:872e:e728%igb2       96:a6:7e:1c:47:6a   igb2 15h56m10s S R
fe80::6903:aa02:e7b3:7b62%igb2       96:a6:7e:1c:47:6a   igb2 12h46m35s S R
fe80::5d75:e323:8ba8:b4e2%igb2       96:a6:7e:1c:47:6a   igb2 22h36m56s S R
fe80::80fe:456a:302f:ae04%igb2       96:a6:7e:1c:47:6a   igb2 19h33m37s S R
fe80::54c9:f5ff:fe7b:9685%igb2       96:a6:7e:1c:47:6a   igb2 9s        R R
fe80::2cc8:1f30:6b8:2ea6%igb2        96:a6:7e:1c:47:6a   igb2 9h8m40s   S R

So you need to see how stable your address is before you can know if a tracking interface will be acceptable.

JKnott

@ddbnj said in T-Mobile cellular service on a netgear LM1200 modem no ipv6 gateway:

Despite the modem being in bridge mode, pfsense only reports the link local address in the gateway module.

Link local addresses are often used for gateways. Here's what my default route is to pfsense:

ip -6 route show
::1 dev lo proto kernel metric 256 pref medium
2607:fea8:4c82:5900::/64 dev eth0 proto kernel metric 256 expires 86397sec pref medium
fd48:1a37:2160::/64 dev eth0 proto kernel metric 256 expires 86397sec pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::4262:31ff:fe12:b66c dev eth0 proto ra metric 1024 expires 57sec hoplimit 64 pref medium

And on pfsense to WAN:

Internet6:
Destination Gateway Flags Netif Expire
default fe80::217:10ff:fe9 UG igb0

I also have a public WAN IPv6 address, but it plays no role in routing.

JKnott

@dem said in T-Mobile cellular service on a netgear LM1200 modem no ipv6 gateway:

If your T-Mobile LTE connection is like mine your IPv6 address and gateway will change often, sometimes multiple times a day. With a tracking interface this will cause your entire LAN to renumber itself every time the address changes, potentially breaking any existing IPv6 connections.

That is bizarre. There's a setting to prevent release of the prefix. Do you have that set?

dem

@jknott said in T-Mobile cellular service on a netgear LM1200 modem no ipv6 gateway:

That is bizarre. There's a setting to prevent release of the prefix. Do you have that set?

To quote the pfSense Manual again:

"Do not allow PD/Address release: Prevents the operating system from sending a DHCPv6 release message on exit."

But the RA (shown in a previous message above) contains only the "O" flag, which means: "Stateless DHCP: The firewall will send out RA packets and addresses can be assigned to clients by SLAAC while providing additional information such as DNS and NTP from DHCPv6."

So there's no DHCPv6 server on the T-Mobile side assigning the address in the first place, as far as I can determine.

JKnott

@dem said in T-Mobile cellular service on a netgear LM1200 modem no ipv6 gateway:

So there's no DHCPv6 server on the T-Mobile side assigning the address in the first place, as far as I can determine.

Do a packet capture on the WAN port for DHCPv6-PD. The packets should contain the prefix for your LAN.

I have attached a DHCPv6-PD capture.

Use Wireshark to take a look at frame 15 where you will see this:

The last line shown is the prefix provided by my ISP. If you don't see that on the pfsense WAN port, you will not be able to provide IPv6 on the LAN.

dhcpv6_capture.pcapng

dem

@jknott said in T-Mobile cellular service on a netgear LM1200 modem no ipv6 gateway:

If you don't see that on the pfsense WAN port, you will not be able to provide IPv6 on the LAN.

As I mentioned previously, everything works fine after both devices are rebooted, but IPv6 stops working the first time the address changes.

ddbnj

@jknott

Dumb question but how do I do a packet capture for just DHCPv6? I don't see that as a filter on the pfsense GUI. I tried ports 546 and 547. Would that work?

ddbnj

@jknott

Thanks again to all who have replied. I'm learning more today than in a while, even after the pfsense hangout about IPv6 from @jimp in 2015.

Here is what wireshark analyzed from packets captured (546 or 547) on the pfsense interface for my cellular modem in bridge mode. The interface is configured at DHCPv6. No other configuration changes. I released and then renewed the lease from the modem.

Frame 2: 130 bytes on wire (1040 bits), 130 bytes captured (1040 bits)
Encapsulation type: Ethernet (1)
Arrival Time: May 18, 2021 14:49:16.414066000 Eastern Daylight Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1621363756.414066000 seconds
[Time delta from previous captured frame: 0.609042000 seconds]
[Time delta from previous displayed frame: 0.609042000 seconds]
[Time since reference or first frame: 0.609042000 seconds]
Frame Number: 2
Frame Length: 130 bytes (1040 bits)
Capture Length: 130 bytes (1040 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ipv6:udp:dhcpv6]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: Globalsc_0b:1d:2f (f0:ad:4e:0b:1d:2f), Dst: IPv6mcast_01:00:02 (33:33:00:01:00:02)
Destination: IPv6mcast_01:00:02 (33:33:00:01:00:02)
Source: Globalsc_0b:1d:2f (f0:ad:4e:0b:1d:2f)
Type: IPv6 (0x86dd)
Internet Protocol Version 6, Src: fe80::f2ad:4eff:fe0b:1d2f, Dst: ff02::1:2
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
.... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
.... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
.... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000
Payload Length: 76
Next Header: UDP (17)
Hop Limit: 1
Source Address: fe80::f2ad:4eff:fe0b:1d2f
Destination Address: ff02::1:2
[Source SA MAC: Globalsc_0b:1d:2f (f0:ad:4e:0b:1d:2f)]
User Datagram Protocol, Src Port: 546, Dst Port: 547
Source Port: 546
Destination Port: 547
Length: 76
Checksum: 0xe3b5 [unverified]
[Checksum Status: Unverified]
[Stream index: 0]
[Timestamps]
UDP payload (68 bytes)
DHCPv6
Message type: Solicit (1)
Transaction ID: 0x1840b4
Client Identifier
Option: Client Identifier (1)
Length: 14
DUID: 000100012831f67ef0ad4e0b1d2f
DUID Type: link-layer address plus time (1)
Hardware type: Ethernet (1)
DUID Time: May 14, 2021 23:03:26.000000000 Eastern Daylight Time
Link-layer address: f0:ad:4e:0b:1d:2f
Identity Association for Non-temporary Address
Option: Identity Association for Non-temporary Address (3)
Length: 12
IAID: 00000000
T1: 0
T2: 0
Elapsed time
Option: Elapsed time (8)
Length: 2
Elapsed time: 0ms
Option Request
Option: Option Request (6)
Length: 4
Requested Option code: DNS recursive name server (23)
Requested Option code: Domain Search List (24)
Identity Association for Prefix Delegation
Option: Identity Association for Prefix Delegation (25)
Length: 12
IAID: 00000000
T1: 0
T2: 0

As far as I can tell, I am not receiving the needed IPV6 prefix. Correct?

-Devan

JKnott

@ddbnj

In Packet Capture, filter on DHCPv6, port 546 or 547. Doesn't matter which. If you have an external connection method, such as a data tap, you can connect a computer and run Wireshark. You'll want to capture it during a reboot, so as to get the entire sequence. If you're using Packet Capture, shut down pfsense and disconnect the WAN cable. Then boot up pfsense, start Packet Capture and reconnect the WAN cable.

JKnott

@ddbnj said in T-Mobile cellular service on a netgear LM1200 modem no ipv6 gateway:

Here is what wireshark analyzed from packets captured (546 or 547) on the pfsense interface for my cellular modem in bridge mode.

It's better to upload the capture file, as I did above. There's a lot of detail in those captures and you really need to use Wireshark to analyze it.

ddbnj

@jknott

I have been doing this via a site to site VPN. Since this will involve physical access, I will visit the site next week and try all the above.

When I get a capture file, I'll revist this.

Thanks,

Devan

JKnott

@ddbnj

Then I can only assume you didn't reboot pfsense. That's pretty much necessary to get the full sequence. Otherwise, you only get renewals.