I found the issue, there was 128.0.0.0/1 in the list causing the problem....
no all pings works as supposed to
so I am still trying to filter the amazon properly...
is it that I should upload the amazon IPs collection from the json, and then compare if it is there and write it as tv-list-nflx then move from that list to list netlike which mangle the traffic through the vpn
?
half of the line, but caused a lot of trouble... good that it get solved
Correct, that's exactly how I did it.
Luckily, most of the addresses you need, you'll 'harvest' fast; later you'll from time to time check the tv-list-nflx list and add the address ranges which got caught meanwhile. From json you don't need everything, extract only "service": "AMAZON" IPv4 addresses
Observations/Comments
- This line is not bad but doesnt seem to be optimal for most scenarios....
/ip/firewall/mangle
add action=change-mss chain=forward comment="Clamp MSS to PMTU for outgoing packets" new-mss=clamp-to-pmtu out-interface=wireguard1 \
passthrough=yes protocol=tcp tcp-flags=syn
Suggest this one is more fullproof, if there are issues browsing through a third party internet.
/ip firewall mangle
add action=change-mss chain=forward new-mss=1380 out-interface=wireguard1 protocol=tcp tcp-flags=syn tcp-mss=1381-65535
- Recommend perhaps an alternative approach. If you are using your appletv, to access APPS, (and its lanip is 10.0.0.10) then one has to ensure the apple tv connection works first to verify your identity but then you want all the apps to go out wireguard for actual streaming, I think! Thus it would seem to me, it would be easier to bypass wireguard for the apple tv connection to its servers, and then ALL other internet traffic from 10.0.0.10 goes out wireguard be it amazon prime, netflix etc...
For example this could be your firewall address list and both these domains will resolve to IP addresses.
Found by doing a websearch and I suppose you could sniff appletv traffic from the router as well.
We have to capture initial traffic apple conducts when turning on to verify appleTV and ensure it goes out our local WAN!!
/ip firewall address-list
add address=icloud.com list=TESTFUN
add address=tv.apple.com list=TESTFUN
Then simply do this and modify the first rule in the firewall forward chain (fasttrack rule) so it can be kept for all other traffic.
/ip firewall mangle
add chain=forward action=mark-connection connection-mark=no-mark src-address=10.0.0.10 \
dst-address-list=TESTFUN new-connection-mark=appletv passthrough=yes
add chain=prerouting action=mark-routing connection-mark=appletv \
new-routing-mark=main passthrough=no
add chain=forward action=fasttrack-connection connection-state=established,related connection-mark=no-mark
/routing rule
add action=lookup-only-in-table min-prefix=0 table=main comment="permits local traffic"
add action=lookup-only-in-table src-address=10.0.0.10 table=t-wg1
SInce mangle rules take precedent over routing rules, the traffic from the appletv going toward apple servers will be permitted and will use the main table. In the routing rules the first rules ensure any subnet traffic to subnet traffic or to the router will not be touched by the traffic going out wireguard.
If valid this approach could potentially be used by any type of streaming box.........
If anyone sees any holes in this approach please let me know.
Not sure what is meant by kill switch?
The only traffic being sent out wireguard is from 10.0.0.10.
We select lookup only in table for the action so even if the router somehow knew if wireguard was up or down, the traffic would never make it to the local WAN.
However, the router, as wireguard is unique, and is not a normal interface, has no clue if the interface wireguard1 is up or down and thus always assumes up and thus will never send 10.0.0.10 out the local WAN. I suppose if you accidentely disabled or deleted the wireguard interface not sure what the outcome would be.... but we do know, with the action setting, the config would not allow the router to look for an alternative route on the main table.
This is correct - killswitch in this scenario is totally obsolete (that's why 'optionally'), and more to give peace of mind to those who are (for whatever reason) concerned that some packets will make it directly to WAN. 
in my case, I run appleTV, Stan, Paramount local in australia aka general traffic,
then I have Czech TV 2 apps, OnePlay and iVysilani, and I need to sniff those IP for that and mark them as ct_voyo,
then I have netflix which goes to turkey.
find out for Czech tv, I have to also forward DNS through VPN otherwise I am not in region. Netflix does not like it, and works only without this DNS forward
the biggest struggle I have is to sniff all the IPs for particular provider. and add /15 just in case
I had to do it manually and it is working now as it supposed to... but once they change range. its gonna be hell again
I use access_vpn list as a source which includes my phone, Apple TV 192.168.4.36 and other devices...
this is my last version of the config, with manually sniffing ip through the script which doesnt do what it supposed so I have to go and delete or adjust, it sniffs all domanins 
honza_conf.txt (48.6 KB)