Posted: Sun Mar 20, 2016 20:12 Post subject: SOLVED: ip6tables for WAN to LAN FTP server
I am searching for the correct ip6tables to get access to FTP server which is located at my LAN, from the WAN side. I am doing something wrong, but cannot detect what.
I googled and found several settings that should work, but I somehow cannot get it to work. I do get access, but then it stalls at "Waiting for the Welcome message..."
I guess some of the rules are not needed, and others are missing.
After I have it working, I will reduce the number of lines by using the '-m multiport' option.
For the record: "Yes, I want to have it connect over IPv6 so the absence of Hardware NAT is not affecting the throughput". _________________ Netgear WNDR4300v1 DD-WRT v3.0 BS r29837 | Netgear R6400 DD-WRT v3.0 KB r33525M | Tickets: 5429 IPv4 & IPv6-PD | ProFTP & Samba to USB thumb | DNSMasq DHCPv6 | Pi-Hole on RasPi
If you haven't done it yet, I'd recommend getting ping/ping6 working by allowing ICMPv6 traffic to be forwarded to the /64 routed to your firewall LAN/WLAN iface and local link. I use this:
ip6tables -A FORWARD -i he-ipv6 -p icmpv6 -d 2001:aaa:b:cccc::/64 -m state --state NEW -j ACCEPT
which forwards NEW connections. The stateful firewall should let replies back out -- there should be default rules already installed allowing ESTABLISHED, RELATED packets through. In addition, my default installed ip6tables rules allow INPUT ICMPv6 connections already so I can ping/ping6 the router itself. If routing is OK and no other firewalling or network problems are interfering, pings should work.
Then it should be easier to work on ftp. I haven't set up an IPv6 ftp server but have set up http, dns and smtp without any weird problems. Basic firewall rules allowing those connections to my little "server" system worked fine the first time.
Getting routing rules correct (ip -6 route) was the hardest part -- I went through an embarassingly long "duh" stage. When that was correctly configured, it all worked fine. HTH.
If you haven't done it yet, I'd recommend getting ping/ping6 working by allowing ICMPv6 traffic to be forwarded to the /64 routed to your firewall LAN/WLAN iface and local link. I use this:
ip6tables -A FORWARD -i he-ipv6 -p icmpv6 -d 2001:aaa:b:cccc::/64 -m state --state NEW -j ACCEPT
which forwards NEW connections.
I do not have a he-ipv6 (Hurricane Electric Free IPv6 Tunnel Broker?) interface. I use Prefix Delegation. So I've set the rule:
ip6tables -I FORWARD -i vlan2 -p icmpv6 -m state --state NEW -j ACCEPT
Insert, so it comes above the other rules. The ping however did not respond. But for the record, I do get a connection, but no (data) response (I think).
Quote:
The stateful firewall should let replies back out -- there should be default rules already installed allowing ESTABLISHED, RELATED packets through. In addition, my default installed ip6tables rules allow INPUT ICMPv6 connections already so I can ping/ping6 the router itself. If routing is OK and no other firewalling or network problems are interfering, pings should work.
Then it should be easier to work on ftp. I haven't set up an IPv6 ftp server but have set up http, dns and smtp without any weird problems. Basic firewall rules allowing those connections to my little "server" system worked fine the first time.
Getting routing rules correct (ip -6 route) was the hardest part -- I went through an embarassingly long "duh" stage. When that was correctly configured, it all worked fine. HTH.
The REJECT_IOT is based on MAC address, and it does not contain the MAC address of the FTP server. _________________ Netgear WNDR4300v1 DD-WRT v3.0 BS r29837 | Netgear R6400 DD-WRT v3.0 KB r33525M | Tickets: 5429 IPv4 & IPv6-PD | ProFTP & Samba to USB thumb | DNSMasq DHCPv6 | Pi-Hole on RasPi
For some reason no icmpv6 packets are being forwarded in toward your IPv6 ftp server. Is the address of that server correct? Matches the /64 routed subnet?
(You're not using state so for testing you could drop the "-m state --state NEW" from the ip6tables command )
As you've noticed, the counters aren't incrementing for your pings to your internal ftp server At least 4 ftp control packets are being forwarded through the router, so something is trying to work. You've opened both control and data ports, so.... Are you sure the ftp server is able to work over IPv6? Can you connect from a node on your LAN using IPv6 addresses?
Are you sure routing is getting set up properly? That's where I had my toughest problem. What do 'ip -6 route' and 'ifconfig vlan2' on the router look like? I'd bet the network interface and routing are the problems....
A more difficult problem may be your ISP routing IPv6 traffic matching your assigned /64 toward your gateway router. But the ISP's usually don't have problems like that... usually.
I am certain that the FTP server works on IPv6. When I am connected on the lan side, it works fine.
Now I skipped the -state part in the ICMP and the result is:
Code:
Status: Connecting to [ipv6]:21...
Status: Connection established, waiting for welcome message...
Response: 220 FTP server ready.
Command: USER <USERNAME>
Error: Could not connect to server
At the third try it came even further
Code:
Status: Connecting to [ipv6]:21...
Status: Connection established, waiting for welcome message...
Response: 220 FTP server ready.
Command: USER <USERNAME>
Response: 331 Password required for <USERNAME>.
Command: PASS *****************
Response: 230 User <USERNAME> logged in.
Command: SYST
Response: 215 UNIX Type: L8
Command: FEAT
Response: 211- Extensions supported:
Response: AUTH TLS
Response: PBSZ
Response: PROT
Response: SIZE
Response: MDTM
Response: MFMT
Response: REST STREAM
Response: MLST type*;modify*;size*;UNIX.mode*;UNIX.owner*;UNIX.group*;
Response: MLSD
Response: 211 End.
Status: Server does not support non-ASCII characters.
Status: Logged in
Status: Retrieving directory listing...
Error: Connection timed out after 20 seconds of inactivity
Looking at the tables, I still have 0 packages at icmpv6
I believe my IPv6 routing works fine, since I get on the web using an IPv6 address. Never the less, I do see some interesting stuff with 'ip -6 route'. vlan2 and br0 have the same ipv6 but a different Prefix length. I have a /56 on my WAN side* and have set the router to a prefix delegation of /64, so why does the br0 has /59
Code:
2001:aaaa:bbbb:cccc::/64 dev vlan2 proto kernel metric 256 expires 57598sec
2001:aaaa:bbbb:cccc::/59 dev br0 proto kernel metric 256
fe80::/64 dev br1 proto kernel metric 256
fe80::/64 dev br0 proto kernel metric 256
fe80::/64 dev ath0 proto kernel metric 256
fe80::/64 dev ath0.1 proto kernel metric 256
fe80::/64 dev ath0.2 proto kernel metric 256
fe80::/64 dev ath1 proto kernel metric 256
fe80::/64 dev ath1.1 proto kernel metric 256
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev vlan1 proto kernel metric 256
fe80::/64 dev vlan2 proto kernel metric 256
default via fe80::7218:8bff:fe22:8088 dev vlan2 proto ra metric 1024 expires 1798sec hoplimit 64
unreachable default dev lo proto kernel metric -1 error -128
ff00::/8 dev br1 metric 256
ff00::/8 dev br0 metric 256
ff00::/8 dev ath0 metric 256
ff00::/8 dev ath0.1 metric 256
ff00::/8 dev ath0.2 metric 256
ff00::/8 dev ath1 metric 256
ff00::/8 dev ath1.1 metric 256
ff00::/8 dev eth0 metric 256
ff00::/8 dev vlan1 metric 256
ff00::/8 dev vlan2 metric 256
unreachable default dev lo proto kernel metric -1 error -128
Notice the local interface, where the fe80: address starts with a 12 MAC address, where the hardware address starts with 10. I guess that's no problem, but just noticed it.
Thanks so far! _________________ Netgear WNDR4300v1 DD-WRT v3.0 BS r29837 | Netgear R6400 DD-WRT v3.0 KB r33525M | Tickets: 5429 IPv4 & IPv6-PD | ProFTP & Samba to USB thumb | DNSMasq DHCPv6 | Pi-Hole on RasPi
I wish my help was better. I never had any of the problems you're running into. As you saw, I'm using a he.net/tunnelbroker.net IPv6 tunnel. No chance my ISPs will support IPv6 any time soon. It may take years So tunnels are my only hope. So:
1.) The difference between your native IPv6 and my tunnel transport is important, and may be causing your problems because there's something about your setup that's not quite sorted out.
2.)
Code:
Status: Retrieving directory listing...
Error: Connection timed out after 20 seconds of inactivity
In the old days I'd say the control channel is connecting successfully but the data channel isn't working. Have you tried PASV? (That should apply to IPv6, too.)
3.) The fact that no icmpv6 packets are being accepted by the very first rule in your FORWARD table smells fishy. I think somehow the addressing or subnetting is mixed up.
4.)
Code:
2001:aaaa:bbbb:cccc::/64 dev vlan2 proto kernel metric 256 expires 57598sec
2001:aaaa:bbbb:cccc::/59 dev br0 proto kernel metric 256
Yeah, has got to be bad. I think an expert will tell you this routing table is invalid due to the conflict. When I did some reading a while back, the experts said that "the most specific matching route wins" but that's not an IP engineering solution, just an outcome
Somehow the DHCPv6-PD your ISP is issuing your dd-wrt border gateway router seems messed up. Maybe there's a minor problem with dd-wrt supporting this? I can't find a dd-wrt wiki explanation or instructions for DHCPv6.
The /59 is weird. I'd expect /64 or /48 or /56. I'm pretty sure /59 is non-standard. I'd expect something vaguely resembling this:
Code:
2001:aaaa:bbbb:cccc::/64 dev vlan2
2001:aaaa:bbbb:cd00::/56 dev br0
or similar, which don't overlap, with a /64 upstream to your ISP. BUT I've never used DHCPv6 so I may be off here. Someone with working experience may be able to tell us where I go wrong....
Any chance you can hook up a different router with stock firmware or your laptop to see what addresses it means to assign? Maybe /59 is their choice but the two links shouldn't overlap. If you can hook up a laptop directly to the upstream and get a working IPv6 address, maybe use WireShark to sniff the IPv6 traffic from upstream?
4.)
Acumen wrote:
Notice the local interface, where the fe80: address starts with a 12 MAC address, where the hardware address starts with 10. I guess that's no problem, but just noticed it.
That's normal for deriving the IPv6 address from the MAC. See for example:
Thanks for your help so far. Perhaps this topic will be potted by someone. I call it a day for now. Tomorrow I might try a clean dd-wrt config to see what happens.
Oh and, PASV did not change anything. I tested it before and did again, just to make sure.
Cheers! _________________ Netgear WNDR4300v1 DD-WRT v3.0 BS r29837 | Netgear R6400 DD-WRT v3.0 KB r33525M | Tickets: 5429 IPv4 & IPv6-PD | ProFTP & Samba to USB thumb | DNSMasq DHCPv6 | Pi-Hole on RasPi
It had everything to do with a bad Dhcp6c config.
That is fixed and so is IPv6 on by second bridge interface...
I will soon give ip6tables for FTP another go! _________________ Netgear WNDR4300v1 DD-WRT v3.0 BS r29837 | Netgear R6400 DD-WRT v3.0 KB r33525M | Tickets: 5429 IPv4 & IPv6-PD | ProFTP & Samba to USB thumb | DNSMasq DHCPv6 | Pi-Hole on RasPi
Well, after a period of silence I found the time to test some stuff. Since IPv6 is working fine, thanks to JAMESMTL, I started testing the ip6tables again.
The result, there was nothing to do...
Besides a good IPv6-setup, I upgraded to firmware r29721 std (05/18/16).
ip6tables -I FORWARD -i vlan2 -p icmpv6 -m state --state NEW -j ACCEPT
Thanks for your support everyone!
Feel free to contact me, or respond to this topic, if you have any questions.
- Acumen
P.s. Multiport doesn't work with ddwrt ip6tables as kernel module is not included. Nice to know, since I like to minimize the number of lines and am thereby creating a problem _________________ Netgear WNDR4300v1 DD-WRT v3.0 BS r29837 | Netgear R6400 DD-WRT v3.0 KB r33525M | Tickets: 5429 IPv4 & IPv6-PD | ProFTP & Samba to USB thumb | DNSMasq DHCPv6 | Pi-Hole on RasPi