IPv6 security

[SjoerdNLD]

I have a static ipv6 set. Running w2k8 r2
W/o opening anyting, all ports are closed except for ICMPv6.
Using this test: http://www6.ipv6.chappell-family.co.uk/cgi-bin6/ipscan-js.cgi
After adding a rule for port 80 and apply, it worked instant.
Pls see screenshot, or click link http://[2001:980:32c5:0:8e:6cf4:46e8:e5a7]/

Anyway I like this fw feature - it's great

 

[RMerlin]

I did the same tests on a Windows 7 Home Premium system with no remote desktop server, same results, port 3389 could not be opened.

Windows 7 Home Premium doesn't support Remote Desktop, so there is nothing to answer connection attempts to port 3389.

What an "open port test" does is attempt to connect to the specified port. That means a service must be answering connection requests on that port.

 

[RogerSC]

Windows 7 Home Premium doesn't support Remote Desktop, so there is nothing to answer connection attempts to port 3389.

What an "open port test" does is attempt to connect to the specified port. That means a service must be answering connection requests on that port.

I'm getting mixed messages here...you're telling me that you have to have a service that's listening, and the other guy is telling me that the service can't be running; e.g. no process is listening. But I've tried it both ways, same results.

I'm done testing, by the way, tried lots of stuff on multiple systems, and the results are consistent.

Thanks for your work on the IPv6 firewall, I'll leave it at that *smile*.

 

[RMerlin]

I'm getting mixed messages here...you're telling me that you have to have a service that's listening, and the other guy is telling me that the service can't be running; e.g. no process is listening. But I've tried it both ways, same results.

We're both saying the same thing, just different wording. He's telling you that the scanner doesn't report the 3389 port as being open because you cannot have the Remote Desktop server running - and the reason is because this is a Windows 7 Home Premium, which does not have the Remote Desktop service.

Those online scanners don't specifically test if a port is open or not, rather they test if they are able to connect to a service on that port, or not. So, you must ensure that you have a service running on your end that actively answers connection requests to the port you are testing.

 

[RogerSC]

We're both saying the same thing, just different wording. He's telling you that the scanner doesn't report the 3389 port as being open because you cannot have the Remote Desktop server running - and the reason is because this is a Windows 7 Home Premium, which does not have the Remote Desktop service.

Those online scanners don't specifically test if a port is open or not, rather they test if they are able to connect to a service on that port, or not. So, you must ensure that you have a service running on your end that actively answers connection requests to the port you are testing.

Okay, I'm about done with this, but the first system I tested on was a Windows 8 Professional Edition desktop. I verified that this system was listening on port 3389 by starting a remote desktop session on the system (which I then exited before starting my testing) before doing the "open" port testing. And verified that the port had a process listening to it, also just before starting my testing. So I've covered this ground with the first tests that I made. Sorry if that wasn't clear, I didn't give these details before, since they seemed like details.

This morning, I also tested with another system, a Windows 7 Home Premium Edition, a different set of tests, based on a misunderstood comment that the service can't be running, which didn't make sense to me. However, given the results I've seen so far, I was willing to try just about anything, even if I don't expect it to work.

So that was the only testing that I did on the Home Premium system, just this morning, the bulk of my testing was done on a properly configured Professional Edition system...again, sorry to confuse you, I am trying hard to do this right. Glad you got other's confirming test results.

Thanks.

 

[demo007]

Was just going to try ipv6 alittle but it seems since "firewalling" ipv6 i cant connect at all to internet.

The router wont even set the time using ntp.

Im using IPTV settings with untagged internet and tagged IPTV.

This might be a known issue, but if not thats abit of a dealbreaker for us using IPTV settings.

 

[RMerlin]

Was just going to try ipv6 alittle but it seems since "firewalling" ipv6 i cant connect at all to internet.

The router wont even set the time using ntp.

Im using IPTV settings with untagged internet and tagged IPTV.

This might be a known issue, but if not thats abit of a dealbreaker for us using IPTV settings.

You realise that unless you provide at least the info I asked in my post, it's hard to troubleshoot anything? You don't even mention what type of Internet connection you are using.

 

[RMerlin]

So that was the only testing that I did on the Home Premium system, just this morning, the bulk of my testing was done on a properly configured Professional Edition system...again, sorry to confuse you, I am trying hard to do this right. Glad you got other's confirming test results.

Thanks.

Just to make sure you didn't make the same mistake as TeHashX, you were testing the computer's IP, not the router's IP, correct?

 

[demo007]

You realise that unless you provide at least the info I asked in my post, it's hard to troubleshoot anything? You don't even mention what type of Internet
connection you are using.

(Sorry i read through the whole thread, but couldnt find any questions, maybe i am getting confused with someone else?)

