|
100% droprate in the backend.
![[dk]](/s/countries/dk.gif) Shadow Hawkins on Monday, 03 October 2011 12:33:10
I've been having a problem with my firewall, that I fixed earlier today that caused all ping trafic for my tunnel to be rejected, the tunnel is T74662.
I have fixed the problem at tested from several online ipv6 pinging tools, that I can ping my own tunnel IP without problems.
In the backend here on sixxs, I still get 100% package droprate, what might be the cause of this?
Is there a way for me to test if your PoP can ping my side of the tunnel, and see the result of that ping? (To make sure it is working from your PoP)
/Bjarke
100% droprate in the backend.
Note that there is a nice FAQ item about 'my endpoint does not ping', start there.
Also it would be very useful if you could include your interface and routing tables; and as you are playing with firewall rules, read the faq on connection trackers, the little part that you have firewalling on IPv4 and IPv6 which might affect all of this and that the pings come from the PoP side of the tunnel to your endpoint and have to take the same path back.
100% droprate in the backend.
Shadow Hawkins on Monday, 03 October 2011 12:59:12
Here is the part of the firewall that relates to pings:
ip6tables -A FORWARD -j COMMON
ip6tables -A COMMON -p ipv6-icmp --icmpv6-type echo-request -j ACCEPT
ip6tables -A COMMON -p ipv6-icmp --icmpv6-type echo-reply -j ACCEPT
It also seems to be working, since I can ping the tunnel ipv6 address using several tools online.
The routing is correct AFAIK, since I can send and recieve traffic just fine over the tunnel.
The only thing not working is the ping packets from the PoP, which is interresting, since the firewall now allows pings (the problem I had before was, that the accept line for echo-request had been commented out by mistake).
100% droprate in the backend.
Here is the part of the firewall that relates to pings:
The part you think relates to ping. Is that portion properly chained into the rest of your rules? Do the other rules already block that before that rule hits? Does the blocking occur on the IPv4 level? Does connection tracking play a role somewhere?
The best thing you can do is run a tcpdump and monitor it, and next to that look at the statistics (ip[6]tables --list -v -n) of course in all the tables, not just the primary one, and have logging enabled for packets you are dropping.
It also seems to be working, since I can ping the tunnel ipv6 address using several tools online.
But what route are the packets taking?
The routing is correct AFAIK, since I can send and recieve traffic just fine over the tunnel.
How did you figure out that it works 'fine'?
The only thing not working is the ping packets from the PoP, which is interresting, since the firewall now allows pings (the problem I had before was, that the accept line for echo-request had been commented out by mistake).
Mistakes can be at a lot of places (see above), only way to see is to check the running configuration.
100% droprate in the backend.
Shadow Hawkins on Monday, 03 October 2011 13:29:30
There is nothing in the chain before that that blocks anything.
From the ip6tables tool, I can see several packet hitting the accept rule, so I know that ping packets hit that rule and gets accepted.
Chain COMMON (2 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp destination-unreachable
0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp packet-too-big
0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp time-exceeded
0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp parameter-problem
4 416 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp echo-request
0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp echo-reply
Since I can both send and recieve packets from the internet over IPv6, I presume the routing works as it should, since that wouldn't be possible if I had messed it up.
On the gateway, the only thing I do is add the default ipv6 route to go through the PoP side of the tunnel.
A tracepath6 for ipv6.google.com also shows that trafic goes that way.
The connection tracking I'm doing is only this:
ip6tables -A INPUT -j COMMON
ip6tables -A INPUT -j BLOCK
ip6tables -A BLOCK -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -A BLOCK -m state --state NEW -i br0 -j ACCEPT
so incoming trafic hits the rules I pasted before, before it hits the connection tracking.
If you need to output from any commands, please let me know :) (Not sure how to provide more info)
100% droprate in the backend.
From the ip6tables tool, I can see several packet hitting the accept rule, so I know that ping packets hit that rule and gets accepted.
But which packets are those, incoming, outgoing? From which src/dst? Over which route?
Since I can both send and recieve packets from the internet over IPv6, I presume the routing works as it should, since that wouldn't be possible if I had messed it up.
As you have not shown traceroutes or routing tables yet, well, it is unknown if that really is the case.
On the gateway, the only thing I do is add the default ipv6 route to go through the PoP side of the tunnel.
Where is the full routing table?
A tracepath6 for ipv6.google.com also shows that trafic goes that way.
Thus maybe the route for that prefix is okay, but what about other prefixes?
The connection tracking I'm doing is only this:
Those are configuration script snippets, not the actual full running configuration.
so incoming trafic hits the rules I pasted before, before it hits the connection tracking.
Obviously you have missed my statements about firewalls on the IPv4 and IPv6 level, oh and that little FAQ item about connection tracking.
Please actually read the FAQ, then if you still have questions ask questions on those points listed there.
100% droprate in the backend.
Shadow Hawkins on Monday, 03 October 2011 17:10:16
The problem seems to have been fixed the minute I fix the firewall problem.
It's just the graphs from the backend that takes a few hours to update correctly :)
|
![[ch]](/s/countries/ch.gif)
on Monday, 03 October 2011 12:37:32
Posting is only allowed when you are