Greetings,
I connect to my router (CHR) via SSH with putty and use it as my VPN server sometimes, although my router does have IPv6 when I connect to it via SSH I only get access to IPv4 and websites doesn’t detect it’s IPv6.
How I can set it to route the forwarding traffic from SSH client via IPv6 as well (IPv4 and IPv6) or IPv6 only?
Thanks in advance for any help 
Any solution for this?
Can you elaborate on how you connect via the ssh “tunnel”? Do you configure forwarding to a particular address:port combination (or a list of them) or you use the proxy mode tunneling?
@sindy
I don’t use nor set specific ports for forwarding just enable forwarding under routeros SSH settings and then use putty to connect to router and open a local dynamic port to use as socks proxy on my browser.
Maybe you can try to ssh into router with IPv6?
My ISP doesn’t give me public IPv6.
When creating ssh connection to your router, define “local port forwarding” with IPv6 address of remote host. Command line example in linux would look like this:
ssh 192.168.88.5 -L 20202:[fe80::ae1f:6bff:feb0:26bc]:80
The trick on OpenSSH client is to enclose the IPv6 address in square brackets.
I don’t know how exactly this part would look when using some other software (e.g. putty on windows), but I guess it should be similar. I also don’t know if ssh service on ROS (as compared to OpenSSH on linux, used in my example verification) comes with some gotchas when it comes to mixing traffic between IPv4 and IPv6 (in principle this should not matter at all, it’s about payload).
Then I can simply open http://localhost:20202/ in local browser and I get web page from remote server …
Tried that as well with putty however couldn’t get any traffic over IPv6, which I guess is due to the fact that there are some configs and setting missing on my routeros end which I don’t know of 
On Linux is very easy whereas if a server got public IPv6 on it’s interface and ssh to it you get access to that for proxy forwarding without any additional settings on Linux itself. And that is why I’m clueless regarding what should I setup on routeros cause Linux doesn’t require any settings.
I have just tested the suggestion of @mkx with PuTTY where I’ve connected to an IPv4 address of a CHR running 7.15.3 with a very basic IPv6 configuration (as in “just a few global addresses added”), and with a single TCP port (23456) forwarded to port 22 on a global address of a reachable IPv6 neighbor (another CHR). And when trying to connect to localhost:23456 on the machine running the PuTTY, I did connect successfully to that other CHR using IPv6 on the path between the two CHRs (confirmed by sniffing).
So I’d say try this (single port forwarding) first, and only move on to the dynamic proxy way once you make this simpler setup work.
Ok so to test that I’ve another CHR router with IPv6 I’ve enabled WWW on port 80 under it’s services (Let’s call this router CHR2) and the goal is to SSH into CHR1 via IPv4 and connect to it via browser socks proxy and be able to open WWW of CHR2 via it’s public IPv6, right?
Is there any special settings required for CHR1?
right.
None I would be aware of. If you can telnet to port 80 on the global IP of CHR2 from CHR1 (in terms that the TCP connection gets established) and ssh forwarding is enabled (forwarding-enabled: both) on CHR1, it should work also via the SSH, as in case of forwarding via SSH, it is CHR1 that acts as the TCP client for the CHR1 to CHR2 part of the overall path.
Thank you very much @sindy and @mkx
I was able to get it to work now on https://test-ipv6.com/ I get 10/10 score (shows both IPv4 and IPv6 as working), now how can I force it to use only IPv6 for this traffic (When I ssh into router and use it as SSH tunnel server).
And possibly is there a way to assign another IPv6 address from my /64 pool than the one router itself uses? (although ISP gave me /64 however they said I should set it with /48 under /ipv6 address in order to be able to use IPv6 so it’s with /48 right now, I just felt like I should mention this as well )
Can srcnat help here or since it’s different IP from one that router is using it wouldn’t work.
You can src-nat to any address you want but in order that the response could reach your router, the routers on the return path must send it to your router, and if L2 network is used between your router and the neighbor, your router must respond to ARP or ND messages for that address.
However, the thing is that there is no criteria on the source side that you could use to distinguish the traffic generated by the sshd process on the router from the traffic generated by other processes. I.e. if you use /tool fetch on the router itself to download a html document from x::x and then you use a web browser on your PC to download a html document from x::x via the ssh tunnel, the only difference as seen by the router’s firewall will be the source port which is ephemeral anyway.
Seems like not much to do here
Even we cannot block IPv4 for SSH? Assuming we use the same IPv6.
Cause if this is doable I can later setup NDP in order to give each device their own IPv6 and the one remaining on router will be used for SSH much like it’s only assigned to it.
It did not come to my mind, but indeed - if you cannot identify traffic generated by the router itself, you may instead identify the one that was not. So if you don’t mind setting a connection-mark or a packet-mark to the initial packets of any forwarded traffic in chain forward in mangle, you can use that to select a NAT rule - what has a mark has been forwarded, what doesn’t has been locally generated. But you’ll still be unable to distinguish a request towards a remote SSH server from the router itself acting as an SSH client from a tunneled request to the same remote server from an SSH client of the router.
Does that mean I cannot make it IPv6-only? or at least IPv6 first then if timed out IPv4?
You may … by using firewall filter rules. Tunneled traffic would appear in chain=output when exiting SSH tunnel. But as @sindy already explained, you would not be able to distinguish tunneled traffic from traffic originating from router itself. If this doesn’t bother you (i.e. you don’t want to use IPv4 for ssh connections, initiated by router itself), then you can use firewall filter rules. If you need ssh outgoing connections, initiated by router itself, and the targets are IPv4 addresses, then … you’ll have to think real hard to come up with something.