im using regular IPv4 with the new firmware, and that doesent work at all, didnt even come to enabling IPv6 since i would not want to run IPv6 only.
(i used both your precomplied beta1 and an self-compiled "beta2" checked out from git today.

IPTV Settings:

ISP is Telia (in Sweden) with FTTH.

The IPv6 solution is some "native" 6RD which is provided by my ISP(but i didnt even come to that point to enable it).

You should be able to replicate it just by setting my VLAN settings since i guess your internet comes untagged too?

If this is an IPv6 only test-firmware im sorry to have disturbed your testing

 

[RMerlin]

(Sorry i read through the whole thread, but couldnt find any questions, maybe i am getting confused with someone else?)

im using regular IPv4 with the new firmware, and that doesent work at all, didnt even come to enabling IPv6 since i would not want to run IPv6 only.
(i used both your precomplied beta1 and an self-compiled "beta2" checked out from git today.

IPTV Settings:

ISP is Telia (in Sweden) with FTTH.

The IPv6 solution is some "native" 6RD which is provided by my ISP(but i didnt even come to that point to enable it).

You should be able to replicate it just by setting my VLAN settings since i guess your internet comes untagged too?

If this is an IPv6 only test-firmware im sorry to have disturbed your testing

Try putting "1" as the Internet tag, see if that helps.

That beta was indeed focusing on IPv6, I'd still like to make sure it didn't break your Internet access at the same time.

 

[RogerSC]

Just to make sure you didn't make the same mistake as TeHashX, you were testing the computer's IP, not the router's IP, correct?

Yes, it never occurred to me to use the router's IP, since I was testing relative to the IP address of the computer I was using. In other words, to be perfectly clear (I hope), I used only the IPv6 IP's of the computers from which I was testing. And I used the "permanent" IPv6 IP's, although I did try the temporary ones as well when the "permanent" IP's didn't act as I expected.

 

[demo007]

Try putting "1" as the Internet tag, see if that helps.

That beta was indeed focusing on IPv6, I'd still like to make sure it didn't break your Internet access at the same time.

1 is not allowed as input in the web-gui, only 2-4094. so iguess that is not an option.

From the Tools_Sysinfo.asp:

Do you have any clue on how the VLANs are tagged of in the router? might be something similiar that makes IPTV users not having any traffic graphs.

Sorry for going totalt off topic with the IPv6 thread, but i would be happy to help you testing it, but not until IPv4 works for me too
And i guess there are a few out there who is using the IPTV/VLAN stuff too so this is probably good to sort out rather sooner than later.

 

[RMerlin]

1 is not allowed as input in the web-gui, only 2-4094. so iguess that is not an option.

From the Tools_Sysinfo.asp:

Do you have any clue on how the VLANs are tagged of in the router? might be something similiar that makes IPTV users not having any traffic graphs.

Sorry for going totalt off topic with the IPv6 thread, but i would be happy to help you testing it, but not until IPv4 works for me too
And i guess there are a few out there who is using the IPTV/VLAN stuff too so this is probably good to sort out rather sooner than later.

No idea unfortunately. Our local ISPs don't use them, and I never had the chance to play with them either.

I know Asus has fixed a few things related to VLAN tagging in 374, so with any luck their fixes might also resolve your issues once their release the source code.

 

[fr33z0n3r]

I can confirm this firewall works. Well done sir!

 

[zzyzx]

I'll need a volunteer or two who has an IPv6 native connection (preferably DHCP or 6rd) to test something for me:

This may be old news since the firmware has moved into beta, but I tested my 6rd connection and the firewall works fine for me.

Thanks for your great work on this!

 

[ryzhov_al]

I think we have to disable ICMP answers from devices behind the router (by default).
For now, LAN devices stays IPv6-pingable from WAN.

 

[fr33z0n3r]

I think we have to disable ICMP answers from devices behind the router (by default).
For now, LAN devices stays IPv6-pingable from WAN.

Actually from RFC 4890 (http://www.ietf.org/rfc/rfc4890.txt) the recommendation is that Echo Request/Response "Must Not Be Dropped".

This is a recommendation RFC, but ICMP takes on a more important role in IPv6. Various apps/services could begin to rely on this connectivity. (Teredo tunneling is one)

That said, it is up to each device owner to decide how they wish to participate in this experiment called the internet.

 

[RMerlin]

I think we have to disable ICMP answers from devices behind the router (by default).
For now, LAN devices stays IPv6-pingable from WAN.

Hm. Perhaps do the same thing Asus did with WAN PING by adding an option to e nable/disable ECHO replies, but apply it to the IPv6 interface and all IPv6 hosts?

 

[RMerlin]

Just found another RFC (2463) that also states that sending back echo replies is not optional:

Every node MUST implement an ICMPv6 Echo responder function that
receives Echo Requests and sends corresponding Echo Replies. A node
SHOULD also implement an application-layer interface for sending Echo
Requests and receiving Echo Replies, for diagnostic purposes.

RFC4890 also gives a good rationale as to why dropping echo requests is pretty much pointless with IPv6. So for the time being, I won't implement a firewall option to drop echo packets.

 

[ryzhov_al]

Ok then. LAN clients still ipv6-pingable, but router is not. Is it right?