6rd Gateway monitoring

[hemirunner426]

It appears gateway monitoring doesn't work on a 6rd prefix setup over PPPoE.

IPv6 works from the router (via ping6) and services the LAN with no issue.

With the gateway left as default, the gateway shows as online.  If I enable monitoring and put in a google DNS server to monitor the status will change to down.  IPv6 on the router and the LAN is unaffected (operational).

The log shows the following entry:

Code Select Expand

/system_gateways.php: The WAN_6RD IPv6 gateway address is invalid, skipping.

The gateway (in it's default state) configures the gateway address as:

Code Select Expand

2602::205.171.2.64

This is verifiable in wan_stf_routerv6 and wan_stf_defaultgwv6

'netstat -r | grep default' has the following output:

Code Select Expand

default            phn4-dsl-gw11.phn4 UGS      pppoe0
default            2602::cdab:240     UGS     wan_stf

[franco]

That may be true depending on your version and ISP. I don't know either and it would be nice to know this to start with.

As for getting traceable clues your contents of /tmp/wan_stf_routerv6 is actually "2602::205.171.2.64" ?

The line of code referenced does not exist on the development version and what is to become 22.1 since:

https://github.com/opnsense/core/commit/65779b80bb1ae7

indicating that no address could be found to begin with. But this isn't the gateway IP, it's the interface IP for the gateway to reach. And if you use a GUA for monitoring you can't get away with a link local interface address. It's all a bit tricky this IPv6...

The following would help too:

# ifconfig wan_sft


Cheers,
Franco

[hemirunner426]

ISP: CenturyLink Fiber

# cat /tmp/wan_stf_routerv6

Code Select Expand

2602::205.171.2.64

# ifconfig wan_stf

Code Select Expand

wan_stf: flags=4041<UP,RUNNING,LINK2> metric 0 mtu 1280
        inet6 2602:b8:431:dd00:: prefixlen 24
        groups: stf
        v4net 184.4.49.221/0 -> tv4br 205.171.2.64
        nd6 options=101<PERFORMNUD,NO_DAD>


# ping6 2602:b8:431:dd00::

Code Select Expand

PING6(56=40+8+8 bytes) 2602:b8:431:dd00:: --> 2602:b8:431:dd00::
16 bytes from 2602:b8:431:dd00::, icmp_seq=0 hlim=64 time=0.086 ms
16 bytes from 2602:b8:431:dd00::, icmp_seq=1 hlim=64 time=0.044 ms
16 bytes from 2602:b8:431:dd00::, icmp_seq=2 hlim=64 time=0.038 ms

# ping6 2602::205.171.2.6

Code Select Expand

PING6(56=40+8+8 bytes) 2602:b8:431:dd00:: --> 2602::cdab:206

--- 2602::205.171.2.6 ping6 statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss


Thanks Franco.
Let me know if you need anything else.

[franco]

Thanks for the info... I'm assuming this is 21.7.7... Let's see our possibilities:

1. Either ping doesn't work for any address or just the gateway IP, confirm by using 2001:4860:4860::8888 manually as monitor address.

2. Maybe the gateway doesn't respond to ping as per ISP configuration. You can confirm this by doing a packet capture on WAN to see if ping packets to gateway address leave correctly, but do not return.

3. The firewall might block these responses due to bogons or default configuration. Enabling default block logging under System: Settings: Logging might reveal this in live view.

4. The routes are not set up correctly for direct traffic to gateway IP at least from the IPv6 side. Depending on the network length being delegated this could happen due to confusion about the assigned subnet for WAN and LAN. It sort of circles back to point 1 too. "netstat -nr" would help shed a bit of light on this.


Cheers,
Franco

[hemirunner426]

1. Either ping doesn't work for any address or just the gateway IP, confirm by using 2001:4860:4860::8888 manually as monitor address.

It appears its only '2602::205.171.2.64' that will not respond to ping.  '2001:4860:4860::8888' will respond on the command line but fails as a monitor address.  The log produces the following:

Code Select Expand

022-01-11T10:33:10 opnsense[7295] /system_gateways.php: The WAN_6RD IPv6 gateway address is invalid, skipping.

2.  I see the echo request but a reply never comes through.

Code Select Expand

0:36:35.525335 IP 184.4.49.221 > 0.0.0.0: IP6 2602:b8:431:dd00:: > 2602::cdab:206: ICMP6, echo request, seq 10, length 16

3. I don't see IPV6 ICMP being blocked here.  Nothing sticks out to my eye.

4. #netstat -nr

Code Select Expand

Internet6:
Destination                       Gateway                       Flags     Netif Expire
default                           2602::cdab:240                UGS     wan_stf
::1                               link#8                        UH          lo0
2602::/24                         link#20                       U       wan_stf
2602:b8:431:dd00::                link#20                       UHS         lo0
2602:b8:431:dd00::/64             link#16                       U      igb1_vla
2602:b8:431:dd00::1               link#16                       UHS         lo0
fe80::%igb0/64                    link#1                        U          igb0
fe80::%igb1/64                    link#2                        U          igb1
fe80::2e0:67ff:fe27:ada1%igb1     link#2                        UHS         lo0
fe80::%lo0/64                     link#8                        U           lo0
fe80::1%lo0                       link#8                        UHS         lo0
fe80::%igb0_vlan201/64            link#11                       U      igb0_vla
fe80::2e0:67ff:fe27:ada0%igb0_vlan201 link#11                   UHS         lo0
fe80::%igb1_vlan3/64              link#12                       U      igb1_vla
fe80::2e0:67ff:fe27:ada1%igb1_vlan3 link#12                     UHS         lo0
fe80::%igb1_vlan4/64              link#13                       U      igb1_vla
fe80::2e0:67ff:fe27:ada1%igb1_vlan4 link#13                     UHS         lo0
fe80::%igb1_vlan5/64              link#14                       U      igb1_vla
fe80::2e0:67ff:fe27:ada1%igb1_vlan5 link#14                     UHS         lo0
fe80::%igb1_vlan6/64              link#15                       U      igb1_vla
fe80::2e0:67ff:fe27:ada1%igb1_vlan6 link#15                     UHS         lo0
fe80::%igb1_vlan1/64              link#16                       U      igb1_vla
fe80::2e0:67ff:fe27:ada1%igb1_vlan1 link#16                     UHS         lo0
fe80::2e0:67ff:fe27:ada0%ovpns1   link#17                       UHS         lo0
fe80::2e0:67ff:fe27:ada0%ovpnc3   link#18                       UHS         lo0
fe80::%pppoe0/64                  link#19                       U        pppoe0
fe80::2e0:67ff:fe27:ada0%pppoe0   2602::cdab:240                UGHS    wan_stf
fe80::2e0:67ff:fe27:ada1%pppoe0   2602::cdab:240                UGHS    wan_stf


[franco]

Hmm, I wasn't expecting (1) but it seems like the easiest one to fix if I understand correctly:

https://github.com/opnsense/core/commit/9ac916cdc30c

# opnsense-patch 9ac916cdc30c

Incidentially, the code for 22.1was already changed in this way while I was reworking the interface function... find_interface_ip*() variants are particularly untrustworthy.

Fingers crossed :)


Cheers,
Franco

[hemirunner426]

The patch took care of the issue.

Thanks!

[franco]

Nice thanks. I don't want to burden 21.7.x with side effects for this as it's already done on 22.1 and that will be out by the end of the month anyway.


Cheers,
Franco