http uses TCP not UDP. That is much of the problem you were having earlier.
1 Like
But there is zero reason to get rid of these... really if the prefix is retracted/lost all GUAs quickly loose validity, while ULAs will still allow to reach the devices o the local network...
Yes, these additional addresses take a short while to get used to, but they offer real utility, so I would recommend to first see wether one can learn to instantaneously recognise and categorise these as ULAs and ignore where appropriate.
OpenWrt offers IMHO quite a nice IPV6 configuration by default, learning to live with it can help reduce the amount of manual configuration necessary after each major upgrade...
3 Likes
yes, corrected that.
If I understood correctly, this self hosted website with IPv6 can only be accessed by clients who also got IPv6 based ip address
For eg, from a client who got IPv6 address
XXX@pinas:~ $ curl -I http://[2406:XXX:XX:2XX::6]
HTTP/1.1 200 OK
From a client who only got IPv4 address
XXXu@headscale:~$ curl -I http://[2406:XXX:XX:2XX::6]
curl: (7) Failed to connect to 2406:7400:51:2ea6::6 port 80 after 0 ms: Couldn't connect to server
From my little reading around this, I saw with Teredo tunneling IPv4 clients also can access this.
Wanted to ask here is that best way around this?
Also another question is, when Router get restarted or ISP pushed new IPv6-PD,
Is rpi supposed to automatically update inet6 address accordingly?
Or should I be restarting rpi to get the new address?
When I test this scenario, I don't see rpi updating to new address in ifconfig command.
You could rent a cloud server with dual stack and run some protocol translator like jool there to translate, because without some sort of translation somewhere pure IPv4 clients will not be able to reach a pure IPv6 server.
By cloud server with dual stack you mean, a cloud server with public IPv4 and IPv6?
Yes, any protocol translator needs to be able to handle both IP versions.
Ideally you would assert that the clients all learn IPv6... that would be the least hassle for you...
1 Like
Just documenting here (for myself or others researching on same setup).
I registered an account dynv6.com and created a zone.
Then I installed ddclient on raspberry pi(now I understand why @moeller0 recommended to do this on pi)
sudo apt install ddclient
Edit /etc/ddclient.conf as below,
ssl=yes
protocol=dyndns2
#use=if, if=eth0
#use=cmd, cmd='curl -k -s http://checkip6.spdyn.de'
use=web, web=checkip6.spdyn.de/
server=dynv6.com
daemon=300
login=none
password=<you will get it from dynv6.com>
<your zone>
sudo systemctl enable ddclient
sudo systemctl stop ddclient
sudo systemctl stop start
we can run,
sudo journalctl -u ddclient.service -f
to check logs
This will run every 5 minute get current IPv6 address and update dynv6.com AAAA record.
I need to see, if a better free dynamic dns provider is available.
No, DHCPv6 works like v4 in that it does not push configuration to the client. The client has to request a renewal before it can be aware of upstream changes. If the upstream network is prone to change, use short lease times to speed up this process.
If you set norelease 1 on the wan6, the ISP may keep the same prefix for you while the router reboots. Rebooting a main router tends to disrupt a lot of things so avoid doing it.
If you have a cloud VPS you could set up a Wireguard tunnel (v6 outside, v4 inside) from the VPS to your Pi so that v4 only clients can reach the website natively with v4. Or of course serve the website directly from the VPS, but that would make this whole thread moot.
2 Likes
Yes, I understood.
I was more trying to understand if ISP push new IPv6-PD at certain intervals.
I am now testing connectivity to my website hosted on rpi from different outside networks.
From my iPhone with 5g network, I can access the site as well ping the host and get replies.
I have two oracle cloud instances, one with IPv4 and another with dual stack.
Both are on the same vnc and subnet and uses common security list (ingress/egress rules)
From the IPv4 only instance, I can ping google.com (it resolved to IPv4 address) and get replies. When I ping my host, it resolved the name and showed correct IPv6 address of website but ping failed, which is understandable.
From the dual stack instance, when I ping google.com (it resolved to IPv6 address) and no replies. When I ping my host, it resolved the name and showed correct IPv6 address of website but no replies. I thought from IPv6 source, I should be able to access the site.
Any thoughts?
Mmmmh, please try the following on the cloud machines and post the results here:
IPv4
mtr -ezbw4 -c 100 one.one.one.one
and
IPv6
mtr -ezbw6 -c 100 one.one.one.one
The goal is to see how far you get with IPv6 compared to IPv4.
Note thrse mtr invocations will take almost 2 minutes and will only show output at the very end...
From IPv4 only instance,
xxx@xxx:~$ mtr -ezbw4 -c 100 one.one.one.one
Start: 2024-11-17T14:17:47+0530
HOST: xxxxxx Loss% Snt Last Avg Best Wrst StDev
1. AS31898 140.xx.xxx.xx 0.0% 100 0.2 0.2 0.2 0.4 0.0
2. AS9498 nsg-static-002.202.72.182.airtel.in (182.72.202.2) 0.0% 100 0.5 1.3 0.4 38.6 4.3
3. AS9498 nsg-static-001.202.72.182.airtel.in (182.72.202.1) 0.0% 100 0.9 1.6 0.8 19.3 2.6
4. AS??? 182.79.142.168 0.0% 100 1.5 5.7 1.4 36.4 8.3
5. AS9498 182.79.223.41 0.0% 100 2.3 2.7 1.9 23.7 3.1
6. AS13335 one.one.one.one (1.1.1.1)
From dual stack Instance,
xxxx@xxxx-xxxx:~$ mtr -ezbw4 -c 100 one.one.one.one
Start: 2024-11-17T14:23:21+0530
HOST: xxxxx-xxxx Loss% Snt Last Avg Best Wrst StDev
1. AS31898 140.xx.xxx.xxx 0.0% 100 0.2 0.2 0.2 0.3 0.0
2. AS9498 nsg-static-002.202.72.182.airtel.in (182.72.202.2) 0.0% 100 0.5 2.4 0.4 32.9 5.7
3. AS9498 nsg-static-001.202.72.182.airtel.in (182.72.202.1) 0.0% 100 2.6 4.4 0.8 23.8 5.9
4. AS9498 116.119.33.197 0.0% 100 6.5 3.9 1.4 37.6 6.3
5. AS9498 182.79.223.41 0.0% 100 2.0 3.5 1.8 34.8 5.7
6. AS13335 one.one.one.one (1.0.0.1) 0.0% 100 1.4 1.4 1.3 1.7 0.0
xxxx@xxx:~$ mtr -ezbw6 -c 100 one.one.one.one
Start: 2024-11-17T14:18:35+0530
HOST: xxxxx-xxx Loss% Snt Last Avg Best Wrst StDev
Basically from dual stack instance, the first command you gave produced results and second command didnt give any output at all.
While adding the IPv6 to the subnet,
In the highlighted part, I entered 7E where as in a youtube example, he added 01 would this have caused the issue happening for me?
If any one know what does it mean?
Thanks so this implies that the dual stack oracle VM lacks IPv6 connectivity in general and this is no issue with your OpenWrt configuration.
I have zero experience with oracle cloud, so can not really help, but what does ifconfig on the dualstack VM reveal about IPv6 addresses?
xxxx@xxxxx:~# ifconfig
ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000
inet 10.0.0.84 netmask 255.255.255.0 broadcast 10.0.0.255
inet6 fe80::xxxx:xxxx:395e prefixlen 64 scopeid 0x20<link>
inet6 2603:xxxx:xxxx:997e:1c9b:4699:b55a:87b prefixlen 128 scopeid 0x0<global>
ether 02:00:17:00:39:5e txqueuelen 1000 (Ethernet)
RX packets 4233 bytes 17038907 (17.0 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3045 bytes 554470 (554.4 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 94 bytes 12589 (12.5 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 94 bytes 12589 (12.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Fixed the issue.
The security list (ingress/egress rules) didnt have the correct rules.
Basically a subnet is associated to a security list. But I was adding the rules to a new security list which have no association with the subnet.
Once I added the egress/ingress rules to the correct security list everything started working!
And also, now I can reach my self hosted IPv6 website from oracle cloud instance.
1 Like
@egc
For hosting the website we added firewall rule
config rule
option name 'rpi-website'
option src 'wan'
option dest 'lan'
option dest_port '80'
option target 'ACCEPT'
option family 'ipv6'
list dest_ip '::6/-64'
list proto 'tcp'
I am trying similar way for router admin page as well,
config rule
option name 'router'
option src 'wan'
option dest 'lan'
option dest_port '80'
option target 'ACCEPT'
option family 'ipv6'
list dest_ip '::1/-64'
list proto 'tcp'
changed to list dest_ip '::1/-64', but its not working.
Only port forward is working for router page, any thoughts? That too when port foward rule applied, dest_ip accepting only full ip. its not accepting '::1/-64'
The admin page is an internal service. Remove the dest lan it should only have src wan
It is not considered safe to open uhttpd/LuCI to the Internet. Use a VPN or ssh tunnel to reach LuCI safely from a remote location.
2 Likes