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

Groups > comp.protocols.time.ntp > #6345 > unrolled thread

IPv6 and ip6tables

Back to article view | Back to comp.protocols.time.ntp

Contents

  IPv6 and ip6tables Xavier Robin <geckolimo@gmail.com> - 2013-03-11 02:10 -0700
    Re: IPv6 and ip6tables Ivan Shmakov <oneingray@gmail.com> - 2013-03-11 21:13 +0000
      Re: IPv6 and ip6tables Xavier Robin <geckolimo@gmail.com> - 2013-03-12 08:50 -0700
        Re: IPv6 and ip6tables Rob <nomail@example.com> - 2013-03-12 16:50 +0000
          Re: IPv6 and ip6tables "Alexandre Y. Harano" <harano@nic.br> - 2013-03-12 17:54 +0000
            Re: IPv6 and ip6tables Rob <nomail@example.com> - 2013-03-13 13:28 +0000
              Re: IPv6 and ip6tables David Woolley <david@ex.djwhome.demon.invalid> - 2013-03-14 07:58 +0000
          Re: IPv6 and ip6tables Xavier Robin <geckolimo@gmail.com> - 2013-03-14 07:08 -0700

#6345 — IPv6 and ip6tables

Hi,

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 append the rules at the bottom of this email. I should also note that it is a virtual (Xen) server with Ubuntu 12.04 Server, kernel 3.2.39 with ip6tables v1.4.12 and NTP server version 1:4.2.6.p3+dfsg-1ubuntu3.1 (from standard Ubuntu repos).

Any input would be very much appreciated.

Xavier



xavier@arthur:~$ sudo ip6tables -L
[sudo] password for xavier: 
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all      anywhere             anywhere            
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
ACCEPT     tcp      anywhere             anywhere             tcp dpt:(more ports...)
ACCEPT     ipv6-icmp    anywhere             anywhere             ipv6-icmp router-advertisement
ACCEPT     ipv6-icmp    anywhere             anywhere             ipv6-icmp router-solicitation
ACCEPT     ipv6-icmp    anywhere             anywhere             ipv6-icmp echo-request
ACCEPT     ipv6-icmp    anywhere             anywhere             ipv6-icmp echo-reply

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

[toc] | [next] | [standalone]

#6346

>>>>> 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] | [prev] | [next] | [standalone]

#6347

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]

#6348

Xavier Robin <geckolimo@gmail.com> wrote:
> 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.

When you don't understand ICMP(v6) you should not block it in your
firewall, as this will cause the weirdest of problems.

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

#6349

[Multipart message — attachments visible in raw view] — view raw

Hello there.

In IPv4 firewalls, people usually blocks ICMPv4 messages. In IPv6,
ICMPv6 covers funcionalities provided by ICMP, ARP and RARP. So, there
must be some caution about which ICMPv6 messages to be blocked.

There are a few documents about how to manage ICMPv6 messages.

[1] RFC4890 - Recommendations for Filtering ICMPv6 Messages in
Firewalls: http://tools.ietf.org/html/rfc4890

[2] NIST - Guidelines for the Secure Deployment of IPv6:
http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf
(Subsection 3.5.6 and Table 3-7)

Remaining any doubts, don't hesitate to ask them!

On 2013-03-12 13:50, Rob wrote:
> Xavier Robin <geckolimo@gmail.com> wrote:
>> 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.
> 
> When you don't understand ICMP(v6) you should not block it in your
> firewall, as this will cause the weirdest of problems.
> 
> _______________________________________________
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
> 


-- 
Alexandre Yukio Harano
Projects Analyst
harano@nic.br
+55 11 5509-3537 ext 4041

NIC.br - http://nic.br
CEPTRO.br - http://ceptro.br

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

#6350

Alexandre Y. Harano <harano@nic.br> wrote:
> In IPv4 firewalls, people usually blocks ICMPv4 messages.

That is not a good idea either.  It will cause weird problems.

When you block ICMPv4 you need to know what message types to
block and what the effect will be.

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

#6351

Rob wrote:

> 
> When you block ICMPv4 you need to know what message types to
> block and what the effect will be.

The classic result of ICMP paranoia is breaking Path MTU Discovery, 
meaning that the connection stalls the first time a long packet is 
transmitted.

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

#6352

On Tuesday, March 12, 2013 5:50:31 PM UTC+1, Rob wrote:
> When you don't understand ICMP(v6) you should not block it in your
> firewall, as this will cause the weirdest of problems.

This is an excellent suggestion. I am now accepting all ICMPv6 packets with an -A INPUT -p icmpv6 -j ACCEPT rule. This will probably save me some more headache later.

Thanks for your input!

Xavier

[toc] | [prev] | [standalone]

Back to top | Article view | comp.protocols.time.ntp

csiph-web