Hello,
So this is a weird one (IMHO). I have a host at OVH with ipv6. However my ipv6 static ip address has a default gateway that isn't in the same /64 as my static ip block. The same happens with ipv4.
When configuring ipv4, the gatway is set as "onlink". However in ipv6 it is not, and the routing table (nestat -6 -rn in the shell) shows no default gateway after completing the setup.
Not sure if this is a bug or not...? Sure, it would be better to use link-local, but that is not what OVH is giving me/supporting.
Any comments/fixes appreciated.
Oddly enough, the gateway is listed as "online" in "Lobby -> Dashboard"
However if I ping the gateway from "Interfaces -> Diagnostics -> Ping" it returns "no route to host"
Hi,
> However my ipv6 static ip address has a default gateway that isn't in the same /64 as my static ip block.
This is an impossible configuration. The gateway needs to be in your assigned /64 or must be link-local which it very often is due to this limitation in IPv6.
Cheers,
Franco
This works in FRR fine.
I also have a non-local default gateway for ipv4 as well (ovh assigns /32 to me for ip address with default gateway outside of this subnet obviously) and this works fine in opnsense:
root@OPNsense:~ # ifconfig vtnet1 | grep inet\
inet 158.69.185.70 netmask 0xffffffff broadcast 158.69.185.70
root@OPNsense:~ # netstat -4 -rn | grep default
default 192.95.32.254 UGS vtnet1
root@OPNsense:~ # ping 192.95.32.254
PING 192.95.32.254 (192.95.32.254): 56 data bytes
64 bytes from 192.95.32.254: icmp_seq=0 ttl=255 time=0.479 ms
64 bytes from 192.95.32.254: icmp_seq=1 ttl=255 time=0.623 ms
64 bytes from 192.95.32.254: icmp_seq=2 ttl=255 time=0.627 ms
^C
--- 192.95.32.254 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.479/0.576/0.627/0.069 ms
root@OPNsense:~ # traceroute 192.95.32.254
traceroute to 192.95.32.254 (192.95.32.254), 64 hops max, 40 byte packets
1 192.95.32.254 (192.95.32.254) 0.684 ms 0.736 ms 0.794 ms
I know it works in IPv4 which made me mention it doesn't work in IPv6 as the kernel will not allow it.
Cheers,
Franco
Here is my Ubuntu box:
root@yul-vpnr01:~# ip a show dev ens18
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 02:00:00:f3:a8:17 brd ff:ff:ff:ff:ff:ff
altname enp0s18
inet 198.50.158.185/32 scope global ens18
valid_lft forever preferred_lft forever
inet6 2607:5300:60:2f46::1:2/64 scope global
valid_lft forever preferred_lft forever
And my netplan config:
root@yul-vpnr01:~# grep -A9 routes: /etc/netplan/00-installer-config.yaml
routes:
- to: default
via: 192.95.32.254
on-link: true
- to: 173.161.5.168/29
via: 192.95.32.254
on-link: true
- to: default
via: 2607:5300:60:2fff:ff:ff:ff:ff
on-link: true
root@yul-vpnr01:~# ping 2607:5300:60:2fff:ff:ff:ff:ff
PING 2607:5300:60:2fff:ff:ff:ff:ff(2607:5300:60:2fff:ff:ff:ff:ff) 56 data bytes
64 bytes from 2607:5300:60:2fff:ff:ff:ff:ff: icmp_seq=1 ttl=64 time=0.709 ms
root@yul-vpnr01:~# traceroute 2607:5300:60:2fff:ff:ff:ff:ff
traceroute to 2607:5300:60:2fff:ff:ff:ff:ff (2607:5300:60:2fff:ff:ff:ff:ff), 30 hops max, 80 byte packets
1 _gateway (2607:5300:60:2fff:ff:ff:ff:ff) 0.825 ms 0.922 ms 1.038 ms
Should I mention this is the FreeBSD kernel we are talking about? ;)
I swear I'm not trying to kid you.
Yep i do understand, but I find it hard to believe a bare metal provider is going to provide an solution that only works in Linux. I'm afraid to try windows with a public ip & this gateway setup :)
Well this works....
root@OPNsense:~ # route -6 add 2607:5300:60:2fff:ff:ff:ff:ff/128 -iface vtnet1
add host 2607:5300:60:2fff:ff:ff:ff:ff/128: gateway vtnet1
root@OPNsense:~ # route -6 add default 2607:5300:60:2fff:ff:ff:ff:ff
add net default: gateway 2607:5300:60:2fff:ff:ff:ff:ff
root@OPNsense:~ # ping ipv6.google.com
PING6(56=40+8+8 bytes) 2607:5300:60:2f46::102:1 --> 2607:f8b0:4020:806::200e
16 bytes from 2607:f8b0:4020:806::200e, icmp_seq=0 hlim=115 time=1.262 ms
It seems FreeBSDs way of doing a route "onlink" is to use -iface in the route command.
Any way we can get this in the installer? ;D
Edit: I went to System->Routes->Configuration to add a route but it doesn't give me an option to set an interface, and it seems I must select a gateway....Any other way to possibly do this?
Install a standard FreeBSD 13.2 with correct configuration and use the bootstrap method?
Sorry, forget it - you are past installation, already.
Thanks for the idea. I didn't even know you could do that. I do appreciate the suggestion!
I came up with another idea.
I pinged the ipv6 gw from a working linux host.
Snagged the mac address.
Then tcpdumped matching on mac address , looking for traffic from fe80::/10
An IP popped up.
I defined that as a gateway in OPNSense and I can now ping ipv6.google.com from OPNSense box.
If they are doing VRRP or something on the actual gateway IP they give out & this host goes down I suppose that will break my ipv6. May see if I can find some VRRP packets & find a second LL address and then do gateway monitoring.
Have you asked them about a permanent link-local address? Really using link-local for gateways is considered best practice.
I've asked that.
Support came back with: "We don't have access to your system to know the link-local address..." and then sent me a link of how to do it on linux *sighs*
I meant the link-local address of their default-gateway.
That is exactly what I asked them. What is the LL of the gateway they are providing and support understood my question as "how do I find my own link local address?" :'(
So something else weird:
I added the LL I found in a tcpdump via the web UI (see attacchment), and the gw monitoring is working (it's pingable) but in the route table it looks like it's on loopback? Yet on the config page I assigned it to WAN ((which is vtnet1)
And no...it doesn't work.
@franco - is this expected behavior?
QuoteI added the LL I found in a tcpdump via the web UI (see attacchment), and the gw monitoring is working (it's pingable) but in the route table it looks like it's on loopback? Yet on the config page I assigned it to WAN ((which is vtnet1)
Sounds like you used a wrong LLA.
Try getting it from Interfaces>Diagnostics->NDP Table page. Locate the one that has a different MAC address than the one that has your GUA. You can also identify by Manufacturer name if it existed (eg: Cisco, Juniper etc).
Quote from: zan on February 16, 2024, 04:55:51 AM
QuoteI added the LL I found in a tcpdump via the web UI (see attacchment), and the gw monitoring is working (it's pingable) but in the route table it looks like it's on loopback? Yet on the config page I assigned it to WAN ((which is vtnet1)
Sounds like you used a wrong LLA.
Try getting it from Interfaces>Diagnostics->NDP Table page. Locate the one that has a different MAC address than the one that has your GUA. You can also identify by Manufacturer name if it existed (eg: Cisco, Juniper etc).
The LLA I found in the NDP table has the same MAC as the non LL gateway they gave me....
eg: MAC of ipv6 default gw = MAC of LL that I found, so I assume it's the same device. Is that a bad assumption?
Bump for visibility. I hope this is allowed.