A guide for Japan NTT users on IPoE/IPv6 setting (MAP-E only)

Installing and Using OpenWrt Network and Wireless Configuration
8

OK I get what you mean, the website does load, but as I clicking deeper inside it's getting much slower.

In my GitHub page there is another discussion about map.sh change, is that you as well? (However the map.sh content change looks difference from yours after running a diff check) Seems we are all trying to find solution to optimize.

BTW when I just finished the setup with default map.sh, I already saw that under firewall rules there is thousand of ports listed to map the ports (of course I didn't check one by one yet), maybe I should spend some more time to read them all.

9

I found out that the map.sh script is trying to map ICMP to a port, but fails due to some check in OpenWRT that does not allow ICMP to be mapped to a port. Doing so manually via nft (position is # handle at the end of the rule - you can get it by "nft -a list ruleset") and place it in between one of the rules in chain snat.
Here's the command I ran (replace position, oifname, IP and port range to match your setup):

nft add rule inet fw4 srcnat position 999 meta nfproto ipv4 meta l4proto icmp oifname "map-replaceme" counter packets 0 bytes 0 snat ip to 1.1.1.1:1234-1234

I needed only one rule for ping to work, but if we can make it generate the rules, then all can be used.

10

Why do we need port range for ICMP?

And I've checked the firewall already had the following srcnat rule which should indicate that ping is allowed?

ICMP egress device [MAP interface] rewrite source to [MAP IPv4 address]

11

Great work! You are right, map.sh has these troubles in fw4. In fw3, it worked.
This effectively fixed ping for me. Now just need to automate it. I will look into it.

12

So we can fix ping with a (very hacky) edit to /lib/netifd/proto/map.sh

I just added a new table in nftables called inet nathack and put the necessary icmp rules there, and put it in map.sh to automate it.

I can confirm that this effectively lets pings work.

If you are not using fwmarks to determine ports:

+nft add table inet nathack
+nft add chain inet nathack srcnat {type nat hook postrouting priority 0\; policy accept\; }
	    for portset in $(eval "echo \$RULE_${k}_PORTSETS"); do
              for proto in icmp tcp udp; do
	        json_add_object ""
...

                  json_add_string snat_port "$portset"
	        json_close_object
              done
+	      nft add rule inet nathack srcnat meta nfproto ipv4 meta l4proto icmp oifname "map-$cfg" counter packets 0 bytes 0 snat ip to $(eval "echo \$RULE_${k}_IPV4ADDR"):$portset

If you are using firewall.user to set the fwmark (recommended if it is JPNE/v6plus)

	json_add_array firewall
	  if [ -z "$(eval "echo \$RULE_${k}_PORTSETS")" ]; then
	    json_add_object ""
	      json_add_string type nat
	      json_add_string target SNAT
	      json_add_string family inet
	      json_add_string snat_ip $(eval "echo \$RULE_${k}_IPV4ADDR")
	    json_close_object
	  else
+local mark=10
+nft add table inet nathack
+nft add chain inet nathack srcnat {type nat hook postrouting priority 0\; policy accept\; }
	    for portset in $(eval "echo \$RULE_${k}_PORTSETS"); do
              for proto in icmp tcp udp; do
	        json_add_object ""
	          json_add_string type nat
	          json_add_string target SNAT
	          json_add_string family inet
	          json_add_string proto "$proto"
		 + json_add_string mark "$mark"
                  json_add_boolean connlimit_ports 1
                  json_add_string snat_ip $(eval "echo \$RULE_${k}_IPV4ADDR")
                  json_add_string snat_port "$portset"
	        json_close_object
              done
+	      nft add rule inet nathack srcnat meta nfproto ipv4 meta l4proto icmp oifname "map-$cfg" meta mark $mark counter packets 0 bytes 0 snat ip to $(eval "echo \$RULE_${k}_IPV4ADDR"):$portset

+	      mark=`expr $mark + 1`

	    done
	  fi
	  if [ "$maptype" = "map-t" ]; then
13

Just tested this and it worked perfectly. Seems like a complete solution now with fwmark. All sites load, passes nichibanbench and the connection is just as fast as IPv6 (350/350).

14

Almost complete solution....
There is the issue of fwmarks interfering with other things that use fwmarks like mwan3 or policy based routing.
But as long as those functions are not needed it's good enough I suppose.

In my case I need these functions, so I just run two OpenWRT VMs.

15

What was affected? Since I am also planning to put VPN on it and do policy routing

16

The basic thing that causes affects is that everything is fwmarked, and the fwmark that is set by other things like policy based routing get overwritten.

So far example, if you use mwan3, and tell it to route some traffic through another interface, it will all still go through the map-e interface.

I think by using masks, it can be resolved maybe, by editing the map.sh and the firewall.user files correctly, but I haven't looked into it hard enough. Maybe I will dedicate some time to do it.

17

I just managed to set up Wireguard via IPv4, but the performance is terrible at only 2mbps. Doing the same via IPv6 gives me around 152mbps. CPU usage is low, so not really sure what's causing it.

18

router as WG client? Did you try OpenVPN?

19

Understand, I have never done this with OpenWrt before (I use pfSense before and it's not working in this way), this packet marking way is more or less like the RouterOS from Mikrotik, so if we implement solution with mwan3 we have to think about it. Just don't know the precedence of fwmark, if we also use mwan3, will the fwmark by map-e go first (i.e. will be overwritten by mwan3 rules) or the other way?

I suggest to follow up this in my GitHub page and open new issue there to discuss (as this thread here going longer would be difficult to track everything)

20

I am adjusting the fwmark rules to use masks instead. It's still a hacky solution, but it's likely to work. Will do some tests and ensure mwan and pbr working then post the working files on your github.

EDIT: I have now fixed policy based routing and mwan. Now it is a complete solution. I will post everything at your github in the discussion as well.

1 Like
21

I have opened this to track.

22

I have posted the new files there. The new files provide a complete solution.

23

It is probably the MTU. Try 1280 for the MTU, then go up from there. Also set the MTU of your map-e connection to 1452 in OpenWRT. I have a wireguard VPN and get 300mbps+ via ipv4, but it doesn't work well if the MTU is too high.

24

upnp can also work, but the usable ports need to be specified for that as well. Not sure if it is within the scope of your tutorial, but let me know if you want more details on getting upnp to work.

25

I am not going to use UPnP (and in terms of security this is also not preferred way) so I can live without it, but from technical point of view we can try to see if we can find a workaround, feel free to open a new issue/discussion there :slight_smile:

26

Oh man, this is amazing, I was about to do the same job, already looking at all the Japanese websites talking about MAP-E and IPoE.
Thanks so much!

I just got a 10G connection with Hikari Cross and the NTT east router XG-100NE doesn't even support static routing... but there is a hidden link "192.168.0.1/t" to open and redirect ports.

I will try and come back here to tell you any success story.

This link can be helpful too: https://openwrt.org/docs/guide-user/network/map

Also, for important links, do not hesitate to use https://archive.org, to save pages and to retrieve unavailable screenshots.

27

Thanks, please try and report if any problem in my GitHub page, some forum members already helped and we figured out original MAP package script needs changes to have better results (see discussion/issue page in my GitHub).

Arcive.org I've used it but some 5ch forum things (especially those images) can't be found, but anyway those were targeting OpenWrt older version which doesn't use nftables, we still need something new.

1 Like