Messages

Bump for visibility.  I hope this is allowed.

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)

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?

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?

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?"  :'(

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

Thanks for the idea.  I didn't even know you could do that.  I do appreciate the suggestion!

Well this works....

Code Select Expand

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?

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 :)

Here is my Ubuntu box:

Code Select Expand


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:

Code Select Expand


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


Code Select Expand


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


Code Select Expand


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


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:

Code Select Expand


root@OPNsense:~ # ifconfig vtnet1 | grep inet\
inet 158.69.185.70 netmask 0xffffffff broadcast 158.69.185.70

Code Select Expand

root@OPNsense:~ # netstat -4 -rn | grep default
default            192.95.32.254      UGS      vtnet1

Code Select Expand


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


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"

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.

Hi All,

I recently upgraded from 22.7 -> 23.1.1_2.

I use OPNSense at home as a VPN server for my mobile phone/laptop/etc.  My phone, laptop, wife's phone, etc have 2 wireguard profiles:  1 to connect via ipv4 to my static ip, and one via ipv6.  The Ipv6 for opnsense sits behind an he.net 6-in-4 tunnel.

While the ipv4 still works, ipv6 just hangs.  I've tried wireguard & wireguard-go with the same result.

Anyone seen this before?  This was working for a very long time on 22.x and just doesn't work after the upgrade.

I'd appreciate any suggestions.

Ok, my first error was forgetting to turn the dictionary back into json.

I've updated the POST as follows:

Code Select Expand

myupdaterecord = requests.request("POST", postRecordURL, auth=(api_key, api_secret), json=json.dumps(myonerecord_response))

However:

Code Select Expand

print(myupdaterecord.content)

now gives me:

Code Select Expand

b'{"result":"failed"}'