* problem reach the internal.
@ 2002-11-29 19:32 james.Q.L
2002-11-30 1:03 ` james.Q.L
0 siblings, 1 reply; 8+ messages in thread
From: james.Q.L @ 2002-11-29 19:32 UTC (permalink / raw)
To: netfilter
hi,
i have access to my firewall ip at port 8888 forward to port 80 at internal machine 192.168.0.3 .
but the connection always fail. can someone help me debug ? thanks.
[root@cozy166 public]#iptables -L --line-number -n
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:6000 reject-with
tcp-reset
Chain FORWARD (policy DROP)
num target prot opt source destination
1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
3 ACCEPT tcp -- 0.0.0.0/0 192.168.0.3 tcp dpt:80
4 LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
Chain drop-and-log-it (0 references)
num target prot opt source destination
1 DROP all -- 0.0.0.0/0 0.0.0.0/0
[root@cozy166 public]#iptables -L --line-number -n -t nat
Chain PREROUTING (policy ACCEPT)
num target prot opt source destination
1 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8888 to:192.168.0.3:80
Chain POSTROUTING (policy ACCEPT)
num target prot opt source destination
1 SNAT tcp -- 192.168.0.0/24 192.168.0.3 tcp dpt:80 to:192.168.0.1
2 MASQUERADE all -- 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
the rules i added to try to make it work are :
iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 8888 \
-j DNAT --to-destination 192.168.0.3:80
iptables -A FORWARD -p tcp --dport 80 -d 192.168.0.3 -j ACCEPT
iptables -t nat -A POSTROUTING -p tcp -s 192.168.0.0/24 -d 192.168.0.3 --dport 80 -j SNAT \
--to-source 192.168.0.1
=====
/James.Q.L
______________________________________________________________________
Post your free ad now! http://personals.yahoo.ca
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: problem reach the internal. 2002-11-29 19:32 problem reach the internal james.Q.L @ 2002-11-30 1:03 ` james.Q.L 2002-11-30 1:35 ` Anders Fugmann 0 siblings, 1 reply; 8+ messages in thread From: james.Q.L @ 2002-11-30 1:03 UTC (permalink / raw) To: netfilter sorry, i forgot mention that the request from outside my local network to the INET_IP:8888 is fine. only the internal request to it fails. i do not see what is wrong in the rules, anyone ? --- "james.Q.L" <shijialeeee@yahoo.ca> wrote: > hi, > > i have access to my firewall ip at port 8888 forward to port 80 at internal machine 192.168.0.3 > . > but the connection always fail. can someone help me debug ? thanks. > > > [root@cozy166 public]#iptables -L --line-number -n > Chain INPUT (policy ACCEPT) > num target prot opt source destination > 1 REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:6000 reject-with > tcp-reset > > Chain FORWARD (policy DROP) > num target prot opt source destination > 1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED > 2 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 > 3 ACCEPT tcp -- 0.0.0.0/0 192.168.0.3 tcp dpt:80 > 4 LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 > > Chain OUTPUT (policy ACCEPT) > num target prot opt source destination > > Chain drop-and-log-it (0 references) > num target prot opt source destination > 1 DROP all -- 0.0.0.0/0 0.0.0.0/0 > > [root@cozy166 public]#iptables -L --line-number -n -t nat > Chain PREROUTING (policy ACCEPT) > num target prot opt source destination > 1 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8888 to:192.168.0.3:80 > > Chain POSTROUTING (policy ACCEPT) > num target prot opt source destination > 1 SNAT tcp -- 192.168.0.0/24 192.168.0.3 tcp dpt:80 to:192.168.0.1 > 2 MASQUERADE all -- 0.0.0.0/0 0.0.0.0/0 > > Chain OUTPUT (policy ACCEPT) > num target prot opt source destination > > the rules i added to try to make it work are : > > iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 8888 \ > -j DNAT --to-destination 192.168.0.3:80 > iptables -A FORWARD -p tcp --dport 80 -d 192.168.0.3 -j ACCEPT > iptables -t nat -A POSTROUTING -p tcp -s 192.168.0.0/24 -d 192.168.0.3 --dport 80 -j SNAT \ > --to-source 192.168.0.1 ===== /James.Q.L ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: problem reach the internal. 2002-11-30 1:03 ` james.Q.L @ 2002-11-30 1:35 ` Anders Fugmann 2002-11-30 2:20 ` Joel Newkirk 0 siblings, 1 reply; 8+ messages in thread From: Anders Fugmann @ 2002-11-30 1:35 UTC (permalink / raw) To: james.Q.L; +Cc: netfilter james.Q.L wrote: > sorry, i forgot mention that the request from outside my local network to the INET_IP:8888 is > fine. only the internal request to it fails. > > i do not see what is wrong in the rules, anyone ? It cannot be done, as the webserver will try to give an answer to the query directly, and not back through your router, and thus the client will not accept the reply. For a more complete explanation, search the email archives. This question has been asked and answered numerous times. Regards Anders Fugmann ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: problem reach the internal. 2002-11-30 1:35 ` Anders Fugmann @ 2002-11-30 2:20 ` Joel Newkirk 2002-11-30 8:34 ` james.Q.L 2002-11-30 11:44 ` Anders Fugmann 0 siblings, 2 replies; 8+ messages in thread From: Joel Newkirk @ 2002-11-30 2:20 UTC (permalink / raw) To: Anders Fugmann, james.Q.L; +Cc: netfilter On Friday 29 November 2002 08:35 pm, Anders Fugmann wrote: > james.Q.L wrote: > > sorry, i forgot mention that the request from outside my local network to > > the INET_IP:8888 is fine. only the internal request to it fails. > > > > i do not see what is wrong in the rules, anyone ? > > It cannot be done, as the webserver will try to give an answer to the > query directly, and not back through your router, and thus the client > will not accept the reply. > > For a more complete explanation, search the email archives. This > question has been asked and answered numerous times. That's what his SNAT rule should handle: (snippet from original message) > the rules i added to try to make it work are : > > iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 8888 \ > -j DNAT --to-destination 192.168.0.3:80 > iptables -A FORWARD -p tcp --dport 80 -d 192.168.0.3 -j ACCEPT > iptables -t nat -A POSTROUTING -p tcp -s 192.168.0.0/24 -d 192.168.0.3 \ > --dport 80 -j SNAT --to-source 192.168.0.1 port 80 requests heading out to the server (192.168.0.3) from anywhere on the lan (already DNATted in prerouting) are SNATted to appear to come from the firewall/router (192.168.0.1) so that they return through it properly. Yes, this has been answered before, and is covered in the DNAT section of Oscar's tutorial, but the rules he has here appear to be correct. (well, along with the FORWARD EST/REL rule I didn't include in this snippet) James - I'd recommend that you try: iptables -z to clear counters, then try accessing the server from the LAN, then iptables -L -v -n to list your ruleset along with the packet/byte counts which matched. This will often show where unexpected things are happening. IE, if the counts in the FORWARD rules accepting ESTABLISHED/RELATED and packets destined for the server are both zero, then the problem is at PREROUTING. If the FORWARD count for server-bound shows your request, but your POSTROUTING SNAT is zero, or if those both show counts but nothing coming back from the server (EST/REL) those can narrow things down. (of course if the DNAT rule in PREROUTING counts 0 that pretty much nails the problem down... :^) Extreme Logging can help as well, where you insert a LOG rule as the first rule in each chain, try to connect, then check the logs. This can generate a LOT of logging if there is other activity through the firewall, though. If you do this, you should log nat PRE and POST, FORWARD, and INPUT. The first three are where it should be, the fourth is where it shouldn't but might, if the DNAT isn't matching. I'd also suggest you reconsider FORWARD rule #2, which accepts EVERYTHING, and limit your MASQUERADE to traffic outbound to the internet, simply with -o $eth0 or whatever interface connects to the world. j ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: problem reach the internal. 2002-11-30 2:20 ` Joel Newkirk @ 2002-11-30 8:34 ` james.Q.L 2002-11-30 15:27 ` Joel Newkirk 2002-11-30 11:44 ` Anders Fugmann 1 sibling, 1 reply; 8+ messages in thread From: james.Q.L @ 2002-11-30 8:34 UTC (permalink / raw) To: netfilter, Anders Fugmann; +Cc: netfilter the iptables counter is very neat to debug problem. i never thought of that. found a problem that in the following ruleset i shouldn't have '-i eth1'. it blocks the internal DNAT. > > iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 8888 \ > > -j DNAT --to-destination 192.168.0.3:80 i also change the order of the rule in FORWARD chain in Filter table. the rule for filter table is: [root@cozy166 Qiang]#iptables -L -n --line-numbers Chain FORWARD (policy DROP) num target prot opt source destination 1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 2 ACCEPT tcp -- 0.0.0.0/0 192.168.0.3 tcp dpt:80 3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 4 LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 the line num 3 and num 2 are swapped. i tried reset the counter of ruleset and make connection test to it. i found something that i don't understand. when i am testing from an internal machine to INET_IP:8888 the ruleset for filter table is (counter has reset to zero) [root@cozy166 Qiang]#iptables -L -v -n --line-numbers Chain FORWARD (policy DROP 5 packets, 224 bytes) num pkts bytes target prot opt in out source destination 1 11806 15M ACCEPT all -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 2 3 144 ACCEPT tcp -- * * 0.0.0.0/0 192.168.0.3 tcp dpt:80 3 8000 341K ACCEPT all -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 4 5 224 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 Chain OUTPUT (policy ACCEPT 13143 packets, 996K bytes) num pkts bytes target prot opt in out source destination Chain drop-and-log-it (0 references) num pkts bytes target prot opt in out source destination 1 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 #### noticed that the Forward chain has (policy DROP 5 packets, 224 bytes) and the line num 2 has 3 counter and 144bytes hits. it's gotta be a problem here. one thing i am unsure is if the counter and packet get hit means the packet get passed or attempted to pass? taking a look at the line num 2 ruleset, it shouldn't block proper packet tho. 2 ACCEPT tcp -- 0.0.0.0/0 192.168.0.3 tcp dpt:80 another thing i'm unsure is the POSTROUTING and PREROUTING both have two hits and packet records. so this seems to say the packet got back from the webserver. but if the FORWARD chain drops the packet there, the POSTROUTING shouldn't have anything.. [root@cozy166 Qiang]#iptables -L -v -n -t nat --line-numbers Chain PREROUTING (policy ACCEPT 146 packets, 10341 bytes) num pkts bytes target prot opt in out source destination 1 4 192 DNAT tcp -- * * 0.0.0.0/0 65.48.28.33 tcp dpt:8888 to:192.168.0.3:80 Chain POSTROUTING (policy ACCEPT 1 packets, 249 bytes) num pkts bytes target prot opt in out source destination 1 4 192 SNAT tcp -- * * 192.168.0.0/24 192.168.0.3 tcp dpt:80 to:192.168.0.1 2 51 2866 MASQUERADE all -- * eth1 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 79573 packets, 5705K bytes) num pkts bytes target prot opt in out source destination James.Q.L ===== /James.Q.L ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: problem reach the internal. 2002-11-30 8:34 ` james.Q.L @ 2002-11-30 15:27 ` Joel Newkirk 2002-12-01 22:35 ` james.Q.L 0 siblings, 1 reply; 8+ messages in thread From: Joel Newkirk @ 2002-11-30 15:27 UTC (permalink / raw) To: james.Q.L; +Cc: netfilter On Saturday 30 November 2002 03:34 am, james.Q.L wrote: > the iptables counter is very neat to debug problem. i never thought of > that. > > found a problem that in the following ruleset i shouldn't have '-i eth1'. > it blocks the internal DNAT. > > > > iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 8888 \ > > > -j DNAT --to-destination 192.168.0.3:80 > > i also change the order of the rule in FORWARD chain in Filter table. > > the rule for filter table is: > [root@cozy166 Qiang]#iptables -L -n --line-numbers > > Chain FORWARD (policy DROP) > num target prot opt source destination > 1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state > RELATED,ESTABLISHED 2 ACCEPT tcp -- 0.0.0.0/0 > 192.168.0.3 tcp dpt:80 3 ACCEPT all -- 0.0.0.0/0 > 0.0.0.0/0 > 4 LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags > 0 level 4 > > the line num 3 and num 2 are swapped. > > i tried reset the counter of ruleset and make connection test to it. i > found something that i don't understand. when i am testing from an internal > machine to INET_IP:8888 the ruleset for filter table is (counter has reset > to zero) > > [root@cozy166 Qiang]#iptables -L -v -n --line-numbers > > Chain FORWARD (policy DROP 5 packets, 224 bytes) > num pkts bytes target prot opt in out source destination > 1 11806 15M ACCEPT all -- eth1 eth0 0.0.0.0/0 > 0.0.0.0/0 state RELATED,ESTABLISHED > 2 3 144 ACCEPT tcp -- * * 0.0.0.0/0 > 192.168.0.3 tcp dpt:80 > 3 8000 341K ACCEPT all -- eth0 eth1 0.0.0.0/0 > 0.0.0.0/0 > 4 5 224 LOG all -- * * 0.0.0.0/0 > 0.0.0.0/0 LOG flags 0 level 4 > > Chain OUTPUT (policy ACCEPT 13143 packets, 996K bytes) > num pkts bytes target prot opt in out source > destination > > Chain drop-and-log-it (0 references) > num pkts bytes target prot opt in out source > destination > 1 0 0 DROP all -- * * 0.0.0.0/0 > 0.0.0.0/0 > > #### > noticed that the Forward chain has (policy DROP 5 packets, 224 bytes) and > the line num 2 has 3 counter and 144bytes hits. it's gotta be a problem > here. Well, what were those 5 packets? They were logged by line 4. You can add --log-prefix "IPT:forward drop:" to the rule, and then use: tail -n 100 /var/log/messages | grep IPT:for later to list them. (or any other useful prefix for the log lines) > one thing i am unsure is if the counter and packet get hit means the packet > get passed or attempted to pass? taking a look at the line num 2 ruleset, > it shouldn't block proper packet tho. > 2 ACCEPT tcp -- 0.0.0.0/0 192.168.0.3 tcp dpt:80 The counter in the first listing indicates that three packets matched this rule, and were accepted. > another thing i'm unsure is the POSTROUTING and PREROUTING both have two > hits and packet records. so this seems to say the packet got back from the > webserver. but if the FORWARD chain drops the packet there, the POSTROUTING > shouldn't have anything.. > > [root@cozy166 Qiang]#iptables -L -v -n -t nat --line-numbers > Chain PREROUTING (policy ACCEPT 146 packets, 10341 bytes) > num pkts bytes target prot opt in out source > destination > 1 4 192 DNAT tcp -- * * 0.0.0.0/0 > 65.48.28.33 tcp dpt:8888 to:192.168.0.3:80 > > Chain POSTROUTING (policy ACCEPT 1 packets, 249 bytes) > num pkts bytes target prot opt in out source > destination > 1 4 192 SNAT tcp -- * * 192.168.0.0/24 > 192.168.0.3 tcp dpt:80 to:192.168.0.1 This tells us that 4 packets, total 192 bytes, matched this rule in POSTROUTING. 4 packets from somewhere on the LAN, going to the server. The rule above this shows 4 packets, total 192 bytes, matching the rule in PREROUTING that performs the DNAT. Unfortunately this doesn't tell us anything about return packets. The only places those would be matched (at least with the listed rules) are in the PRE and POST policies, and in the ESTABLISHED rule in FORWARD. However, PREROUTING policy accepted 146 packets, POSTROUTING policy only 1, and the listed rules match 4 and 4, so the remaining 145 packets are unaccounted for in the data here. > 2 51 2866 MASQUERADE all -- * eth1 0.0.0.0/0 > 0.0.0.0/0 > > Chain OUTPUT (policy ACCEPT 79573 packets, 5705K bytes) > num pkts bytes target prot opt in out source > destination j ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: problem reach the internal. 2002-11-30 15:27 ` Joel Newkirk @ 2002-12-01 22:35 ` james.Q.L 0 siblings, 0 replies; 8+ messages in thread From: james.Q.L @ 2002-12-01 22:35 UTC (permalink / raw) To: netfilter; +Cc: netfilter > > [root@cozy166 Qiang]#iptables -L -n --line-numbers > > > > Chain FORWARD (policy DROP) > > num target prot opt source destination > > 1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state > > RELATED,ESTABLISHED 2 ACCEPT tcp -- 0.0.0.0/0 > > 192.168.0.3 tcp dpt:80 3 ACCEPT all -- 0.0.0.0/0 > > 0.0.0.0/0 > > 4 LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags > > 0 level 4 > > > > the line num 3 and num 2 are swapped. > > > > i tried reset the counter of ruleset and make connection test to it. i > > found something that i don't understand. when i am testing from an internal > > machine to INET_IP:8888 the ruleset for filter table is (counter has reset > > to zero) > > > > [root@cozy166 Qiang]#iptables -L -v -n --line-numbers > > > > Chain FORWARD (policy DROP 5 packets, 224 bytes) > > num pkts bytes target prot opt in out source destination > > 1 11806 15M ACCEPT all -- eth1 eth0 0.0.0.0/0 > > 0.0.0.0/0 state RELATED,ESTABLISHED > > 2 3 144 ACCEPT tcp -- * * 0.0.0.0/0 > > 192.168.0.3 tcp dpt:80 > > 3 8000 341K ACCEPT all -- eth0 eth1 0.0.0.0/0 > > 0.0.0.0/0 > > 4 5 224 LOG all -- * * 0.0.0.0/0 > > 0.0.0.0/0 LOG flags 0 level 4 > > > > Chain OUTPUT (policy ACCEPT 13143 packets, 996K bytes) > > num pkts bytes target prot opt in out source > > destination > > > > Chain drop-and-log-it (0 references) > > num pkts bytes target prot opt in out source > > destination > > 1 0 0 DROP all -- * * 0.0.0.0/0 > > 0.0.0.0/0 > > > > #### > > noticed that the Forward chain has (policy DROP 5 packets, 224 bytes) and > > the line num 2 has 3 counter and 144bytes hits. it's gotta be a problem > > here. haven't nailed the problem yet.. can i ask further help please ? #eth0 is internal IF, eth1 external IF. #dmesg | tail FWD drop IN=eth0 OUT=eth0 SRC=192.168.0.3 DST=192.168.0.12 LEN=64 TOS=0x00 PREC=0x00 TTL=127 ID=22869 DF PROTO=TCP SPT=80 DPT=1026 WINDOW=17520 RES=0x00 ACK SYN URGP=0 so it's the FWD chain problem? # request INET_IP:8888 from internal machine 192.168.0.12. only one type of msg greped out. #grep 192.168.0.12 /proc/net/ip_conntrack tcp 6 59 SYN_RECV src=192.168.0.12 dst=65.48.28.33 sport=1109 dport=8888 src=192.168.0.3 dst=192.168.0.1 sport=80 dport=1109 use=1 this seeems to be SYN/ACK in return. but no established further on.. here is more verbose iptables dump.. from iptables -L -v -n Chain FORWARD (policy DROP 130 packets, 7822 bytes) pkts bytes target prot opt in out source destination 1292K 1462M ACCEPT all -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 55 3204 ACCEPT tcp -- * * 0.0.0.0/0 192.168.0.3 tcp dpt:80 18402 1286K ACCEPT all -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 53 3296 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `FWD DROP ' from iptables -L -v -n -t nat Chain PREROUTING (policy ACCEPT 51091 packets, 3818K bytes) pkts bytes target prot opt in out source destination 7 396 DNAT tcp -- * * 0.0.0.0/0 65.48.28.33 tcp dpt:8888 to:192.168.0.3:80 Chain POSTROUTING (policy ACCEPT 276 packets, 46588 bytes) pkts bytes target prot opt in out source destination 10 576 SNAT tcp -- * * 192.168.0.0/24 192.168.0.3 tcp dpt:80 to:192.168.0.1 5715 315K MASQUERADE all -- * eth1 0.0.0.0/0 0.0.0.0/0 many thanks, ===== /James.Q.L ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: problem reach the internal. 2002-11-30 2:20 ` Joel Newkirk 2002-11-30 8:34 ` james.Q.L @ 2002-11-30 11:44 ` Anders Fugmann 1 sibling, 0 replies; 8+ messages in thread From: Anders Fugmann @ 2002-11-30 11:44 UTC (permalink / raw) To: netfilter; +Cc: james.Q.L, netfilter Joel Newkirk wrote: > On Friday 29 November 2002 08:35 pm, Anders Fugmann wrote: >>It cannot be done, as the webserver will try to give an answer to the >>query directly, and not back through your router, and thus the client >>will not accept the reply. >> >>For a more complete explanation, search the email archives. This >>question has been asked and answered numerous times. > > > That's what his SNAT rule should handle: (snippet from original message) Thanks for the correction. I see that it can be done, allthough I guess that some serious network degradation will result, especially on a half duplex network. Regards Anders Fugmann ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2002-12-01 22:35 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-11-29 19:32 problem reach the internal james.Q.L 2002-11-30 1:03 ` james.Q.L 2002-11-30 1:35 ` Anders Fugmann 2002-11-30 2:20 ` Joel Newkirk 2002-11-30 8:34 ` james.Q.L 2002-11-30 15:27 ` Joel Newkirk 2002-12-01 22:35 ` james.Q.L 2002-11-30 11:44 ` Anders Fugmann
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.