Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #2010 > unrolled thread

Re: IPv6 and ip6tables

Back to article view | Back to comp.os.linux.networking

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: IPv6 and ip6tables Ivan Shmakov <oneingray@gmail.com> - 2013-03-11 21:13 +0000
    Re: IPv6 and ip6tables geckolimo@gmail.com - 2013-03-12 08:51 -0700
      Re: IPv6 and ip6tables Ivan Shmakov <oneingray@gmail.com> - 2013-03-12 16:14 +0000

#2010 — Re: IPv6 and ip6tables

>>>>> Xavier Robin <geckolimo@gmail.com> writes:

	[Cross-posting to news:comp.os.linux.networking.]

 > Has anyone some experience serving NTP over IPv6 through an ip6tables
 > firewall here?

 > Despite the fact that I opened port 123 (both UPD and TCP), as soon
 > as I set the INPUT policy to DROP, NTP becomes unreachable.  Is it
 > using a different port on ipv6 or something like this?  The server is
 > fully reachable when the INPUT policy is ACCEPT.  It is also
 > reachable over ipv4 with the same iptables rule (and DROP policy).

	I've never seen an issue with such a setup.  The only difference
	is that my firewall has also a -j ACCEPT rule for --dport 123 in
	the FORWARD chain.  I don't know if it's related, though.

[...]

 > xavier@arthur:~$ sudo ip6tables -L
 > [sudo] password for xavier: 
 > Chain INPUT (policy DROP)
 > target     prot opt source               destination         
 > ACCEPT     all      anywhere             anywhere            

	Is there really such an all-permitting rule?

 > ACCEPT     all      anywhere             anywhere             ctstate RELATED,ESTABLISHED
 > ACCEPT     tcp      anywhere             anywhere             tcp dpt:(some ports...)
 > ACCEPT     udp      anywhere             anywhere             udp dpt:ntp
 > ACCEPT     tcp      anywhere             anywhere             tcp dpt:ntp

[...]

-- 
FSF associate member #7257

[toc] | [next] | [standalone]

#2020

On Monday, March 11, 2013 10:13:28 PM UTC+1, Ivan Shmakov wrote:
>         I've never seen an issue with such a setup.  The only difference
>         is that my firewall has also a -j ACCEPT rule for --dport 123 in
>         the FORWARD chain.  I don't know if it's related, though.

I tried to add ACCEPT rules on the FORWARD chain for port 123, and when nothing changed I switched the policy to ACCEPT. NTP server was still unreachable. Reverted back.


>         Is there really such an all-permitting rule?

In fact it is for loopback only (-A INPUT -i lo -j ACCEPT) but for some reason -L doesn't show that.


I decided to perform some logging of the dropped packets.

> sudo ip6tables -N LOGGING
> sudo ip6tables -A LOGGING -j LOG --log-prefix "IPTables-Dropped: " --log-level 7
> sudo ip6tables -A LOGGING -j DROP
> sudo ip6tables -A INPUT -i eth0 -j LOGGING

Only a few lines popped up in my log, all of them being PROTO=ICMPv6 TYPE=135 or TYPE=136, that is neighbor advertisements and solicitations. They were not specifically printed at the same time than the NTP request. I tried to allow them nonetheless:

> sudo ip6tables -D INPUT -i eth0 -j LOGGING
> sudo ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbor-advertisement -j ACCEPT
> sudo ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbor-solicitation -j ACCEPT

Now my NTP server is reachable!

I don't know if it is related with my provider's network architecture (I have a VPS server hosted by gandi.net) or if it is the common behaviour of NTP over IPv6. I should note I've already had ICMPv6-related issues in the past: I had to turn on router-solicitation and router-advertisement to get a global ipv6 address at all. What should be enabled is still a bit arcane to me.

Anyway, everything looks fine now!

Cheers,
Xavier

[toc] | [prev] | [next] | [standalone]

#2021

>>>>> geckolimo  <geckolimo@gmail.com> writes:
>>>>> On Monday, March 11, 2013 10:13:28 PM UTC+1, Ivan Shmakov wrote:

[...]

 >> Is there really such an all-permitting rule?

 > In fact it is for loopback only (-A INPUT -i lo -j ACCEPT) but for
 > some reason -L doesn't show that.

	That's why I'd recommend to always refer to ip6tables-save(8)
	(and not # ip6tables -L) output while troubleshooting.

[...]

 > Only a few lines popped up in my log, all of them being PROTO=ICMPv6
 > TYPE=135 or TYPE=136, that is neighbor advertisements and
 > solicitations.  They were not specifically printed at the same time
 > than the NTP request.  I tried to allow them nonetheless:

[...]

 > Now my NTP server is reachable!

 > I don't know if it is related with my provider's network architecture
 > (I have a VPS server hosted by gandi.net) or if it is the common
 > behavior of NTP over IPv6.

	Actually, it's a common behavior of /IPv6,/ when an
	Ethernet-style network interface is used.  (Which apparently is
	the case.)  To note is that ICMPv6-based neighbor discovery
	assumes the role played by ARP in IPv4 Ethernets.

 > I should note I've already had ICMPv6-related issues in the past: I
 > had to turn on router-solicitation and router-advertisement to get a
 > global IPv6 address at all.

	It's possible to configure IPv6 address manually, thus these
	aren't strictly necessary.  I'd recommend against such a manual
	configuration, however, unless there's a compelling reason to
	use one.

 > What should be enabled is still a bit arcane to me.

 > Anyway, everything looks fine now!

-- 
FSF associate member #7257

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.networking

csiph-web